al3xtjames has quit [Read error: Connection reset by peer]
al3xtjames has joined #asahi-dev
bps3 has quit [Remote host closed the connection]
bps3 has joined #asahi-dev
bps3 has quit [Ping timeout: 480 seconds]
c10l7 has joined #asahi-dev
c10l has quit [Ping timeout: 480 seconds]
amw has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
yuyichao has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
yuyichao has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
nicolas17 has quit [Quit: Konversation terminated!]
<nametable[m]>
Can someone point me in the right direction as far as how to use the existing documentation. For example, lets say I'm interested in turning the backlight on/off (and then researching to figure out how dimming works). Where in the documentation that is available so far can I find the register address which corresponds to m1 macbook air backlight?
kov has quit [Quit: Coyote finally caught me]
<jannau>
rqou_: problem seems to be "nvme-apple 393cc0000.nvme: ANS did not boot". I've seen nvme (and usb) failures with broken DCP but never looked closely at them since the problem was clearly DCP. Although I'm still wondering how DCP can break nvme
<jannau>
nametable[m]: there is no documention. I'm not sure if anyone has checked but the expectation is that backlight is controlled through DCP
<jannau>
to inestigate that further you have to look at dcp traces (hv/trace_dcp.py) from running macos under m1n1's hypervisor
<rqou_>
huh i'm definitely surprised that DCP can break nvme, but i guess it's "fine" for now
<rqou_>
my workaround seems to consistently win the race condition
<rqou_>
just something to note for further investigation
<rqou_>
no, i mean things like "sven's 4k patch" or "sven's atcphy"
<rqou_>
or the DCP driver
<rqou_>
rn i have my own branch that's an ad-hoc merging of features i've tried out
<jannau>
not in a central place
<jannau>
rqou_: it's entirely possible that it is the same race and broken dcp results in strange looking rtkit behavior for dcp but still unsure how that can break nvme
<rqou_>
yeah i dunno
<rqou_>
i definitely observed e.g. m1n1 hypervisor debug printing affecting the race
<sven>
DCP needs to move to the raw iommu api
<sven>
that fixes the usage of that weird function
<sven>
other than that, the nvme bug is that ANS fails to boot and then my error handling apparently sucks
<sven>
I don’t understand why it would fail to boot though just because DCP does something
chadmed has quit [Read error: Connection reset by peer]
<Dcow[m]1>
where is t8110 dart used ?
kov has joined #asahi-dev
<sven>
thunderbolt and some other things on the t600x
<Dcow[m]1>
but not in regular M1 ?
<sven>
no
<sven>
otherwise I would’ve already written support for it ;)
<Dcow[m]1>
do you have only regular M1 devices?
<sven>
yes
<Dcow[m]1>
do you have github sponsors?)
<sven>
no, and that’s quite intentional :)
<sven>
once people start paying money to me it feels like a day job and I already have one of those :)
<Dcow[m]1>
nah, that's the night one xD
<sven>
:D
<jannau>
sven: any progress on getting the t6000-dart merged in linux? would it help to ping the patch? we should try to get it into 5.19 together with basic t600x device trees
<sven>
haven’t heard anything from the last time I pinged robin
<sven>
we should also figure out if the bit that used to be “disable subpage protection” actually is “mark this page as uncachable”
<jannau>
ok, I'll ping it tonight
<jannau>
it appears t6000 and t8110 share the same PTE layout assuming the offset mask 37,10 in the kernel patch is correct and the 39,10 offset in m1n1 is an oversight
<sven>
given that "disable subpage protection" no longer works I'm willing to bet that bit means uncachable as well
<sven>
would still be good to confirm that somehow
<sven>
and then fix the kernel patch to not set that for everything.. but ugh...
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<sven>
might be too many differences to the arm pagetable format at that point for robin
<jannau>
the ARM_MALI_LPAE page table format seems to have also a different use for BIT1)
<sven>
ah, good
<jannau>
read write protection bits also differ between between t8110 and the defines for t8103 in the kernel
<sven>
hrm... if that bit is indeed uncachable but the same page is mapped as normal memory for the CPU shouldn't that break horribly?
<sven>
unless the cache somehow snoops those DART transactions I guess
<Jamie[m]1>
fyi rqou_ I'm getting sane results with that t8110 implementation from the AVD
<Jamie[m]1>
and i now understand 1% more of the avd interface :P
chadmed has joined #asahi-dev
jonaburg[m] has joined #asahi-dev
tardyp has quit [Read error: Connection reset by peer]
tardyp has joined #asahi-dev
caef^ has quit [Remote host closed the connection]
<kettenis>
sven: you mean the cache would still snoop DART transactions, but DART transaction would no longer consult the cache?
<sven>
yes, but dunno if a setup like that would make sense
<kettenis>
doesn't make sense to me, but that doesn't carry much weight ;)
<kettenis>
note that our device trees don't have dma-coherent attributes, which I think that Linux does all the appropriate cache flushing and invalidation
<sven>
at least for dma_alloc_coherent buffers it shouldn't do any cache maintenance
<sven>
but let me check again
<kettenis>
by allocating those as non-cached in the first place?
<sven>
last time I looked into this I convinced myself that for devices with an iommu those would just be normal memory
<sven>
but let me check that again because it's been a while
<kettenis>
that's effectively what I do for OpenBSD (force the flag that tells the core code DMA is cache coherent in the DART driver)
<kettenis>
but nvme doesn't use the DART for example
bisko has joined #asahi-dev
<sven>
true
yuyichao has quit [Ping timeout: 480 seconds]
<emilytrau[m]>
Hey devs! I'm working on adding Asahi linux support to the NixOS installer. What would be a reliable way to detect if we're on an Asahi system? So we can include support in the generated config
<j`ey>
emilytrau[m]: you should talk to tpw_rules
atsalyuk has joined #asahi-dev
<emilytrau[m]>
We're trying to get upstreamed. Using his amazing work as the base!
<emilytrau[m]>
*upstreamed into nixpkgs
<kettenis>
sven: On OpenBSD I couldn't really detect any performance benefits of skipping the cache flushes, but that may just be because the CPUs are too fast
<kettenis>
still, I think we need to sprinkle some dma-coherent properties into the device trees
<sven>
yeah, agreed
<kettenis>
for OpenBSD a single one on the /soc node would be enough, but I'm not sure that works for Linux
<sven>
I think it should, I remember seeing some of_ code that just tried walking up to the root to look for dma-coherent
<maz>
kettenis: if the system is always coherent (which is likely since the CPUs implement FWB), then the CMOs may well be implemented as NOPs.
yuyichao has joined #asahi-dev
<j`ey>
emilytrau[m]: you could use `strings /proc/device-tree/{model,compatible}`, not sure if there is a standard interface for that
<kettenis>
the "compatible" property should be the definitve answer
atsalyuk has quit [Ping timeout: 480 seconds]
linuxgemini9 has quit [Remote host closed the connection]
linuxgemini9 has joined #asahi-dev
atsalyuk has joined #asahi-dev
doggkruse has joined #asahi-dev
linuxgemini95 has joined #asahi-dev
linuxgemini9 has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
<sven>
looks like pcie hotplug is actually pretty simple: when a LINK_UP interrupt is received tell the pci subsystem to re-scan, when LINK_DOWN is received remove the devices and finally poke that LSSMCTL bit again to be able to catch the next LINK_UP