ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
newiz has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
user982492 has joined #asahi-dev
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
hightower4 has joined #asahi-dev
user982492_ has joined #asahi-dev
hightower3 has quit [Ping timeout: 480 seconds]
user982492 has quit [Ping timeout: 480 seconds]
gabuscus has quit []
___nick___ has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
gabuscus has joined #asahi-dev
kettenis has quit [Remote host closed the connection]
<jannau>
where did we get the SPI pins from? I'm trying to hook the touchbar touchscreen and we don't have the pins for spi3
<jannau>
on t8112
<marcan>
monitoring GPIO registers with regmon or gpiola while messing with SPI
<marcan>
I need to do that for the NOR SPI on t602x...
<ChaosPrincess>
On t8103 i randomly guessed them by getting the cs pin from adt and taking 4 pins down from that.
<ChaosPrincess>
Might also work for t8112
<marcan>
I think if you guess wrong it will still work but might mess something else up...
raveling has quit [Ping timeout: 480 seconds]
<jannau>
oh, you don't have any SPI0_PINS in the touchbar PR just cs. that works on t8112 as well
<jannau>
sddm associates the touchscreen with the main display
<jannau>
and so does kde
<jannau>
kde has configuration to set the target display
<jannau>
ChaosPrincess: the touchbar turned out more popular than I assumed judging by the reaction on my posts yesterday
raveling has joined #asahi-dev
<psykose>
it might sound stupid but i never really thought of that being good
<psykose>
using that touchbar thing on my girlfriends laptop made me want to hit walls
<psykose>
and this makes it.. more useful...
<psykose>
truly incomprehensible :p
<ChaosPrincess>
I had a work-issued intel macbook from before they got a hardware esc key. Now _that_ was terrible :P
<chadmed>
it could have been cool but not as a total replacement of real F keys, and no developers took it up except ones paid by apple to do so
<chadmed>
using it for a plasma panel is a neat idea thoug h
<ChaosPrincess>
chadmed: Yea. And the macos api for it isnt great.
<psykose>
ChaosPrincess: yeah, my girlfriends has touchbar esc
<psykose>
i think she's a psychopath at this point tbh
<marcan>
I think we don't actually need to set the extra pinmuxes
<marcan>
only CS since we do use that one differently from Apple (I think they use direct GPIO for that instead of the native CS?)
<marcan>
anyway I confirmed the spi1 pins on t602x
<marcan>
I guess I might as well do spi2 and spi4
<ChaosPrincess>
I use cs as gpio in the z2 driver too.
<marcan>
why?
<ChaosPrincess>
Dont remember exactly why, think using it from the controller didnt work or sth
<marcan>
hm
<marcan>
did you set the pinmux properly?
<marcan>
setting that one way will work with gpio, the other way with spi
<ChaosPrincess>
Dont think so
raveling has quit [Ping timeout: 480 seconds]
<jannau>
you use it just for "cs-gpios". that seems to be a well establish dt property and seems to get picked up by gpiolib-of for us
<jannau>
maybe not
<jannau>
no, I see it's manually handled in the driver
<ChaosPrincess>
Well, thats just me being bad at writing drivers :P i since got told that i should move it to the parent dt node, and rip out all the manual code and it will be done automatically
<kettenis>
figured out that the board function to fixup the device tree runs before just before u-boot adds the initrd properties for an initrd it loaded itself
raveling has joined #asahi-dev
<kettenis>
so deleting the initrd properties there is good enough
<kettenis>
pushed to the t6020 branch
newiz has quit [Quit: Konversation terminated!]
<marcan>
pushed the SPI DTs to t602x/bringup
raveling has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: so your idea was for the installer to build a separate cpio with selected firmware for u-boot?
<kettenis>
and then cat that to the back of the boot.bin after unpacking the zip file on the ESP?
darkapex1 has quit []
darkapex has joined #asahi-dev
raveling has joined #asahi-dev
<jannau>
ChaosPrincess: have you checked if the 200m clock is correct for the touchbar spi? according to macos logs it uses a 24 MHz clock on j493
<marcan>
kettenis: yup
<marcan>
same with the distro scripts that do updates
<marcan>
jannau: it should be 24m, that's cargo cult copypasta from the nor spi
<kettenis>
to make sure the ethernet address on j474 is populated
<marcan>
good catch
<marcan>
fixed
<kettenis>
thanks
raveling has joined #asahi-dev
nsklaus has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
<marcan>
povik: reproduced the cs42l83 issue that altdistros are hitting. it clearly has to do something with kernel config, timing, or something like that.
<marcan>
and it is related to clocking and clock switching
<marcan>
going to try to fix it
kit_ty_kate has quit [Quit: WeeChat 3.6]
<kettenis>
the cs42l83 is a bit quirky and needs to have the SCLK running before switching away from the internal oscillator
<kettenis>
otherwise you loose i2c access
<kettenis>
it is not clear to me what bits in the MCA actually turn on the SCLK
raveling has joined #asahi-dev
<marcan>
povik: we are disabling the MCA clocks before muting the codec
<marcan>
kettenis: it's a logic issue
<marcan>
and it's just broken, it pulls the clock before switching off so it never had a chance
<marcan>
I suspect the clock shutdown might take a while or there is some other timing nuance that makes it work for my usual kernel builds, and also it works for me the first time on my repro kernel
<marcan>
but it's definitely broken
raveling has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
<jannau>
marcan: did you test dockchannel/mtp with 13.3? it's broken on the j493. one obvious problem is that the sram requested by rtkit is 2 pages further down. but even after adjusting the sram size in the devicetree it is still broken without error logged
<jannau>
driver core complains about failing to create a device link to the smc gpio but that appears also with 12.3 and working mtp
<jannau>
probe succeeds but it looks like no packets arrive
<marcan>
jannau: you're right, it's broken :/
<marcan>
wait sec, sram first
<jannau>
just double the size
<marcan>
I made it cover everything, looks like it's 1MiB
<marcan>
jannau: yeah it's broken :/
<marcan>
I'll figure it out
<marcan>
jannau: it's oslog
raveling has quit [Ping timeout: 480 seconds]
<marcan>
we need to actually implement that properly
roxfan has quit [Ping timeout: 480 seconds]
<jannau>
kettenis: linux boot works now with firmware "initrd"
raveling has joined #asahi-dev
<kettenis>
cool
<jannau>
let's see if I can refactor the linux driver to make the link up check not as ugly as it is now
hightower4 has quit []
cylm has quit [Quit: WeeChat 3.6]
<kettenis>
u-boot doesn't do any interrupt setup (since it doesn't use interrupts)
<kettenis>
so that still has to happen in the linux driver
<kettenis>
and that includes MSIs
<marcan>
jannau: also the mtp protocol init message parsing was wrong
<marcan>
fixing that
cylm has joined #asahi-dev
<jannau>
yes, it is intertwined with the other port setup stuff. I currently just added 'if link up's which makes the code hard to read/follow
<marcan>
does anyone remember what we added oslog for? the current behavior seems patently wrong as far as MTP goes, but I have no idea why it's there at all
<sven>
i vaugely remember someone adding it to get some co-processor to boot (or not hang after a while)
<jannau>
I think I added it for dcp. iirc it just needed to be started
<marcan>
I don't see oslog in my most recent dcp log
<kettenis>
my OpenBSD commit messages says it was for NVMe
<marcan>
nvme does have the endpoint
<marcan>
however it sends no messages
<marcan>
so I have no idea where the logic came from
<marcan>
it's not implented in u-boot though
<kettenis>
which probably means that starting the endopoint for NVMe isn't necessary
<jannau>
in my logs I see endpoint 0x8 for dcp in 12.3, 12.4 and 13.2. it's gone in 13.3
<marcan>
ha.
<marcan>
however, I still see no messages in my old DCP logs
<sven>
ohh... didn't jannau (?) notice that the endpoint was also required for nvme in some firmware version?
<sven>
maybe that's where that nvme comment comes from :D
<marcan>
but u-boot doesn't implement it...?
<sven>
maybe nvme just hangs after a while if it's not started?
<sven>
it does that for syslog
<sven>
dunno, it always worked without oslog for me but I don't even know what firmware I'm running
<marcan>
I'm just going to remove it from m1n1 and we'll see if anything breaks :p
<marcan>
OTOH it will need to be added to u-boot for MTP...
<jannau>
t8112 dcp on 12.3 works without starting oslog
<marcan>
12.4 you mean?
<jannau>
but based on the time I added it it would have been required on m1 with macos 12.x with x < 3
<jannau>
err, yes. 12.4
<marcan>
yeah, so we can drop it then
<kettenis>
marcan: we don't use the ltssmX regs anywhere in the PCIe drivers
<kettenis>
is there a good reason to add them anyway?
<kettenis>
(I'm considering submitting the bindings upstream to prevent myself from getting burned again)
<marcan>
didn't I drop that?
<marcan>
m1n1 uses it for what looks like a bug workaround which *may* be needed in linux eventually but I'm not sure, we can always add it later
<kettenis>
unless I missed something the regions are still defined in t602x-die0.dts
<kettenis>
but I won't include them in the binding for now
<marcan>
jannau: pushed m1n1 and the bringup branch, mtp should work now
<marcan>
the change was backwards-compatible, I had just misinterpreted the protocol
<kettenis>
I'd better fix that on the OpenBSD side as well then
<jannau>
marcan: m1n1 breaks on j274 without oslog (12.3)
<marcan>
jannau: how does it break?
<jannau>
seems to be dead after display init. I removed it completely though, i.e. not even starting the endpoint
<ChaosPrincess>
marcan: is there a way to make m1n1 reliably survive sleep
<marcan>
no idea
<marcan>
jannau: seems to work for me with what's in m1n1:main (drop the logic, keep the ep start)
<marcan>
haven't tested it as stage1 though
<jannau>
yes, works with main. without it I need to power cycle it. it's still dead after power cycle via usb-pd
<jannau>
or at least m1n1's uart and usb are still dead
<marcan>
it's like the other buffer requests except the field defs are different and the address is in 4K pages
<kettenis>
marcan: strange though it's like they made more space for the address
<kettenis>
and then decided it wasn't enough and made more space by shifting the address
<marcan>
yeah, it's weird...
<marcan>
they already had 44 bits, which is enough for current machines with up to 42-bit address space everywhere
<marcan>
oh yeah, APPLE_RTKIT_BUFFER_REQUEST_IOVA should be 43, 0 (you don't care, only the GPU cares about those high bits, but just out of technicality)
<marcan>
(the GPU sign-extends so it needs the high bit)
<marcan>
also I guess I should fix mtp there too
<marcan>
I can do that one
<marcan>
oh actually, don't need to
<marcan>
we don't even parse that stuff in u-boot
<kettenis>
heh
<marcan>
they did increase the init message lengths though, I hope we aren't going to overflow the fifo with our trick for that...
<kettenis>
we still have to get the mtp stuff in u-boot upstream at some point...
<kettenis>
but that is best done once we have bindings
<marcan>
nah, we're still good for the size, as long as they don't double it
<marcan>
and yeah, I need to clean up the shutdown path and submit this to linux, *however*, I'm partially slacking on that on purpose so we can figure out the Fn key story
<marcan>
because right now the keyboards don't work *at all*, which means doing whatever I want with Fn is not a regression
<marcan>
if we add this driver, I think the keyboard will work to some extent even without other patches, and then we might end up in trouble
roxfan has joined #asahi-dev
<marcan>
OTOH I could just upstream the keyboard stuff with the no Fn emulation idea to begin with, even if we still carry downstream patches to add emulation until the xkb stuff is ready
<jannau>
yes, it should be handled by the default HID keyboard support
<marcan>
if it's just the default keyboard it's fine, it won't match the apple one nor do Fn emu
<marcan>
so yeah, I guess this doesn't block dockchannel
<marcan>
spi though, I think that would get matched already?
<jannau>
I don't think so. iirc the product ids are unique even if the vendor id would matches across different busses
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
gabuscus has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
<povik>
ugh. tweaking asoc ordering...
<povik>
marcan: how did you check hw_free indeed happens before the mute?
<povik>
i thought hw_free is symmetrical to prepare, where we turn on the clocks
<povik>
so that the way it was makes sense
<povik>
also i am not sure
<povik>
* not sure 'shutdown' is ever called, usually
<povik>
unless the driver is unloaded
<marcan>
povik: I added WARN_ON(1) to get stack traces and printks to log what is happening
<marcan>
shutdown is called when the device is closed
<marcan>
hw_free is symmetrical to hw_params AIUI
<povik>
16:55 <@marcan> shutdown is called when the device is closed
<povik>
ah, you are probably right
<povik>
16:55 <@marcan> hw_free is symmetrical to hw_params AIUI
<povik>
that would still mean it's ok to turn off the clock there since hw_params happens *before* prepare
<povik>
though maybe pmdown_time messes up the ordering
<marcan>
hw_free is an ioctl that userspace can send at any time AIUI, and which does not trigger a mute
<povik>
not after prepare
<marcan>
so if you want to do it that way the codec drivers would have to mute on hw_free too (I think some do)
<marcan>
well it is calling it after prepare :p
<povik>
err, i though you wrote hw_params
<marcan>
hw_free is getting called from the ioctl path, while the mute and later shutdown are getting called from the device close path
<marcan>
so clearly hw_free alone isn't going to work unless we add an explicit mute path in there
<marcan>
I won't claim to know what the "right" thing is here but that's what's happening right now
<povik>
right
<povik>
mute can happen after hw_free so it's broken
<povik>
i will look at this more later
<kettenis>
I don't see any oslog messages on my machines (all with 13.2 or even older firmware)
<marcan>
povik: cs43130.c has a hw_free callback that switches to internal clock, so maybe that's the right way
<marcan>
but on the other hand, I sure would expect a mute to happen before that anyway
<povik>
yeah, maybe that pmdown_time i mentioned is what causes mute to happen later
<marcan>
yeah, that would make sense
roxfan has quit [Ping timeout: 480 seconds]
chipxxx has joined #asahi-dev
<jannau>
stage 1 m1n1 is broken with 13.3.1: "rtkit(dcp): unknown oslog message 103ff8000f0025f"
<kettenis>
so it is sending a message with a pre-assigned address?
<kettenis>
this is on m2?
<kettenis>
(t8112)
<sven>
bah.. so either the fuses need to be re-applied for thunderbolt mode or I just re-introduced that old bug where the first plug event doesn't work *sigh*
<jannau>
no, j274
<marcan>
OK, so that's what the old logic was for, pre-assigned addresses. so we need to check for dva != 0 and reintroduce the old code.
<marcan>
I wonder what that 0xff8 thing is about though...
sosys has joined #asahi-dev
roxfan has joined #asahi-dev
<kettenis>
but 0xf0025f << 12 = 0x25f000
<kettenis>
which doesn't make sense as a memory address either
<jannau>
that's a dva so we have to lookup what's mapped there
<jannau>
rtkit(dcp): pre-allocated buffer (ep 0x8, dva 0xff8000f0025f, phys 0xbe5bd825f)
<marcan>
needs the left shift
<marcan>
the dva is >> 12 in the message
sosys has quit [Ping timeout: 480 seconds]
<jannau>
err, oslog is probably not the problem. there are two EPIC errors. I ignored them since at least one happens with 13.2 as well
sosys has joined #asahi-dev
sosys has quit [Quit: leaving]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
user982492 has joined #asahi-dev
i509vcb has joined #asahi-dev
zalyx0 has quit [Quit: later alligator]
drubrkletern has joined #asahi-dev
landscape15 has joined #asahi-dev
landscape15 has quit []
c10l has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
newiz has joined #asahi-dev
raveling has joined #asahi-dev
drubrkletern has quit [Remote host closed the connection]
<kaazoo>
Hi, I'm trying out asahi-installer current main branch directly via test.sh on 13" M2 Pro. I switched the m1n1 Git submodule to point to t602x/bringup branch before, in order to have the latest changes. Basic installation seems to have worked, but m1n1 doesn't have required devicetree: "ERROR: Kernel found but no devicetree for apple,j414s available" during boot.