08:05 <jhovold> broonie: i would not be suprised if there are further problems with the qualcomm runtime pm implementation, but the -EBUSY in steev's log happens already during component probe

08:06 <jhovold> the runtime pm implementaion is incomplete, and fails to resume the soundwire device before trying to access the registers

08:06 <jhovold> I can reproduce the issue here with some instrumentation altering the autosuspend timing, has just worked by chance for most of us so far

08:08 <jhovold> steev: i shall have a fix for you to test by the time you wake up (go back to to bed ;) )

10:11 <ungeskriptet> kitsune-tsuki: Hi, I've been told that you have a sc7180 laptop with ufs. I want to upstream SM7125 support and wanted to ask you if you have ufs working there

10:12 <ungeskriptet> Right now I have ufs defined in sm7125.dtsi. It would be great if you could test this so that I can move the UFS nodes to sc7180.dtsi if it works for you

10:13 <ungeskriptet> https://github.com/ungeskriptet/linux/blob/sm7125-next/arch/arm64/boot/dts/qcom/sm7125.dtsi#L19-L84

12:06 <jhovold> steev, clover[m], srinik, broonie: posted a fix for the broken headphone issue here: https://lore.kernel.org/lkml/20230630120318.6571-1-johan+linaro@kernel.org/

16:35 <steev> jhovold: doesn't work :(

16:35 <steev> https://paste.debian.net/hidden/7adf50ba/

16:38 <broonie> steev: You could put a WARN_ON() in there to generate a backtrace and confirm exactly where it's trying to do the I/O.

16:40 <steev> will see about doing so after work

18:15 <hexdump0815> ungeskriptet: i once tried to take over the sc7125 ufs entries to a sc7180 samsung galaxy book go and it did not work

18:15 <hexdump0815> unges

18:16 <hexdump0815> hexdump0815: ungeskriptet: https://github.com/hexdump0815/linux-mainline-qcom-msm8998-kernel/blob/main/misc.qc7/misc/sc7180-samsung-galaxy-book-go.wip#L180C4-L274

18:16 <hexdump0815> ungeskriptet: but i must admit that i have no real idea about ufsand that was really just a blind try - i guess there is more code required beyond just the dts entries

18:17 <ungeskriptet> I remember that UFS wasn't working for me on the latest kernel and I had to change some nodes/properties

18:17 <hexdump0815> ungeskriptet: i could try a few things in case you can guide me a bit :)

18:17 <ungeskriptet> Sure that would be great

18:19 <hexdump0815> ungeskriptet: i'm currently running v6.1, so if you have anything to try for that, then just point me to the code and i can have a look in a few days ... i could also go to v6.3 or v6.4 if needed

18:20 <hexdump0815> ungeskriptet: what seems to be a problem on those windows on arm devices it to get reliable resource info from the dsdt

18:22 <ungeskriptet> https://github.com/ungeskriptet/linux/commit/4e9939bf0d53fbe9820053ba0a1f8b8f2cdcec77

18:22 <ungeskriptet> You need this patch and rename sm7125-qmp-ufs-phy to sc7180-qmp-ufs-phy

18:23 <ungeskriptet> And rename the compatible in the DTS too

18:25 <ungeskriptet> It would be best to test this on v6.4

18:35 <jhovold> steev, broonie: very odd, that register is only accessed in wcd938x_soc_codec_probe() and I could reproduce the exact same symptoms you reported by intstrumenting the timing

18:37 <jhovold> it seems unlikely that we have more than one way that that access can fail with -EBUSY, but I guess not impossible

18:45 <broonie> Is runtime PM turned off somehow?

18:45 <hexdump0815> ungeskriptet: i'll give it a try during the next days and report back here

18:48 <jhovold> broonie: I'm assuming the -EBUSY comes from map->cache_only being set in _regmap_read(). If runtime was disabled, the soundwire device should not be suspended and that flah should not be set

18:49 <broonie> jhovold: wcd9380_probe() appears to unconditionally set cache_only, assuming it's starting up with runtime PM idle.

18:50 <jhovold> broonie: heh, indeed. So way we have at least two ways this implementation is broken...

18:52 <broonie> The whole bootstrapping with runtime PM situation coupled with optionality always feels overly fragile and complex :/

18:58 <jhovold> broonie, steev: so it seems we may have a regression here with 84822215acd1 ("ASoC: codecs: wcd938x: fix accessing regmap on unattached devices") that was backported to 6.3.2

18:59 <jhovold> before that commit, the state of the regmap cache flag matched the runtime pm state

18:59 <jhovold> and with my fix, this would not have been an issue

19:01 <broonie> Oh, it's the TX sound device probing after whatever device this is?

19:01 <jhovold> I'll take a closer look later, but dropping that regcache_cache_only or setting the initial state to suspended may be enough to address this

19:01 <broonie> The other devices need to probe defer if they need the regmap.

19:02 <jhovold> broonie: the code is using this soundwire device for register accesses, i don't understand yet why you'd set it the cache_only flag ones it has probed

19:03 <jhovold> codec*

19:04 <broonie> IIRC it's the SoundWire issue where the device is probed through DT but might not have actually enumerated on the bus yet.

19:04 <jhovold> ah, ok. yeah, something clearly goes wrong, but at least we know roughly where now

19:04 <jhovold> goes wrong here*

19:05 <broonie> We keep a persistent Linux device around for SoundWire devices even though they might physically hot unplug and reconnect for power management purposes.

19:08 <jhovold> ok, after skimming the commit message, it seems starting up in suspended state might do the trick, but I'll take a closer look tomorrow

19:15 <steev> jhovold: shouldn't that mean that 6.3.9/10 shouldn't work as well though if it was backported to 6.3.2? because 6.3 works for me, but 6.4+ does not (though 6.3.10 seems to have a few timing issues)