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
ddxtanx has quit [Remote host closed the connection]
john-cabaj has joined #asahi-dev
ddxtanx has joined #asahi-dev
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
DannyB has joined #asahi-dev
hexdump02 has joined #asahi-dev
hexdump01 has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-dev
tobhe_ has quit [Ping timeout: 480 seconds]
skipwich has quit [Remote host closed the connection]
skipwich has joined #asahi-dev
john-cabaj has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
ece314378925355451680698427415 has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
john-cabaj has joined #asahi-dev
nora_ has joined #asahi-dev
nora has quit [Ping timeout: 480 seconds]
skipwich has quit [Ping timeout: 480 seconds]
skipwich has joined #asahi-dev
john-cabaj has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
al3xtjames2 has joined #asahi-dev
al3xtjames2 has quit [Quit: al3xtjames2]
al3xtjames2 has joined #asahi-dev
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
ravikant_ has joined #asahi-dev
ece314378925355451680698427415 has quit [Ping timeout: 480 seconds]
<chaos_princess>
anyone knows how to tell the kernel to not light up a core cluster unless necessary?
<sven>
ah well. i'm starting to remember the tbt mess now. acio depends on the iommu but the iommu only works once acio is at least partially up. this is going to be fun 🙃
<chaos_princess>
kinda like with aop and admac where aop wants to do admac power management itself
<sven>
it's gonna be rather annoying to represent this in the device tree
<sven>
how did you solve aop and admac?
<chaos_princess>
removing all register accesses from probe
<sven>
this gets extra complicated because i have to shut down the iommu again before i shut down the PHY
<sven>
but maybe i can do something similar. just have to check if there's a point in the iommu api where i can trigger that deferred probe and the shutdown again
<jannau>
chaos_princess: how is the kernel to decide necessary? Are you looking into some sort of CPU idle management which tries to keep an entire cluster idle? i.e. keeps one of the perf core cluster idle on t60x0 when only 4 perf cores are used
<chaos_princess>
yep
<chaos_princess>
i am not even fully sure what "necessary" means, kinda hoped android already has some solution, but probably to not light up the second p-cluster if utilization of the first one is below some threshold
<jannau>
I'd not be surprised if android has some out of band management for that otherwise I'd expect that's something the scheduler needs to handle
<chadmed>
android has a litany of insane schedulers that all do weird shit incompatible with upstream
<chadmed>
i think what youre after is probably the job of EAS and a cpuidle driver working in concert
<jannau>
is it acceptable to add bcm4388 to brcmfmac's dt-bindings without driver support?
<chaos_princess>
iirc bindings need either a driver, or a tree that uses them
<chadmed>
unfortunately i dont think EAS has any smarts in it to deal with clusters sanely
<sven>
should be fine, we also got those gpu bindings upstream and only chaos tree is using them so far
<sven>
after all the bindings are supposed to just describe hardware...
<chadmed>
according to some theyre not even supposed to do that :P
hdbngr has joined #asahi-dev
<jannau>
I have the wifi node in the t602x DT submission so the compatible is used (and causes dtbs_check complaints if it's omitted from the bindings)
<chaos_princess>
it should be ok then
<sven>
yeah
<kettenis>
jannau: at some point we need to discuss the power control for the wifi chip with upstream
<jannau>
I missed that. That would require driver changes as we would have to add :apple,t8110-dart" to the driver to use compatible = "apple,t6020-dart", "apple,t8110-dart"; in new device trees
<jannau>
I'll ask for a clarification
<sven>
ack
<sven>
i think dart is actually fine because there's no "apple,dart" fallback
<sven>
but he may want something like "apple,t6020-spi", "apple,t8103-spi" instead of "apple,t6020-spi", "apple,spi"
<chaos_princess>
does anyone know anything about "ioa-parent" (it is dart and maybe pmgr related)
<jannau>
no. looks like mmio addresses but the trailing 31 zeros are suspicios
<chaos_princess>
it is a mmio address, and it writes there
ravikant_ has joined #asahi-dev
john-cabaj has joined #asahi-dev
nafod has quit [Ping timeout: 480 seconds]
<kettenis>
jannau: do you remember where? We have pwren-gpios in the PCIe port nodes, but that got NACKed IIRC
<jannau>
the driver code is D3 handling. i.e. completely unrelated
<jannau>
why did I think we had the pwren-gpios in in the dt-bindings? I looked for mac pro support where it's more complicated due to the pcie switch
<jannau>
linux has since a while a PCI slot power control driver.
<jannau>
that alone is not enough since it needs to be synchronized with port probing
<nickchan>
ill post a patch that fixes the sart binding description I guess
<sven>
nah
<sven>
it's about the commit description
<nickchan>
the existing binding description does say it is incompatible though so I don't get where the "unusual" thing come from
<nickchan>
(the only? difference between sart v0 and v1 is differences in the config flags)
<sven>
he might've only read the patch. i can still adjust the commit description since i haven't send out the pull request yet
<kettenis>
sigh, oh well, I guess I just give up
<sven>
mood
<sven>
let's add least add back the generic compatible inside m1n1
<kettenis>
just keep shipping the device trees I have now and see what needs to be done in a year when they've finally decided what shade to paint their bikeshed in
<jannau>
I'll re-add the missing generic compatibles for t6020 in m1n1. for all I care we can leave the code in m1n1 forever
<sven>
we'd probably forgot to remove it even if we planned to do it 2 years from now tbh
<nickchan>
sven: how about the content of the sart binding commit? I can send a fixed version.
<sven>
what content needs to change? i can always back up the full commit and replace it with another one
<nickchan>
The binding description
<sven>
oh, it doesn't already mention SARTv0 but only 1,2 and 3?
<nickchan>
sven: right and a14 has sartv1
<nickchan>
not v2
<sven>
hrm
<sven>
let me think about it, but i could also just replace the entire commit
<nickchan>
i am thinking about replacing the entire commit as well
<jannau>
I'll use M1 as base compatible (if applicable) as that's what the driver was written for
<sven>
jannau: ack
<sven>
nickchan: some part of me just wants to be like "oh well, the commit is already upstream, too late" tbh :D
<sven>
let me reply to him on the weekend, then we can figure out what we'll do
<jannau>
let's see if there's a significant runtime impact of patching the whole DT. that might remind us of removing it
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
<sven>
do we already increase the cpu frequency to maximum inside m1n1? :>
<nickchan>
no
<nickchan>
well not any apple silicon mac socs anyways
<nickchan>
some of the olders socs does use maxed frequency in m1n1
<nickchan>
also looking at the sart0 code that I did submit it looks like the filter entry size is up to... 31-bit?
<nickchan>
APPLE_SART0_CONFIG_SIZE shifted by APPLE_SART0_CONFIG_SIZE_SHIFT
<nickchan>
the config size bits is the range of low bits the hw allowed me to set the bits to 1
<nickchan>
this is also a draft of a possible replacement commit
<nickchan>
well the whole knowledge of sart0 comes from me trying to set the registers in all to 0xffffffffffffffff and see what actually gets set
<sven>
"Add bindings for SARTv0 as found on Apple A11 SoC." -> "dd bindings for SARTv0 as found on Apple A11 SoC, which is incompatible with the previously described versions since it uses a different MMIO layout"
<jannau>
I'm actually not quite about what exactly Krzysztof complains. I don't think generic implementation / version compatibles like "nvme-ans2", "asc-mailbox-v4", "aic2" are uncommon nor did we start with that.
<jannau>
"apple,spi" wasn't a good idea and in our case having just the unrelieable information from the ADT is an argument for only using SoC specific ones
<nickchan>
there's at least two incompatible variants for the spi
<nickchan>
one found on Samsung S5L8700 all the way to T8030 and another one found since T8101
<kettenis>
but that's a samsung hardware block, not an apple one
<jannau>
the samsung one wouldn't use "apple,spi" though
<nickchan>
the new one is still based on the old one
<nickchan>
it'd just be apple,s5l8960x-spi most likely
<nickchan>
maybe I should look at whatever the ipod linux people are doing
<sven>
jannau: yeah, i dunno, but not a fight i'm willing to fight. i think with nvme the mistake was just nvme-ans2 while the controller is actually nvme-ans3 on the M!
<sven>
*M1
<chaos_princess>
just to be thorough, i assume we don't care about fabric and ecc errors, right?
<sven>
what did you run into? :D
<chaos_princess>
pmgr turns on error reporting on a bunch of fabric bits, and then... idk, i have no idea how to decode fabric errors as i can't observe them :P
opticron has quit [Read error: Connection reset by peer]
opticron has joined #asahi-dev
<sven>
ah, in that case it sounds like a curiosity but nothing i'd spend time on right now
ravikant_ has quit []
<jannau>
I'm troubled by writing a justification beyond "we agreed to not use them" for the commit messages
<jannau>
I'm annoyed but not annoyed enought to fight it either
<sven>
yeah :/
<sven>
maybe put a link to the thread in there?
<sven>
"After discussion with the devicetree maintainers we agreed to not extend the list with the generic compatible anymore [1]"
myrrhk has joined #asahi-dev
myrrhk has quit [Remote host closed the connection]