07:59 <narmstrong> bamse: abhinav__: by curiosity, did someone try to enable HDMI audio on the RB3gen2 ? on hdk8450/8550/8650 we get a timeout while playing audio on the Primary MI2S so I was wondering if it's has been tested

08:11 <z3ntu> narmstrong: I've tested it on my Fairphone 5 (QCM6490), works fine there

08:11 <z3ntu> with some downstream patches but nothing too interesting

08:11 <narmstrong> z3ntu: using audioreach ?

08:12 <z3ntu> no, my adsp firmware doesn't support that afaik

08:12 <z3ntu> APR

08:12 <z3ntu> Does rb3gen use audioreach?

08:23 <narmstrong> no idea

08:25 <narmstrong> it doesn't seem so...

08:45 <z3ntu> I'd be a bit surprised given my QCM6490 LA firmware doesn't, but also for some reason the sc7280 chromebooks have audioreach in their google-y firmware

08:50 <narmstrong> I thought chromebooks were using lpass-cpu bypassing the dsp firmware ?

08:53 <z3ntu> Some parts are definitely handled by Linux vs by adsp firmware on those but seems some parts of adsp firmware still do things, see https://lore.kernel.org/linux-arm-msm/20230616103534.4031331-6-quic_mohs@quicinc.com/

09:15 <narmstrong> so bad he didn't continue, the sound card changes are definitely missing

09:24 <z3ntu> unfortunately a bunch of things are half baked :(

09:26 <z3ntu> Also still fighting since probably 2 years with speaker on both sm7225 Fairphone 4. I get audio from the speaker but it's pretty quiet and I can't for my life figure out why. Maybe ADSP is doing weird things. Maybe (i2c-controlled) amplifier is doing weird things. Maybe Linux has some quirks. For sure I know if I play audio in 16-bit format no audio at all comes out the speaker, with 24-bit I can hear the audio undistorted

10:26 <DylanVanAssche> I wonder if we can dump the audio along the path in this LPASS ADSP setup? I guess not? Otherwise you can determine where in the path the audio gets messed up

11:10 <z3ntu> Maybe reverse question: Is (M)I2S tested and working on anything upstream SM8250+? I see it configured on (sm8250) RB5 for HDMI audio but otherwise nothing relevant upstream

11:12 <z3ntu> By the way, a bit ago I asked a colleague to solder some wires to some tiny test points for the I2S lines between SoC and amplifier, but unfortunately I couldn't get any useful results, maybe also my cheap logic analyzer isn't fast enough to be usable. So I sorta explored that approach already but it's not really doable on the production phones (and I don't have any kind of breakout-board phones)

11:13 <strongtz[m]> I don't really think it's working on anything audioreach anyway

11:33 <narmstrong> z3ntu: i2s is tested and validated on pre-8450 (pre-audioreach), i2s doesn’t work with all current audioreach supported platform, we’re currently investigating

11:48 <z3ntu> I mean it "works" for me also, as in I get undistorted audio out, but I cannot wrap my head around how to get the volume to something reasonable

11:48 <z3ntu> Does the ADSP by default limit volume to something low for like speaker protection reasons or something?

11:49 <cwabbott> is this a known compile error?

11:49 <z3ntu> narmstrong: I know there's these speaker calibration files you can load into the ADSP, so maybe that's missing for me?

11:49 <cwabbott> https://www.irccloud.com/pastebin/S6KdmyEo/

11:50 <cwabbott> from merging arm64-for-6.11 into msm-next

11:54 <cwabbott> (for sm8650-hdk support that recently went in)

11:56 <cwabbott> guess I can disable it for now, but how is it that broken?

13:01 <cwabbott> aaand my nvme drive doesn't show up :(

13:22 <cwabbott> this might be the reason, I have no idea if it's expected or not:

13:22 <cwabbott> [ 1.032870] qcom-qmp-pcie-phy 1c0e000.phy: phy: No clock-output-names index 1

13:22 <cwabbott> [ 1.032431] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with 88e8000.phy

13:22 <cwabbott> [ 1.032877] qcom-qmp-pcie-phy 1c0e000.phy: probe with driver qcom-qmp-pcie-phy failed with error -61

13:28 <z3ntu> cwabbott: sounds like https://lore.kernel.org/linux-arm-msm/20240614-fix-pcie-phy-compat-v3-0-730d1811acf4@linaro.org/ ?

13:30 <cwabbott> z3ntu: git log says I have that series

13:31 <cwabbott> ah, maybe I only have the dt part...

13:32 <cwabbott> so I guess arm64-for-6.11 is currently broken because only half of that got merged

13:37 <cwabbott> yup, reverting "arm64: dts: qcom: sm8650: drop second clock name from clock-output-names" and I get further, now there are nvme-related messages

13:46 <narmstrong> cwabbott: you really need the driver part

13:57 <cwabbott> narmstrong: is it ok if i just revert the device tree part? that seems to work

13:58 <cwabbott> I can boot with reverting that + the patch to fix to fix a7xx enumeration that robclark hasn't picked up yet

14:00 <cwabbott> usb doesn't work, before I had to add a hack patch from flto to avoid needing pd-mapper, I was hoping to drop that but even with the new kernel pd-mapper it's still broken

14:04 <cwabbott> I get [ 1.532155] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with a600000.usb

14:11 <robclark> cwabbott: fwiw the a7xx fix is on msm-next-robclark .. just waiting for akhil to re-send the x1-85 series

17:48 <cwabbott> I looked a bit into why pmic-glink isn't coming up... it's not getting any state notifications from PDR at all

17:51 <cwabbott> PDR gets the instance to use (74) just fine from pd-mapper, then does qmi_add_lookup(&pdr->notifier_hdl, SERVREG_NOTIFIER_SERVICE, 1, 74 /* from pd-mapper */)

17:51 <cwabbott> then... nothing

17:51 <cwabbott> pdr_notifier_new_server never gets called

18:12 <cwabbott> oh, didn't realise the name server part is also in the kernel... gotta trace that

18:22 <cwabbott> yup, no notifier server ever gets created

18:27 <cwabbott> actually no servers at all get created except for ones from the host

23:14 <konradybcio> Luca Weiss: i think 7280-nonchrome is actually audioreach..