ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
<TheLink> looks like an exiting week is coming up :)
<alyssa> :>
<alyssa> any week i take off from work (panfrost) is a good week for asahi 😋
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
skipwich has quit [Ping timeout: 480 seconds]
<alyssa> [syslog] * [FramebufferDCP.cpp:1824]virtual IOMFBStatus IOMobileFramebuffer::swap_submit_dcp(const IOMFBSwap *, IOMFB::Surface **, const uint32_t *, bool, double,
<alyssa> tell me more! :-p
<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
<alyssa> (continued in #asahi-re)
aleasto has joined #asahi-dev
gabuscus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
gabuscus has joined #asahi-dev
al3xtjames2 has joined #asahi-dev
al3xtjames has quit [Ping timeout: 480 seconds]
al3xtjames2 is now known as al3xtjames
aleasto has quit [Remote host closed the connection]
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
<alyssa> this is kinda interesitng
<marcan> alyssa: weren't those already in the list I sent back in the day?
<alyssa> marcan: yes, but it's kinda interesting seeing it in real apple code
<alyssa> maybe i'm a nerd :p
* alyssa reads the DT spec
<alyssa> That too
bps has quit [Ping timeout: 480 seconds]
<alyssa> j_ey: what cmdline do you use for hv?
<alyssa> linux kernel command line I mean, in chosen.bootargs
<j_ey> console=tty0
<alyssa> ack
<alyssa> thx
* alyssa trying to debug display
<alyssa> Guest exception: EXCEPTION_LOWER/SERROR
<alyssa> uh oh
<alyssa> vuart works up until then, though
<j_ey> oh, if youre trying to use vuart, dont use that console=
<alyssa> yeah, I am
<j_ey> if you still get those SERRORs, try https://paste.gg/p/anonymous/a420eb5337bb48419018512753e924eb
<alyssa> ack
<alyssa> [ 0.116190] Unable to handle kernel NULL pointer dereference at virtual address 000000000000022c
<alyssa> Oh, finally :]
<j_ey> from one error to another!
<alyssa> j_ey: this is the one I'm interested in
<alyssa> and answer seems to be "deferred probing" or maybe just fixing my DT bindings
<j_ey> :-)
<alyssa> j_ey: thank u
<j_ey> no thank you
<alyssa> what did i do
<j_ey> dunno
<alyssa> ok, now why is it broken
chadmed has quit [Read error: Connection reset by peer]
<pipcet[m]> blame j_ey!
<j_ey> btw don't rebase onto a recent next, looks like some changes broke nvme
<pipcet[m]> how broken?
<pipcet[m]> as in, doesn't it initialize or does it randomly eat your data?
<j_ey> former
balrog has quit [Ping timeout: 480 seconds]
<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...
<pipcet[m]> D0* / D1* would be suspicious keys...
<sven> https://github.com/AsahiLinux/linux/commits/sven/20210829 too lazy to split it properly, but that contains the current WIP state. will at least put the nvme stuff back in the feature branches later this week
<sven> j_ey: ^--
<j_ey> cool, ty!
<kettenis_> sven: do we really need a separate node for the SART in the device tree?
<sven> no
<sven> i think i'd prefer to have SART part of the ANS/NVMe node
<kettenis_> I liked the version where you made it part of the mailbox
<kettenis_> since it avoided the driver crosscalls
balrog has joined #asahi-dev
bps has joined #asahi-dev
<sven> that branch uses a dumb mailbox fwiw
<sven> just a single channel with 64+32bit messages
<pipcet[m]> D1St and D2St are SMC keys that might correspond to device connection status, but I'm not sure that's what we want
<sven> yeah, might be easier to just rely on the usb pd interrupts (which should exist) at that point
<pipcet[m]> IIRC we don't get those interrupts if it's the remote end of a type-a/type-c adapter that's disconnected
<sven> doesn't matter, those work fine
<pipcet[m]> they do? that's weird, but if you say so they must...
<sven> mine works fine as long as i keep the type-c end connected
<sven> it's just disconnecting/reconnecting the type-c end that doesn't work for me
<alyssa> ^^ ditto for me
<alyssa> which makes sense I think
<alyssa> it's apurely physical layer issue
<pipcet[m]> you're right, it does make sense. PD interrupts it is then :P
bps has quit [Ping timeout: 480 seconds]
Mary has quit [Quit: The Lounge - https://thelounge.chat]
Mary has joined #asahi-dev
<alyssa> DCP driver "works"
<alyssa> for some very generous definition of works.
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
balrog has quit [Quit: Bye]
yrlf has joined #asahi-dev
balrog has joined #asahi-dev