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
zkrx has quit [Ping timeout: 246 seconds]
<amw>
kettenis1: Where about is your dt-bindings on the wiki - github wiki says no updates for the last week?
<dtantono[m]>
since Ipad support m1 chip. is ipad also supported as well?
phiologe has quit [Ping timeout: 276 seconds]
phiologe has joined #asahi
<opticron>
dtantono[m], no one knows for sure yet as I don't think they're even shipping yet, but it's likely that since the iPad Pro runs iOS that the M1 will be locked down on that platform
<dtantono[m]>
Apple said that the new Ipad will be properly released next month and I think thorough check is needed in this case
<dtantono[m]>
But, it will be interesting if we can dual boot linux on Ipad
<opticron>
I agree, that'd be pretty neat, just unlikely
<marcan>
dtantono[m]: it's locked down
<marcan>
99% sure
<The_DarkFire_[m]>
Pretty sure it’s more of a spec bump then Anything else, it’ll be locked down
<pipcet[m]>
interrupts are often routed through the GPIO controller, yes.
<pipcet[m]>
for example, that's how the keyboard works
Chainsaw has joined #asahi
<kettenis1>
It's just that I don't need them for u-boot ;)
<pipcet[m]>
no keyboard support in u-boot? :-)
<kettenis1>
usb keyboards work
<sven>
that ti usb chip uses a gpio interrupt fwiw
<kettenis1>
u-boot generally uses polling instead of interrupts
<pipcet[m]>
(I still think we should support booting Linux directly from a minimally-intrusive macho)
<pipcet[m]>
yes, you need another GPIO pin to enable the device, and the SPI bus is mapped to GPIO pins as well.
<sven>
you don't need a gpio pin to enable the ti chip
<kettenis1>
is there an actual SPI controller?
<pipcet[m]>
sven: the i2c one? it's rather annoying because the two ports share an interrupt line so if you try booting without SMP support, the corellium code deadlocks because chip0 is receiving interrupts from chip1 but chip1 hasn't registered its isr yet.
<kettenis1>
or do they really use GPIO bit-banging to implement SPI?
<pipcet[m]>
I'm pretty sure there's an actual controller, they use SPI a lot
<sven>
pipcet[m]: yeah, the i2c one. and yes, the corellium code has some, uh, issues
<pipcet[m]>
"some"
<pipcet[m]>
I don't think we need to be overly polite about that part, it's impressive work but does need (at least) cleanup and (quite possibly) rewriting the way you guys appear to be setting out to do
<kettenis1>
anyway, I don't think interrupts would have any implication for the DT bindings
<sven>
there's a AppleSamsungSPI.kext so it might be so samsung variant controller again
<pipcet[m]>
sorry, I meant you need GPIO for the keyboard, not for the typec chips
<pipcet[m]>
the proposed bindings look good to me (though not very different from the Corellium ones), but I think we should use ADT names for the "clocks"/power gates
<sven>
kettenis1: yeah, i think the interrupts would only require an additional interrupt-controller; in there.
<kettenis1>
sven: and an interrupts property of course
<kettenis1>
to mention the AIC interrupts that will be triggered
<sven>
ah, yes :)
<kettenis1>
looks like there is a seperate AIC interrupt for each group of pins
<pipcet[m]>
I think you assign each pin to an interrupt group
<pipcet[m]>
(no idea how free you are to do that, there's probably a horrible table of interdependencies somewhere)
klaus has quit [Quit: leaving]
klaus has joined #asahi
<pipcet[m]>
sven: do you happen to know whether unplugging the charger and reinserting it works if you're still in m1n1?
VinDuv has quit [Ping timeout: 240 seconds]
<sven>
pipcet[m]: i only develp on my mac mini
<sven>
*develop
<pipcet[m]>
oh. sorry :-)
<sven>
can't disconnect a charger there :P
<sven>
it might work after you bring up the TI chip
<pipcet[m]>
it works if I don't bring it up :-)
<sven>
heh, even better
<pipcet[m]>
except the shared irqs mean the second chip's interrupt handler busy-loops until Linux decides it's had enough.
<pipcet[m]>
so I can use the port in gadget mode for about the first minute, and then it stays in whatever connection state it had then.
<pipcet[m]>
* so I can use the other port in gadget mode for about the first minute, and then it stays in whatever connection state it had then.
cshbicos has joined #asahi
<sven>
hm. i need to get back to fixing my dart driver and then just do the whole i2c/ti thing correctly
<pipcet[m]>
Linux or m1n1?
<sven>
linux
<pipcet[m]>
yay!
<pipcet[m]>
there's documentation for a very similar TI chip, but you probably know that :-)
<sven>
alright.. let me document these guarded execution levels and this pagetable permissions rewrite thing apple calls SPRR and then it's back to reading iommu code :)
<sven>
yeah, there's a linux driver for that chip
<sven>
the corellium patch does the important thing (SPSS) and then some strange things that shouldn't be required
<pipcet[m]>
I suspect it's the SPSS that breaks charging though :/
<sven>
try to run proxyclient/i2c.py and see if charging still works
<sven>
it essentially just issues that SPSS command
<pipcet[m]>
will do as soon as I can kexec m1n1
cshbicos has quit [Client Quit]
<sven>
that's gonna be tricky since m1n1 expects to be able to bring up SMP itself
<pipcet[m]>
my inital kernel disables SMP for that reason.
<pipcet[m]>
so I'm running on one (efficiency...) core until the final kernel's loaded, but it's hardly noticeable
<sven>
yeah, the cores are fast enough as long as the MMU is enabled :)
<pipcet[m]>
though now you say that I'm not sure that's actually true, m1n1 does the same thing unless you ask it to bring up the secondaries, doesn't it?
<sven>
yes
<sven>
but it will bring up the secondaries before jumping to linux
<pipcet[m]>
only for Image Linux, not for a macho
<sven>
sure. i only care about linux (or other linux-like images) :)
<pipcet[m]>
that's why I skip m1n1 entirely.
rjeffman has joined #asahi
maknho has quit [Ping timeout: 252 seconds]
maknho has joined #asahi
<pipcet[m]>
can we have two pinmux cells instead of splitting one 32-bit pinmux cell into two 16-bit values?
<kettenis1>
no
<pipcet[m]>
maybe it's more trouble to use pinmux than it's worth, then?
<kettenis1>
why? it is straightforward and already implemented in the generic pinctrl/pinmux code
<kettenis1>
there will be a dt-bingings/pinctrl/apple.h file with macros to build the pinmux cells and pull them apart into pin and func
<pipcet[m]>
we should definitely use pinctrl, maybe I misunderstand what pinmux is for
<kettenis1>
the generic pinmux implementation is just one of the few "standard" ways to implement a pinctrl device
<kettenis1>
most of the other generic approaches require assigning names to the pins
<kettenis1>
that is useful if you have a datasheet for the SoC and.or schematics for a board
<kettenis1>
that's not going to happen with Apple products
<pipcet[m]>
but since we don't, we can just use a pinctrl device and pin numbers?
<pipcet[m]>
the SMC gP pins have "names", if you count gP0b...
<kettenis1>
the SMC is a different device that will need a different binding
<kettenis1>
don't think it has pin muxing capabilities so it would be a gpio node rather than a pinctrl node
maknho_ has joined #asahi
maknho has quit [Ping timeout: 265 seconds]
<pipcet[m]>
true
VinDuv has joined #asahi
thestr4ng3r has quit [Read error: Connection reset by peer]
<pipcet[m]>
sven: i2c.py doesn't work on the USB port Linux used between booting and starting m1n1, but it does work on the other one, and it's still charging when booted into Linux (with the power port removed from the DT) afterwards
<pipcet[m]>
so it's probably a different bug in the Corellium code and not SSPS that's the problem.
<sven>
yeah, that's what i assumed :)
odmir has quit [Remote host closed the connection]