<marcan>
the apcie_st domain fails to add, I left it like that for now. We should probably just have the actual ans driver depend on both instead
chadmed has joined #asahi-dev
leah2 has quit [Remote host closed the connection]
leah2 has joined #asahi-dev
<alyssa>
marcan: to make sure i understand, apple,t8103-pmgr-pstate and the corresponding driver wholly replaces the clock gates driver from sven I'm carrying?
<alyssa>
clk: add support for gate clocks on Apple SoCs
<kettenis>
this also means that "clock" properties of devices such as NVMe and PCIe need to be replaced with appropriate "power-domains" properties
frode_0xa has quit [Quit: leaving]
jbowen has joined #asahi-dev
X-Scale has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
<alyssa>
fun. thanks
<kettenis>
you might be able to get away with keeping the clock stuff and just adding the power-domain stuff if you want to have a DT that works with older kernels as well
skipwich has joined #asahi-dev
<alyssa>
kettenis: no interest in older kernels, just need to know what to splice in and out of my tree
skipwich has quit [Remote host closed the connection]
skipwich has joined #asahi-dev
<kettenis>
heh, then forget what I said
<alyssa>
I love forgetting advice people give me :-p
<tophevich[m]>
Ha, you know what is even better, ignoring your own advice ,_`o`O_,
<marcan>
kettenis: won't work, without the clock driver stuff would fail
<marcan>
(e.g. uart wants working clocks)
<marcan>
but current DTs should largely work with older kernels *if* those devices start out ungated
<alyssa>
marcan: also to clarify this is the same as the pmgr enable /arm-io/foo stuff in m1n1?
<marcan>
(which is the case for UART but not e.g. ANS, though that might change as I'm considering adding pmgr code to m1n1 to clean up after iBoot's stupidity)
<marcan>
alyssa: yes
<alyssa>
got it
<alyssa>
(I have a `u.pmgr_enable("/arm-io/ans")` in my linux.py right now 😅)
<marcan>
yeah, thanks to the magic of the pm framework, you can remove that and just add the domains... except the sample dt right now fails *without* that exact line because iBoot sucks
<marcan>
you can either change the relationship to remove ans2 from the power domains of apcie_st and add apcie_st and ans2 to the power domains of the ans device node
<marcan>
or you can leave that in and just have apcie_st as the only power domain of the ans device node
<marcan>
I think the relationship is BS anyway so might as well just change it, but i'm also considering adding a cleanup pass to m1n1 to ensure everything is consistent
<marcan>
(the problem is the ADT claims apcie_st depends on ans2, yet ans2 is powered down and apcie_st is powered up, which is a contradiction, and Linux' sanity checking catches that)
<marcan>
(the sample DT in my tree right now mirrors the ADT relationships, but I think they're BS anyway)
leah2 has quit [Remote host closed the connection]
leah2 has joined #asahi-dev
<alyssa>
nods
<alyssa>
I have very little confidence in the accuracy of the ADT, it has bullshitted us before and will bullshit us again 🤷
<marcan>
hard to say with the power hardware what's real and what isn't
<marcan>
I know there is some level of true relationships because enabling a child without enabling a parent, in at least some cases, sets an error flag
<marcan>
(not that case)
<marcan>
but it's also not impossible that there are "hidden" relationships, who knows
<marcan>
anyway... it doesn't *really* matter as long as it works
<marcan>
today I did find a relatinship between devices, clocks, power domains, and events and a pile of consecutive registers, which is if nothing else curious
<marcan>
*relationship
<marcan>
if I can at least get *feedback* as things get turned on and off on what real clocks/pds get toggled, that'd be useful
<marcan>
but I have no idea what those registers actually do (something that is somehow homogenerous between all those categories? events is the only thing that makes sense...)
<marcan>
-r
<alyssa>
🤷
<kettenis>
marcan: I think your pmgr driver should only match on "apple,pmgr-pstate"
<kettenis>
the "apple,t8103-pmgr-pstate" compatible is only there as a safety in case the hardware isn't as generic as we think it is
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
quarkyalice__ has joined #asahi-dev
quarkyalice__ has quit [Remote host closed the connection]
maor has joined #asahi-dev
maor26 has quit [Ping timeout: 480 seconds]
jbowen has quit [Quit: leaving]
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
aleasto has quit []
aleasto has joined #asahi-dev
aleasto has quit [Remote host closed the connection]