<alyssa>
By the way, since it wasn't obvious to me (and so probably isn't obvious for anyone here but marcan)--
<alyssa>
swap_enabled/swap_completed are bitfields
<alyssa>
bit i says whether to enable surface i
<alyssa>
("layer" in the firmware, based on syslog)
<alyssa>
[syslog] * [UPPipeDCP_H13P.cpp:3320]IOMFB verify_active_surface_count: cannot blend more than 2 layers
<alyssa>
Oh, that's a bummer :|
<alyssa>
marcan: that explains why you saw macos fuse the cursor into the main fb .... that's the only way to make room for an overlay plane for video compositing, etc
<marcan>
huh
<marcan>
then why are there 3 slots? that's weird...
<alyssa>
Yeah. I'd say "just firmware, there are 4 in 12.x after all" but that doesn't explain why there seemed to be 3 slots in the registers too..
<alyssa>
Unless DCP has a particular meaning of "blend" (i.e. scaling or CSC or overlapping or something)
<alyssa>
and you get 3 as long as you aren't using fancy featur?s/ Dunno
<sven>
yeah.. tracking pci.c in the future is going to be fun
<j_ey>
the tag / command_id is 16 bits in the code, but we think the hw might only care about 8 bits, so therefore it's 0-ing out the 'gen' thats put into the top 4 bits
<sven>
and while we can theoretically hot plug usb-c devices now, we can't really distinguish between the two ports yet.
<sven>
so.. uh.. we were half-successful i guess :D
<pipcet[m]>
same message for both ports? d'oh.
<sven>
yeah. then we though we found some bit in the phy registers to find the correct one
<sven>
but that didn't work either
<pipcet[m]>
fun.
<kettenis_>
sven: does it matter to find the correct one?
<sven>
kettenis_: yes, because otherwise the other phy will get a reset as well and whatever is plugged in there will stop working
<kettenis_>
oh, the phy actually needs a reset before it can detect a new device?
<sven>
it appears so :/
<sven>
that's at least what mac os does
<sven>
there's still that pd chip on i2c. that should hopefully also have some interrupt to detect a new connection
<kettenis_>
but mac os uses this SMC thing?
<sven>
i'm not entirely sure. i haven't been able to see the direct call chain in the hv
<j_ey>
SMC generates a notification, but we dont know if it actually uses that
<j_ey>
or some other method
<sven>
i just see both the SMC notification and some USB PD interrupt and a few moments later it issues the PHY reset
<pipcet[m]>
sven: do you see a PD interrupt if you unplug a device from a typec-typea adapter? rather than unplugging the adapter?
<sven>
and the backtrace from the PHY reset wasn't helpful to see how it was triggered
<pipcet[m]>
is it reading something else from the SMC, maybe? maybe there's a bit in there for each port...