05:08 <jeffmiw> j`ey: thanks for checking. I have tried different kernel config, starting with https://github.com/AsahiLinux/PKGBUILDs/blob/main/linux-asahi/config, and messing up with an old one that has been working.

05:09 <jeffmiw> jannau: I do not have CONFIG_GPIO_MACSMC in my config, I will dig around this. Thanks.

14:30 <marcan> merged a bunch of m1n1 PR stuff that was in the queue

14:30 <marcan> also the hypervisor now lets you cpu() to switch CPU without exiting the shell

14:30 <marcan> and there's an iterator so you can do stuff like `for i in cpus(): context(); bt()`

15:08 <_jannau_> marcan: re dcp: shutdown: it doesn't block, we simply don't ack the syslog message since due to asc_can_send() returning false. I don't remember in which state dcp is after that. It's certainly not useable in a chainloaded m1n1

15:08 <_jannau_> issue might be just that we don't power it down

16:06 <marcan> _jannau_: right, but why does it return false?

16:07 <marcan> are there 8 messages in the FIFO? that seems unlikely

16:20 <jannau> yes, I think there are more than 8 messages. dcp produces several syslog messages over an HDMI poweroff/poweron cycle

16:21 <marcan> oh, so we ack 8 messages all at once (presumably for 8 syslog pings coming in) then try to send the EPIC out before DCP clears out any of them?

16:21 <marcan> that would explain it, yes

16:21 <marcan> either way the fix is what I said, we need to block, not fail, when the queue is full

16:45 <jannau> and of course I can't reproduce it anymore. there are 9 syslog messages at shutdown. one of them looks like it reported after the shutdown.

19:50 <marcan> jannau: so... turns out you can shut down DCP.

19:50 <marcan> like all the way :-)

19:50 <marcan> and it comes back up if you PMGR reset it and do a proper boot, and it even does so quickly!

19:51 <marcan> and doesn't modeset!

19:51 <marcan> that means no more hotplug nonsense, and HDMI stays up even if the monitor glitches :-)

19:51 <marcan> I'll implement it in the m1n1 C side tomorrow, need sleep

20:00 <jannau> good night

20:01 <jannau> so on disp0 side the same behavior as when dcp crashes with a 1920x1200 fb on the mac studio

20:02 <marcan> yes

20:02 <jannau> I assume dart-dcp remains locked and keeps its config

20:02 <marcan> I believe so

20:04 <marcan> there's still a race, but as long as we can detect hpd -> modeset -> shut down before the monitor goes into the disconnect cycle, we're good

20:04 <marcan> for users who want to set non-default modes, that'd have to include the trip into stage2

20:05 <marcan> anyway, will figure out the details tomorrow

20:11 <tpw_rules> i think i am such a user

20:11 <tpw_rules> who would want to set non-default modes

20:56 <jeffmiw> fwiw, I understood which config flag I was missing to get back my framebuffer with asahi-5.18-2 on my mba: CONFIG_BACKLIGHT_GPIO :)

21:05 <j`ey> jeffmiw: good its working again

21:12 <VinDuv> From what I’ve seen monitor disconnect delays seem to be all over the place, but hopefully the race window is short enough that it’s unlikely to cause problems

21:17 <VinDuv> maybe after modeset m1n1 should ask the dcp if the monitor is still connected just before shutting it down, to shorten the race window?

21:21 <jannau> VinDuv: you mean like https://github.com/jannau/m1n1/commit/dafd2da58908f38c72cfb5f40e0b4e18c8034d32