08:07 <janneg> leio: that looks ok. yes it's a little annoying that we need context to identify device nodes due to ranges

08:10 <janneg> log looks like if the display hpd is missing. either I made a mistake when lifting the hpd gpio from ADT. the hpd needs powered dp2hdmi converter but that shouldn't be a problem on the studio

08:16 <janneg> Nefsen402: that's not a log. did you take dcp/dptx-fixes from my or from the AsahiLinux tree. The later has a fix for an issue seen on j414/j416. not sure if there is anything in the devicetree which triggers this or if it depends on other factors. I've never seen that on j314 or while experimenting with dp-altmode

10:32 <leio> janneg: ok, not sure what to try then from my end. I feel like a limiting factor to think along is that I haven't seen a dmesg where it works :)

16:59 <povik> janneg: i found that either from sio data that's handed down from ADT to the coprocessor, or from the mmio sweep while turning power domains on/off

17:01 <povik> in any case i don't think we need it in the FDT for other reason than as an excuse to have the device node on the memory bus

17:01 <povik> since we don't access that MMIO from the driver, neither does apple's

17:06 <povik> janneg: is there a particular SoC for which you want to find the addresses?

17:17 <mps> I run `modprobe snd_soc_macaudio please_blow_up_my_speakers=1` and get ' tas2764 1-0038: ASoC: error at soc_component_write_no_lock on tas2764.1-0038 for register: [0x0000003b] -6' on j1316s

17:18 <mps> did I forgot to enable something in kernel config?

17:19 <mps> this with few latest tagged kernels

17:20 <povik> doesn't seem like it

17:22 <mps> povik: sorry, don't understand

17:24 <povik> it doesn't seem like you forgot something in kernel config

17:25 <mps> aha, thanks

17:25 <povik> hm, 3b, that is INT_MASK0 on the tas2764

17:28 <povik> mps: if you are up for trying things, revert this patch: https://github.com/AsahiLinux/linux/commit/05d68db0ce3ecc05860b707548afb0b0d069ea42

17:28 <mps> povik: ok, will try later this evening

17:44 <mps> povik: https://tpaste.us/JRbl

17:44 <mps> didn't worked

17:44 <povik> mps: actually, no. what you are running into is most likely fixed by https://github.com/AsahiLinux/linux/commit/add8ad99139fed50508c07316ff78f112d7c6bdc

17:44 <povik> best to move this to #asahi

18:01 <janneg> povik: t60xx, for no change between m1 and m2 and the latter works

18:02 <povik> that doesn't confirm the address is right, like i pointed out :p

18:04 <janneg> is it expected that the beginning of the audio is cut-off? for `speaker-test -t wav -c 2` the "front" is mostly inaudible except for the first "Front left"

18:05 <janneg> ah, I didn't realize that was in regard to the dpa mmio. so it might already work

18:06 <povik> janneg: in any case https://github.com/AsahiLinux/m1n1/pull/354

18:06 <povik> ah, yeah, i noticed the ramp-up cut-off too the other day

18:06 <povik> i suspect that's a sio bug

18:08 <janneg> have you already rebased on asahi-wip or dcp/dptx-fixes? I can push my tree somewhere

18:08 <povik> i haven't

18:10 <povik> sio bug as in our driver sio bug

18:10 <povik> or the hdmi receivers have ramp-up time and we need to address that in use-case configuration

18:15 <janneg> povik: https://github.com/jannau/linux/tree/dcp/dptx-fixes-audio should work on m1 with both 12.3 and 13.5 fw, on m2 with 13.5. I started with some cleanup

18:15 <povik> great, thanks

18:16 <janneg> sio boot is reliable, I didn't really test since your dart runtime pm fix

18:21 <povik> where did that fix end up, is it in asahi-wip?

18:22 <povik> yup, since asahi-6.3-1

18:22 <janneg> should be in released kernels since a while

18:48 <janneg> fun, j314c has dp-audio0 to dp-audio4 for dcpext0 to dcpext3

20:42 <povik> how are the 0...4 and 0...3 linked?

20:45 <povik> ah, dp-audio0 belongs to dcp, the rest to the three dcpext

20:45 <povik> why does dcp need the dp-audio though?

20:46 <povik> if the same chip is used somewhere other than a laptop, probably?

20:49 <povik> yeah, of course

20:49 <povik> it's the same everywhere

20:50 <povik> it's just been a while and i am forgetting things...

21:22 <janneg> yes, for dcp, that's why I said fun. I would have expected that the dp-audio0 nodes are deleted from the laptop device trees. needed for mac studio