13:17 <mort_> I have an apq8016, somehow audio stuff just doesn't show up *at all* after a kernel upgrade. The config should be correct, CONFIG_SND_SOC_LPASS_APQ8016=m, CONFIG_SND_SOC_APQ8016_SBC=m, CONFIG_SND=y. My devicetree should be correct

13:20 <mort_> https://p.mort.coffee/3An this is my sound devicetree file

13:20 <mort_> is there anything I can do to debug why this doesn't work? Any more information I can provide?

13:21 <mort_> on a 4.9 kernel, where I do have working sound, I see messages from qcom-apq8016-sbc 7702000.sound during boot, but I don't with the 5.10 kernel I'm trying to upgrade to

13:30 <vknecht[m]> mort_: maybe you can get some inspiration from https://github.com/msm8916-mainline/linux/blob/master/arch/arm64/boot/dts/qcom/apq8016-sbc.dts#L356-L396 tho it's a more recent tree than 5.10

13:32 <mort_> I've been using apq8016-sbc.dtsi from 5.10.y as inspiration (https://github.com/gregkh/linux/blob/7d51b4c67cfb95a069ccbe52f13963bfd9fe85b0/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi#L331-L371)

13:32 <mort_> but it's essentially identical

13:33 <mort_> the 4.9 dts I've been using, which works, doesn't have a external-dai-link@0, even though the upstream apq8016-sbc.dtsi does have an external-dai-link@0, so I'm guessing it doesn't apply to this hardware

13:35 <mort_> I think the biggest thing I'm surprised by is that there's no messages at all in dmesg from apq8016_sbc_sndcard, despite there being a status=okay devicetree node with it as its compatible string

14:53 <vknecht[m]> which compatible ? not `qcom,sbc` by chance ?

15:03 <mort_> the sound label is defined here: https://github.com/gregkh/linux/blob/7d51b4c67cfb95a069ccbe52f13963bfd9fe85b0/arch/arm64/boot/dts/qcom/msm8916.dtsi#L1315, so compatible is "qcom,apq8016-sbc-sndcard" inherited from there

15:45 <vknecht[m]> could check with lsmod whether modules are loaded or not, and try loading them manually if not

16:34 <mort_> I'm digging into the driver, seems like probing always exits with an error. Adding debug prints to figure out why. Will come back to it tomorrow but I at least have a direction to go now

16:43 <vknecht[m]> can try https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html#debug-messages-at-module-initialization-time

16:51 <mort_> my experience is that drivers are frequently under-printk'd so it's often better to just get in there

18:18 <aka_[m]> konradybcio: You asked about "what about dropping xo_board and using rpmcc" right?... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/BpcmpDmeAFLZkhSZLtJRINji>)

18:19 <aka_[m]> weird because i can recall sm6115 not having such issues?

18:20 <aka_[m]> glink vs smd issue?

18:20 <konradybcio> if it's a new dt, you should probably pass it to rpmcc via dt

18:20 <konradybcio> and then use the rpm clock

18:20 <konradybcio> legacy lookup will work too but that's not prefered

18:20 <konradybcio> thinking about it, gotta resend 6375 with that

18:21 <aka_[m]> you know i mean 8976 dtsi

18:21 <aka_[m]> in theory i can just use xo_board into rpmcc

18:21 <aka_[m]> and replace rest of xos with rpmcc

18:21 <aka_[m]> but one has to stay

18:21 <konradybcio> that's what your'e supposed to do

18:21 <aka_[m]> but in theory its wrong

18:21 <aka_[m]> because we shouldn't expose xo like that

18:21 <aka_[m]> its not separate

18:22 <konradybcio> what do you mean 'expose'?

18:22 <aka_[m]> i mean fixed-clock

18:22 <konradybcio> xo as in the physical crystal oscillator feeds the rpm xo clock

18:22 <konradybcio> which actually feeds the rest of the soc

18:23 <konradybcio> there's some pmic clock mess along the way but it doesn't really matter

18:24 <z3ntu> I'm actually not aware of any separate crystal being somewhere on the board, or at least it's never mentioned on any schematic. Doesn't pmic have this stuff included in the package?

18:24 <aka_[m]> its part of pm

18:24 <aka_[m]> lines get out and its connected to various blocks