[ljskernel]

On bootup, an Apple MacBook Pro (13-inch, M2, 2022) dmesg shows:

dcp-dp-audio 238334000.audio-controller: No DMA device

And:

$ cat /proc/device-tree/soc/sio@236400000/status
disabled

This model's t8112-j493 hardware is able to encode this data through its SIO coprocessor, but the device tree doesn't configure it to be able to.

Similar to t8112-j473, enable the node and assign the sio alias so m1n1 injects the correct firmware.

With this applied the sink is available:

 ~ cat /proc/asound/cards
 0 [DisplayPort    ]: apple_dcp - Apple DisplayPort
                      Apple DisplayPort
...

And audio works correctly over DP and is stable.

[WhatAmISupposedToPutHere]

I do not think we want it to be generally available yet, whether it is stable or not highly depends on which device is on the other side of the dp link.

[ljskernel]

Ack fair enough, I have tested a Samsung LS49AG95 which is working fine, but I did notice some (minor) instability immediately after sending this (typical) - the audio dropped after I switched from 120 Hz -> 60 Hz requiring a pipewire restart that fixed it.

I also noticed (not audio obviously but DP-related) it seems to have issues with 10-bit colour depth at 120 Hz, resulting in compression and visual artifacts, so have forced to 60 Hz, will try a hack locally to force 8 bit to see if that fixes that.

Obviously intending this one for the fairydust branch but understood if you'd rather avoid possible instability with this even on that.

Will report any other bugs I notice with this setup, is rapidly becoming a daily driver for me now... :)

[WhatAmISupposedToPutHere]

If i found the right monitor - isn't that expected? 5120x1440@120hz with 10bpp is just slightly above dp 1.4 speed, so it needs either subsampling or dsc, and i am not sure if we do that correctly.

[ljskernel]

yeah it just seems the G9 isn't brilliant at rendering the compressed signal :) and it seems that 8 bit isn't available as an option as currently implemented?

I've put in a hack to force 8 bit which seems to have fixed it. But obviously the real fix would be to make that otherwise available.

[nr23730]

Hi,

just out of curiosity I tried this branch. My machine is a MacBook Pro 13 M2.
I can confirm that the state went from disabled to

$ cat /proc/device-tree/soc/sio@236400000/status
okay

but the device won't show up as a sink.

In dmesg I see

[    0.013051] /soc/audio-controller@238334000: Fixed dependency cycle(s) with /soc/dcp@271c00000
[    0.013142] /soc/dcp@271c00000: Fixed dependency cycle(s) with /soc/audio-controller@238334000
[    0.014234] /soc/audio-controller@238334000: Fixed dependency cycle(s) with /soc/dcp@271c00000
[    0.020604] /soc/audio-controller@238334000: Fixed dependency cycle(s) with /soc/dcp@271c00000
[    0.020615] /soc/dcp@271c00000: Fixed dependency cycle(s) with /soc/audio-controller@238334000
[    1.072146] apple-drm soc:display-subsystem: bound 238334000.audio-controller (ops dcpaud_comp_ops [appledrm])

For reference: I tried with a iiyama Prolite XCB4594DQSN-B1 Monitor.

[ljskernel]

@nr23730 you need appledrm.hdmi_audio=1 on the kernel command line too if you don't have that set. I've had to do a lot of fiddling locally to get it working, @WhatAmISupposedToPutHere is right that this isn't really in a stable state yet :)

[nr23730]

Thanks! Now it shows up.

[ljskernel]

Hm though @WhatAmISupposedToPutHere aren't all uses of DP audio gated on this kernel parameter anyway, and also in an experimental branch, so does it make sense to take this change to reflect the fact that it's a valid setting, if experimental for t8112-j493?

Are other hardware that has the SIO set like t8112-j473 all tested and confirmed working? What kind of testing would you need me to do to confirm my hardware?

Is there much of a delta between this hardware and other hardware?

All the flakes I've seen have been about audio-over-DP and the DP stuff in general, especially handling connect/disconnect and even more so suspend/wake.

I haven't seen anything that points specifically to this hardware and when just used without connecting/disconnecting has worked flawlessly.

[WhatAmISupposedToPutHere]

Fair, the issues are not model-specific, i think this one was just missed, since it is not enabled in general.

[jannau]

manually merged differently and hopefully enabling DP audio for all M2/T8112 devices one the DP-altmode port. The M2 Macbook Airs were missing the same change and the M2 Mac mini did not enable dpaudio0 which is used for DP-altmode port. DP-audio was not tested when the branch was created.

[ljskernel]

Any hint as to which of the rebased commits achieve the same thing @jannau or is it just a rebase and go away?... Not a very friendly way of resolving this PR. I guess I'll keep future stuff to my local branch.

[WhatAmISupposedToPutHere]

This is now a part of ad272ad . Sorry about the miscommunication, if you wanted it resolved some other way - tell us, there was no intent to "rebase and go away", it is just that the way this repo is managed is by heavily using git history rewrite features.

[ljskernel]

Thanks @WhatAmISupposedToPutHere , I understand the rebasing but a simple 'hey - I think doing x,y,z will fix this for your hardware and [other hardware] - have rebased, could you check?' would be a lot nicer than 'manually merged differently and hopefully enabling DP audio' close

The vibe is dismissal and that's not encouraging contributions.

(I'm a kernel maintainer so I'm used to 'robust' comms, but also this is a contribution back in my personal time in genuinely good faith so y'know.)

[WhatAmISupposedToPutHere]

I see, it seems like the issue that the "script" for internal contributors (where everyone already knows what branch to look at and where changes are supposed to end up) was applied to you, while a different one should have been applied in this case. Again, sorry about that, it is something that fell through.

[ljskernel]

Anyway rebased on the branch and can confirm it works thanks