<j`ey>
oh hm, !spi->controller->set_cs_timing should be true actually?
<jannau>
no, also if the controller has no method to set the cs timing: !spi->controller->set_cs_timing
<j`ey>
yeah I missed that when i first read it, thought it was inside the if () {..
yuyichao has quit [Ping timeout: 480 seconds]
<j`ey>
(I probably need to do more testing with linux.py, I always used hv)
bps has quit [Ping timeout: 480 seconds]
<marcan>
jannau/j`ey: thanks for catching that!
<marcan>
yup, that was a dumb typo
<marcan>
did you not hit the WARN_ON(fifo_flags & APPLE_SPI_FIFO_TXOVERFLOW); ? I would expect that to fire with the bad code
rwhitby has joined #asahi-dev
bps has joined #asahi-dev
<marcan>
either that or it would get stuck
<jannau>
I saw tx_overflow set in the spi trace I did not notice it in the kernel log but I was not really looking at it
<marcan>
it might be it was never making it out of the transfer loop
<j`ey>
marcan: I managed to see one packet from the keyboard at least, but then it gets stuck
aidenfoxivey has joined #asahi-dev
StupidYui has quit [Read error: Connection reset by peer]
yuyichao has joined #asahi-dev
rwhitby has quit [Quit: rwhitby]
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
vx^ has quit [Ping timeout: 480 seconds]
<marcan>
j`ey: can you push that branch somewhere?
<marcan>
in principle we can run the HV in UP mode (or just filter out one CPU, might add an option for that) and then throw the gpiola on that one and see what linux does
<marcan>
does it not need those delays with the HV *even without* SPI tracing?
<marcan>
just plain HV should have relatively little performance impact, mostly the timer IRQ spam
<jannau>
let me test that
<jannau>
it's broken without spi tracing
<marcan>
also oh god just looking at the diff context for that applespi.c makes me cringe
<marcan>
such a mess of ACPI stuff mixed in there
<marcan>
we definitely want to rewrite that as a HID transport properly (and someone else can add the bits to make it work with ACPI laptops too and then we can deprecate applespi in the future)
<marcan>
but for now let's see if it breaks because of a driver problem or a SPI problem...
<jannau>
touchpad seems to need more delay than I currently have. broken both with bare metal and hv without tracing
<marcan>
[ 0.709687] applespi spi1.0: Received corrupted packet (crc mismatch)
<marcan>
[ 0.716454] applespi spi1.0: Unknown touchpad model 0 - falling back to MB8 touchpad
<marcan>
that, right?
<jannau>
on applespi side it presents received spi data as 0x00
<jannau>
not sure but I see those two messages with spi tracing and working touchpad
<marcan>
that sounds like there's more than one problem
<kettenis>
there are some packets that get sent early one that I haven't been able to give a meaning to
<marcan>
I seem to have working touchpad with that branch as-is
<marcan>
on the M1 Pro
<marcan>
HV, no tracing
<jannau>
increasing SPI_END_CS_DELAY_US in applespi to 100 fixes the touchpad on baremetal
<marcan>
keyboard too
<jannau>
caps lock led still breaks it but that ought to be an applespi problem
<jannau>
keyboard seems to be more reliable
<marcan>
let me actually try the touchpad (I was just catting the device)
<marcan>
so the *unused* spis on the mac mini get set to 120MHz, heh
<marcan>
I wonder if this is actually an oversight...
<marcan>
also it feels really weird that #5 is 120 for spi2/3/4 but not spi1
<marcan>
maybe they actually forgot to initialize that clock in iBoot (but it works anyway because the spi driver does the right thing wrt divider)
<kettenis>
well, if the input frequency isn't 24MHz but 200MHz the actual SPI clock frequency won't be what I think it is
<marcan>
200MHz is only used for spi1 as far as I can tell
<marcan>
for spi3 we have either 24 or 120 apparently?
<marcan>
but my point is the spi driver should be computing its divider based on this information
<marcan>
now the question is is it 120 on the air too...
<kettenis>
of course I copied the spi-max-frequency property from corellium
<marcan>
spi-max-frequency is something else, isn't it?
<marcan>
that's a max, not the base clock
<marcan>
the base clock comes from the clock provider
<marcan>
but the clock being 5x faster by accident on j293 would explain why it's breaking for people
<kettenis>
spi-max-frequency is the max frequency the spi device can run at if my understanding is correct
<marcan>
yes
<kettenis>
spi-max-frequency = <2000000>;
<kettenis>
that is what I have
<marcan>
yes, and if your clock provider is claiming the controller is clocked at 24 when it's actually at 120, then you're driving the device at 10MHz instead of 2MHz
<marcan>
which is bound to cause some issues :-)
<marcan>
let me try the m1 air...
<kettenis>
your gpiola.py stuff can actually measure the clock frequency?
<marcan>
sure, it's timed
<marcan>
just capture it and eyeball it in gtkwave by selecting a range of cycles
<marcan>
it's a real logic analyzer with proper delta compression ;)
<marcan>
(some call it RLE)
<kettenis>
I'll need to fugure out how to use it ;)
<marcan>
ok, at least it's badly broken on the m1air, much more than the pro
<kettenis>
also, how did you figure out which gpio pins are used?
<marcan>
let's look at pmgr
<marcan>
the CS pin is specified in the ADT, I guessed it was nearby pins. that worked for spi3 but not spi1, for spi1 I spammed the RegMonitor during a SPI transaction until I saw something change
<marcan>
that found me the two disjointed pins
<marcan>
you could also just trace, like, all pins in groups of 32 (the analyzer supports up to 32)
<kettenis>
the adt doesn't actually provide the equivalent of spi-max-frequency for the spi devices isn't it?
<marcan>
cs-gpios should work, but then you need to pinconfig it to 0 instead
<marcan>
since it defaults to 1 on these machines
<kettenis>
I think we should not add cs-gpios if we want to use hardware cs control
<marcan>
correct, but what I'm saying is software CS control should work too
<marcan>
but then you need the pinconfig; without that it tries to use software CS control while the hardware is the one actually owning the pin
<marcan>
which is why none of this was working a minute ago, CS wasn't changing
<kettenis>
right
<jannau>
thanks, fix pushed
<marcan>
jannau: were you testing on t6k or t8103?
<jannau>
I'm testing on t6000-j314c, I have no t8103 laptop
<marcan>
ack
<marcan>
I'll go back to t6k since that's where I have a root partition for X, but hopefully those DT changes were the only difference that matters on t8103
<kettenis>
so the 24/120MHz difference suggests that we can actually use a 10MHz spi-max-frequency on t8103-j293
<marcan>
does that work?
<marcan>
I mean it was broken due to the CS anyway
<jannau>
I'm not sure how much time we should spend on applespi. I'll work on the spi hid transport this weekend
<j`ey>
marcan: im happy the air is getting some attention ^_^
<marcan>
I mean I want all the machines to work :-)
<j`ey>
yeah but it was always the mini you worked on, then the t6000 :P
Andre[m]1 has joined #asahi-dev
<marcan>
yeah, because a lot is shared
<marcan>
but now that things are starting to come together I do want to test stuff on all of them and fix whatever's broken :)
<kettenis>
interface 3 and 4 only provide vendor-specific stuff
<kettenis>
so the descriptors don't tell us very much
<marcan>
oh derp it's in the firmware
<marcan>
so I guess the device reports its own properties
<marcan>
just running `strings` in the firmware yields a giant plist
<marcan>
wait no
<marcan>
this "firmware" *is* the plist
<marcan>
and it includes the actual firmware and more stuff inside
<marcan>
what
<marcan>
... so where is this stored?
<marcan>
/System/Library/AssetsV2/com_apple_MobileAsset_SFRSoftwareUpdate/e1e322bee87acc15973794a58f6e551734c82adf.asset/AssetData/boot/Firmware/J293_Multitouch.im4p for one... but surely it doesn't get it from there
<FireFox317>
apple really do like firmware, doesnt it
<kettenis>
no real surprise that the descriptors are contained in the firmware
aleasto has quit [Remote host closed the connection]
Gaspare has joined #asahi-dev
<j`ey>
Im getting what seems to be recursive exceptions when trying to use linux.py, anyone else seeing this?
<j`ey>
nevermind, I forgot to chainload
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
j`ey: why going back to 24?
<j`ey>
marcan: because I misunderstood what you said before
<marcan>
I was talking about t6000
<marcan>
but if that works then I guess it can handle 30MHz lol?
<marcan>
ok, confirmed with spi.py, the CLKDIV is not -1 and the minimum is 2
<kettenis>
so you end up with 200000000 / CLKDIV on the t6000?
<marcan>
no, 24MHz / CLKDIV
<kettenis>
ah for spi3
<marcan>
ah yes
<marcan>
for spi1 it would be 200M, yes
aleasto has joined #asahi-dev
yuyichao has joined #asahi-dev
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
yuyichao has quit [Ping timeout: 480 seconds]
mini_ has joined #asahi-dev
<marcan>
ok, got gpiola running on the hypervisor while running linux; I can't see the signals accurately at 8MHz, but I can tell the CS to clock delay isn't being correctly implemented
the_lanetly_052___ has joined #asahi-dev
mini_ has quit [Quit: ZNC closing...]
<marcan>
... because applespi calls applespi_setup_read_txfrs before applespi_setup_spi, which is what sets the cs delay value