marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
al3xtjames has quit [Quit: Ping timeout (120 seconds)]
al3xtjames has joined #asahi
<bloom>
I need dev tools on here grumble
<bloom>
dual booting..
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi
hspak has quit [Quit: bye]
hspak has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi
bgb_ has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
ihaveamac has quit [Quit: fail]
ihaveamac has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
VinDuv has joined #asahi
<marcan>
sven: that multiple table stuff sounds like the extra registers I found...
<marcan>
32 bits is enough for access perms for just userspace, without GL
<marcan>
sven: ascwrap-v4 is their general "sub cpu" thing
<marcan>
apple system coprocessor? (wild guess)
<marcan>
so it sounds like we can probably expect the GPU to share the CPU page tables, and have its own SPRR reg to do remapping
<marcan>
bloom: do you know if Linux supports this kind of thing? IIRC the PS4 does it like this with their OS, but I don't know if the linux amdgpu driver could ever do that
<marcan>
seems like it would save a ton of management/overhead for unified memory systems if the GPU can just outright use the userspace page tables
malvo has quit [Ping timeout: 480 seconds]
malvo has joined #asahi
<svenpeter[m]>
Ohh… makes sense
<svenpeter[m]>
I wonder how it selects the user space table then
<svenpeter[m]>
And the GPU just reusing the page tables would also explain why there’s no DART in front of it
<jannau>
mac os doesn't seem to be happy with the usb-pd controller. it writes [0x00], [0x14] and reads [0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00] all over after short initialisation
<jannau>
no, at least the aic interrupt of the first cell (106) is not firing. I'm not convinced that it is actually a aic interrupt
<pipcet[m]>
since the IRQ line is shared, it's probably trying to handle the interrupt for the PD chip that m1n1 stole.
<sven>
the IRQ comes from the gpio controller
<sven>
and what pipcet[m] said would explain all of this
<sven>
it constantly thinks it sees an irq but there isn't one on that chip
<sven>
so it tries to handle it over and over again
<pipcet[m]>
sven: when you steal the usb port, do you initialize the irq mask of the chip?
<sven>
the currentl m1n1 doesn't touch that chip at all
<pipcet[m]>
ah.
<sven>
and the PR i have open just sends the SPSS command
<sven>
so no
<sven>
jannau: you can try to take my PR and write 8 times 0x00 to address 0x16
<sven>
that should disable interrupts for that chip. i think.
<pipcet[m]>
sven: that's what I'm doing in Linux for the "stolen" power port
<pipcet[m]>
(which I just ignore since touching it still breaks charging)
<sven>
that's... weird
<sven>
if you boot a linux kernel with just a dwc3 node charging on both ports still works
<pipcet[m]>
I've been meaning to look into that, yes :-)
<sven>
(well, except for the usual don't replug the port or everything breaks issue)
<pipcet[m]>
yes, that's the issue I meant. if you keep power plugged in from boot everything is fine, if I come home and re-plug power it breaks.
<sven>
yeah, but that's also true for the data connection
<pipcet[m]>
I believe that's correct, yes. Charging is more of an annoyance because you get a spontaneous reboot when the battery's empty.
<pipcet[m]>
but if you don't touch the port, unplugging/replugging power on it works fine.
<sven>
not sure if you saw, but set32(0x502a90004, 3); clear32(0x502a90004, 3) fixes it as well
<sven>
i just don't have any irq to trigger that so far
<pipcet[m]>
oh, wow, thanks, I've got to try that.
<sven>
found that yesterday thanks to jannau's mmiotrace :)
<pipcet[m]>
so macos resets the port once in a while and we don't know what triggers it?
<pipcet[m]>
s/port/phy/
<sven>
"once in a while" = when the device is unplugged
<sven>
well, or if it's replugged. i think mac os actually goes through the whole phy init sequence
<sven>
but that reset sequence above seems to be enough at least for usb2
<pipcet[m]>
and we can detect when a device is unplugged from the physical port but we cannot detect when a device is removed from an adapter connected to the port, right?
<sven>
no idea
<sven>
i can't detect unplugging in device mode but the linux xhci driver seems to get disconnect events
<sven>
but i don't know enough yet to figure out a sane way to handle this in linux
<pipcet[m]>
there has got to be an irq or status register somewhere, just relying on the xhci driver to disconnect isn't good enough.
<sven>
yeah, i'm pretty sure about that
<sven>
could be the usb pd i2c interrupt
<pipcet[m]>
yes, we need to mask IRQs and see whether that helps.
<sven>
how would masking irqs help?
<sven>
oh.. you mean in mac os and see if replugging breaks then as well?
<pipcet[m]>
mask the IRQs for the m1n1 uart, then get another mmiotrace in macos to see whether it's the PD IRQ
<jannau>
sven: writing 8 time 0x00 to 0x16 doesn't seem to help
<pipcet[m]>
jannau: there's a second int mask at 0x17, we might have to clear that too
<sven>
hm... and then we might also need to ack the irqs once
<pipcet[m]>
true :/
<sven>
so maybe also write 0xff 0xff 0xff... to 0x18 and 0x19? :D
<pipcet[m]>
I really really hate Apple for sharing that IRQ line
<sven>
i think the 16k iommu issue is worse ;)
<pipcet[m]>
jannau: probably obvious, but you are writing 0x16 for the other port, right, not for the one we're mmiotracing?
<jannau>
writing all zeros to 0x16/0x17 and all ones to 0x18/0x19 doesn't seem to help
<sven>
strange
<pipcet[m]>
can you read 0x14/0x15 to see whether anything's pending?
<jannau>
probably user error
<jannau>
yes, looks much better now
<jannau>
mac os startup is also much faster now with one usb-c port enabled
<sven>
heh
<sven>
guess it was spamming the i2c bus the whole time ;)
<pipcet[m]>
cool!
<ar>
/42/42
<jannau>
no i2c traffic though on usb-c plug events
<sven>
hrm
<sven>
i'm out of ideas now :D
<sven>
so it's none of the drd irqs, it's not the i2c irq and the phy itself as not interrupts
<sven>
*has
<pipcet[m]>
maybe another GPIO pin?
thunfisch has quit [Quit: frrrp!]
<sven>
that should be in the adt then
thunfisch has joined #asahi
<pipcet[m]>
yes.
<jannau>
I would expect a gpio irq, and then a read of gpio pin 106
<jannau>
there is something if I disconnect the usb-c to usb-a connector
<pipcet[m]>
disconnect which side?
<jannau>
there's nothing if I disconnect the just the USB-A device
<jannau>
usb-c cable plugs are signalled through gpio irqs. on disconnect mac os starts reading from gpio_base + 0x800 until it finds bit 106 set at offset 0x80c
<jannau>
it rewrites pin 106's config then and acknowledges the irq and starts communicating with the tps6598x
<sven>
ok. so then we'll probably have to do the phy reset sequence whenever we heard from that tps chip as well
<sven>
damnit. i hoped we could ignore most of the usb phy for now inside the kernel
<sven>
oh well.. we first need gpio/pinctrl and then i2c upstreamed anyway
pugguu has quit [Read error: Connection reset by peer]
bps has quit [Remote host closed the connection]
bps has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<bloom>
sven: Yeah, the lack of DART for the GPU is odd
<bloom>
it does have its own iommu-mapper in the ADT, but.. not DART
<bloom>
I started mmiotracing and looking at ADT etc
<bloom>
As hinted by the compatible, gfx-asc is just exposing IOP mailbox
<bloom>
Not too much interesting here most of the time, rather than just a "there is new work for you GPU, wake the f up"
<bloom>
sgx is the GPU itself but even less MMIO poking here
<bloom>
I did a little digging on IOP, and that's normal -- it's meant to be low bandwidth, with shared memory used for high bandwidth transaction.
<bloom>
So then the question is where does that shmem come from?
<bloom>
Possibly the IOP mailbox itself.
<bloom>
as well as, what's inside the shmem? is it just the buffer prepared by userspace passed through unmodified? would be convenient, but seems unlikely.
<jannau>
creating pull requests for pull requests now
<sven>
bloom: would it make sense if the GPU has just the same view of memory as the userspace app?
<sven>
that's what that gxf/sprr patent sorta hints at
<kettenis>
the wifi controller definitely works with using a normal MSI
<kettenis>
there is an SMC "gpio" involved in powering the thing up
<kettenis>
and I suspect wifi can wake up the system as well
<jannau>
even without mmio/irq tracing no wlan or bluetooth but probably still slower than usual
<bloom>
silly question but is the power button a regular gpio?
<bloom>
or an SMC "gpio" or..?
<pipcet[m]>
neither
<pipcet[m]>
it's an SMC property
<pipcet[m]>
and it also sends an SMC message when pressed.
<jannau>
wlan works now after switching it on and off a couple of times
<bloom>
ah
<jannau>
works == find networks
<pipcet[m]>
I haven't figured out how to decode that message yet, but essentially you get an interrupt from the SMC mailbox, discard the message, and you can check whether the power button was pressed, and whether it's currently pressed.
<pipcet[m]>
oh wait, sorry, all that's on the MBP, might be totally different on the mini
<bloom>
ah
<sven>
i think there's a good chance it's the same on the mini
<jannau>
I would assume so two. why develop a different solution just because the mini misses a couple of keys
<pipcet[m]>
does the mini have an AOP?
<sven>
yup
<pipcet[m]>
I ran down the battery on my MBP once, and it was very very unhappy.
<bloom>
snrkt
<pipcet[m]>
anyway, the SMC has a large number of four-character keys, most of which will need to be decoded at some point. I wonder which of those the mini has.
<pipcet[m]>
(I assume it has no lid switch)
<hell__>
snrkt?
<jannau>
no irq activity on scanning or joining networks. might it be used when the pcie link is powered down?
<jannau>
pipcet[m]: user facing there is just the power button and maybe the headphone jack
<jannau>
saving the network preferences crashed mac os
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
VinDuv has quit [Quit: Leaving.]
bps has joined #asahi
<svenpeter[m]>
The “normal” interrupts will be the pcie MSIs. That gpio must be something else
<svenpeter[m]>
Possibly waking up the machine like kettenis suggested
klaus2 has joined #asahi
klaus1 has quit [Ping timeout: 480 seconds]
bsandro has joined #asahi
klaus3 has joined #asahi
klaus3 is now known as klaus
klaus is now known as nsklaus
klaus2 has quit [Ping timeout: 480 seconds]
choozy has quit [Remote host closed the connection]
<jannau>
makes sense. based on the pin config I don't think the second cell codes the AIC interrupt
<jannau>
it also doesn't make that much sense since the OS can read that from the pin config