jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
dsrt^ has quit [Ping timeout: 480 seconds]
derzahl has quit [Remote host closed the connection]
derzahl has joined #asahi-dev
derzahl has quit [Remote host closed the connection]
derzahl has joined #asahi-dev
derzahl has quit [Remote host closed the connection]
dsrt^ has joined #asahi-dev
derzahl has joined #asahi-dev
greguu has joined #asahi-dev
jakebot6 has joined #asahi-dev
<VinDuv>
jannau: I was talking about the “shut down DCP” approach that marcan mentioned. If my understanding is correct, the race condition is that the monitor might disconnect after you set the mode but before you shut down DCP, and in that case the DCP might have seen the monitor disconnecting and reset the mode. I was thinking that checking (once) that the monitor is still connected just before shutting down DCP might give a tighter rac
<VinDuv>
e window. (of course if you see that the monitor did disconnect, you will need to start up DCP, wait for the monitor to come back, and do it all over again, but that should not happen often)
<jannau>
yes, but I'm not sure how much that helps if the monitor indeed disconnects within 500 ms after mode set. we have to test what happens
<jannau>
but if the display does disconnect without user interaction after modeset it's probably within a couple of 100 ms
bps3 has quit [Read error: Connection reset by peer]
Retr0id0 has joined #asahi-dev
Retr0id has quit [Read error: Connection reset by peer]
Retr0id0 is now known as Retr0id
the_lanetly_052 has joined #asahi-dev
Retr0id has quit [Ping timeout: 480 seconds]
<marcan>
VinDuv: you can't check if it's connected without DCP, so you'd just have to re-modeset and do it all over again yes
<marcan>
but I think in practice it will ~definitely work for a single-modeset; what I'm not so sure about is the stage1->2 latency. but stage2 will ~always have to do a re-check anyway because stage1 might be old or broken or we might need to change the resolution anyway
<marcan>
at which point we can do the double check and *hopefully* it doesn't line up in the race very often
<marcan>
i.e. it would break if, say the two stages take ~100ms and stage2 does not change resolution and the monitor takes about the same to disconnect and catches stage2 in just the exact window between hpd check and dcp shutdown
<povik>
^-- turn your Mac machine into an ohmmeter, TODAY!
<sven>
lol :D
<povik>
:D
<TheLink>
:B
<kettenis>
povik: time to give the ADMAC series another push?
<sven>
there's also SPI that could use another push
<sven>
(finally I can annoy other people with this now that nvme is in torvald's tree :>)
<kettenis>
I'm probably the worst person here to give advice about pushing things into Linux, but letting things linger for months doesn't seem to be a good strategy
<sven>
from my limited experience sending a new version every other week seems to work
<marcan>
doesn't help when google blocks half my emails
<marcan>
(they're still doing that, and postmaster tools still says everything is green)
<marcan>
(I had someone file a bug on their side for this...)
<sven>
fastmail + mailing lists has been a bit annoying as well. i really need to look into just getting one of these @kernel.org aliases
<sven>
i've had two people now reach out to me because mails they got via a list ended up in their spam :/
dsrt^ has joined #asahi-dev
<kettenis>
marcan: ir probably helps if you, as the maintainer of the m1 stuff, actively review/ack the patches others send to the lists
<kettenis>
s/ir/it/
<marcan>
yeah, I caught myself in an email death spiral since the release in march :(
<marcan>
trying to get out of it
dsrt^ has quit [Ping timeout: 480 seconds]
<_jannau_>
sven: did you send the t8103 nvme dts changes as well?
<sven>
nope, totally forgot about those. i'll send them this evening
<_jannau_>
sending an updated series every week only works if there is something to update
<sven>
:D
<kettenis>
jannau: but a reminder after 2-4 weeks if things are unreviewed is appropriate isn't it?
dsrt^ has joined #asahi-dev
<povik>
yeah, i suppose a push on ADMAC is overdue
dsrt^ has quit [Ping timeout: 480 seconds]
c10l4 has quit []
<povik>
i guess i should still be splitting off the MAINTAINERS addition
<povik>
didn't do it for v3 (sending v4 now)
c10l4 has joined #asahi-dev
dsrt^ has joined #asahi-dev
derzahl has joined #asahi-dev
CME has quit []
CME has joined #asahi-dev
dsrt^ has quit [Remote host closed the connection]
<tsujp>
Anything a novice-intermediate C developer (me) who is willing and able to learn much more about C (I love C) can do to help Asahi?
<tsujp>
I'm _actually_ a full stack (devops and webdev) at my day job if that stuff is useful too
<mps>
tsujp: any help is good to have
<mps>
tsujp: what is 'full stack (devops and webdev)'? webdev I assume as web server development
<mps>
but rest?
<tsujp>
Yeah titles are next to useless that's all good
<lkvrsfld[m]>
Ci/cd for web applications
<lkvrsfld[m]>
Etc.
<lkvrsfld[m]>
Same thing i do
<lkvrsfld[m]>
But can‘t understand a shit of the linux kernel
<tsujp>
So I do devops and all that entails and that's _mostly_ for web applications like say a REST API or a full blown site
<mps>
lkvrsfld[m]: thanks
<mps>
lkvrsfld[m]: I interpreted 'full stack' as kernel and drivers at bottom
<tsujp>
Azure, AWS, C#, F#, TypeScript, C (a little), Bash, Ansible, Terraform, Linux (Ubuntu/Fedora/Void/Alpine)
<sven>
--> #asahi please
Gaspare has joined #asahi-dev
<mps>
sorry sven
<lkvrsfld[m]>
mps: Actually a mix of that, and backend web app developing, and kind of sometimes „fixing ui“
the_lanetly_052__ has joined #asahi-dev
<mps>
for my excuse last night friend asked me about charging control perl script I posted here last week or so and I rewrote it in C and to run as daemon, it is here https://www.arvanta.net/2x3d1kfg/charge-ctl.c
<mps>
it is 'bare' one without bells and whistles but works and easy to change
Gaspare has quit [Quit: Gaspare]
<mps>
and ugly hacked before going to bed
the_lanetly_052 has quit [Ping timeout: 480 seconds]
Gaspare has joined #asahi-dev
yuyichao has joined #asahi-dev
yuyichao has quit [Quit: Konversation terminated!]
<marcan>
jannau: found another way to do it; DCP has a mini AIC type thing and we can disable IRQs or mask the relevant IRQ, then it behaves the same (doesn't notice the disconnect, still doesn't notice if it comes back before IRQs are reenabled)
<marcan>
that seems hackier than an orderly shutdown though
<marcan>
what I didn't find is a way to restart the CPU without involving a PMGR reset
<mps>
oh sorry for above messages, I though I'm on #asahi channel
<mps>
thought*
<sven>
marcan: oh, fun, i wondered if those registers where some kind of irq controller because you can also trigger what apple calls NMI somewhere in there
<sven>
didn't manage to figure out what they were though
<marcan>
I couldn't find the nmi stuff where I thought it was
<sven>
it's moved around quite a bit, let me see if I still have notes
<sven>
the kext hast like 5 or 6 different offsets depending on the asc version
<marcan>
hah
<marcan>
maybe the "ipi" thing I found is the nmi
<sven>
hrm, one version is write32(0x10004, 0x11) followed by write32(0x10024, 1) but i'm not sure that's the correct one
<marcan>
yeah, that one is the one I had but I think those registers don't exist/do anything
<sven>
another one I tried at some point is 0xc004 / 0xc024
<sven>
and I think I also tried 0x1004 / 0x1014 but i'm not sure about that one because the context inside m1n1-history is confusing there
<sven>
write32(asc_base + 0x1004, 0x10); write32(asc_base + 0x1014, 1); asc.send(0x30000000000010, 0); asc.recv(); read32(0x809f84000) <-- i dunno what that asc.send was supposed to do but this looks like I managed to crash it like that
<marcan>
0x1004 / 0x1014 kind of fits, those did look like they do something for me
Gaspare has quit [Quit: Gaspare]
bps2 has quit [Ping timeout: 480 seconds]
off^ has joined #asahi-dev
c10l4 has quit []
tomatkinson has joined #asahi-dev
tomatkinson is now known as hir0pro
c10l4 has joined #asahi-dev
Gaspare has joined #asahi-dev
riker77 has quit [Quit: Quitting IRC - gone for good...]
<marcan>
jannau: Pushed the new stuff to put DCP to sleep. Also fixed macos crashing with the DART changes (it was the l2-tt stuff; iBoot only ever allocates 2 tables, macOS hates any more)
<marcan>
not sure if that fixes it on the mac studio though, haven't tried there yet
<marcan>
I expect this to break with the linux DCP stuff of course; it needs to learn to unconditionally kick the ASC (like I made m1n1 do)
<marcan>
macos also doesn't know how to do that, but I made the HV codepath wake DCP back up into quiesced mode
<marcan>
(well, it does, but it requires the ADT to specify the current state)
riker77 has joined #asahi-dev
jabashque_ has quit []
jabashque has joined #asahi-dev
<jannau>
thanks, I guess I never tested the l2-tt stuff without fb reallocation and macos. that looked so obvious that macos should be able to handle that that I never considered that would be the problem
ajxu2 has joined #asahi-dev
<jannau>
1 1/2 tables should be enough for 5120x2160
ajxu2 has quit []
ajxu2 has joined #asahi-dev
<jannau>
higher resolution displays than that are hopefully connected via displayport anyway
<jannau>
works with my picky display
<jannau>
we might have another timing problem. the second modeset fails if it is too close to first one leaving a broken display
<jannau>
delay between first stage modeset and 2nd stage modeset for custom resolution seems to be long enough for my setup though
ajxu2 has quit [Remote host closed the connection]
<jannau>
macos still panics with an reallocated frame buffer on the studio
<marcan>
will have to look at that then
<marcan>
jannau: how does the second modeset fail if done too quickly, exactly?
<jannau>
marcan: sometimes silently, sometimes with "EPIC: IOP returned 0xe00002bc" in the mode set
<marcan>
so the monitor cycles pretty quickly in your case, and we rely on the second modeset happening *after* that in that case?
<marcan>
I guess one thing to do would be to retry the whole modeset a few times
<marcan>
are both of those after a stage1 modeset?
<marcan>
if so I guess the mode that stage1 set was different? since normally a dummy modeset doesn't take much time
<jannau>
the monitor cycles with 500 - 700 ms for HPD de-assert/assert after modeset i it was in power save mode
<marcan>
or was stage1 not modeset there?
<marcan>
sounds like we probably just want to retry a couple times
<jannau>
yes, stage 1 doesn't do anything. Done explictly to make experimenting with it easier
<marcan>
apparently the first modeset trakes 485ms so that explains the bad lining up
<marcan>
I need to get some sleep :)
<marcan>
but I think this should work reasonably well once we do that
<marcan>
alternatively, another hack would be to leave DCP up while m1n1 runs, but kill its HPD interrupt, and then finally shut it down at the end only (which will implicitly fix the IRQ once it comes back up)
<marcan>
that might be a good idea actuallyu
<marcan>
it effectively fixes the race entirely I think, at least within a single stage
<marcan>
I'll give that a shot tomorrow
<marcan>
(or maybe later this week)
<jannau>
good night
<jannau>
I still have the failure case that the dcp modeset suceeds because it comes after the unplug. The monitor doesn't come up though
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #asahi-dev
Retr0id has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<VinDuv>
I updated the stage2 m1n1 on my mini to test DCP shutdown on my monitors. It works :) Even when turning off the monitor/switching inputs
<VinDuv>
I think I even get a picture a bit faster than with hotplug, which makes sense since the mode is already set when the monitor reconnects
<VinDuv>
On the subject of disconnection delays, I think that one of my monitors doesn’t continuously check for a signal when in sleep mode. Instead, it checks for a signal every 5 seconds or so, and if there is one, it starts waking up (and go through the disconnection/reconnection sequence)
<VinDuv>
That means that from the point of view of the computer, the delay between setting the mode and the monitor disconnecting is basically random
<VinDuv>
(running a sleep/wake test in macOS I actually see the disconnect delay vary between 1.4 and 6.5 seconds)
the_lanetly_052__ has joined #asahi-dev
ajxu2 has joined #asahi-dev
ajxu2 has quit [Remote host closed the connection]
hir0pro has quit [Quit: hir0pro]
systwi_ has quit [Ping timeout: 480 seconds]
c10l48 has joined #asahi-dev
c10l4 has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]