12:10 <Daanct12> aka_[m]: what's apcs2 in msm8939? like what is it used for

13:28 <aka_[m]> Daanct12: in linux it's mostly exposed as clock controller for cpu cluster

13:28 <aka_[m]> Inside apcs space there is mux to switch source for cpu clock signal

13:29 <aka_[m]> It's bigger register space and it also have interrupt bits

13:29 <aka_[m]> Wiki should have what it's abbreviation

13:29 <Daanct12> ah ok

13:30 <aka_[m]> On 8937 there is 3 apcs spaces

13:30 <aka_[m]> For cluster0, cluster 1 and cci

13:30 <aka_[m]> Wait

13:30 <aka_[m]> Not sure

13:30 <aka_[m]> Uh I guess it's like that maybe there is less plls

16:59 <z3ntu> krzk: regarding wcd938x, on my device both swr devices are attached: /sys/bus/soundwire/devices/sdw:0:0217:010d:00:3/status:Attached /sys/bus/soundwire/devices/sdw:0:0217:010d:00:4/status:Attached

16:59 <z3ntu> but I think checking pm_runtime was a good idea, the log seems a bit weird? https://pastebin.com/raw/fsW7V4Un

17:00 <z3ntu> seems both wcd938x_sdw and the soundwire bus gets suspended, then the issue occurs

17:01 <krzk> z3ntu: uhu, nice, so that's the cause. the "sdw" is regmap provider. The wcd9380-codec uses its regmap. When sdw suspends, regmap will be in cache mode, so it will return stale values.

17:01 <krzk> z3ntu: this probably needs proper device links, so runtime PM is ordered

17:01 <z3ntu> Can I for now just force it on for now?

17:02 <krzk> z3ntu: however such link is added in bind callback, so I wonder why it does not work for you

17:02 <krzk> yes, you can

17:02 <z3ntu> pm_runtime_get in wcd938x-sdw.c or something?

17:03 <krzk> yes, could work. or disable runtime pm

17:04 <z3ntu> With the device links you mean the device_link_add calls in wcd938x.c, right?

21:41 <z3ntu> krzk: this is weird, only after wcd938x_sdw_runtime_suspend is called (which then calls swrm_runtime_suspend and then sdw_bus_clk_stop) do we get an qcom_swrm_irq_handler call with "SWR new slave attached". So somehow something there in the suspend code triggers the device attachment, but since it's already half suspended stuff's a bit broken

21:43 <krzk> z3ntu: yes, its weird, maybe something pokes the reset-gpio? Anyway it might be good to send report to mailing lists (ccing maintainers printed on scripts/get_maintainer.pl -f sound/soc/qcom/ arch/arm64/boot/dts/qcom/ )

21:44 <krzk> with some logs (or linsk to logs), description of your hardware and of course description of the issue

22:01 <z3ntu> the reset gpio isn't even touched during suspend it seems, just during probe it gets toggled. And since the pin is called RESET_N in schematics, it also makes to use GPIO_ACTIVE_LOW like all other devices with wcd9385. One thing I noticed now is that this reset-gpio toggle happens very early in boot since I have the driver built-in, so at second ~0.3 of boot. I'm going to try now to build it as module to see if that changes anything..