<marcan>
so I'm glad I found the real clock registers :p
<sven>
\o/
<marcan>
but it seems we don't really have to mess with them
<sven>
iirc xnu doesn't even load these clock-frequency-regs property from the device tree
<marcan>
so it mightheh
<marcan>
*heh
<sven>
ohhhh... you figure out how the real registers work. nice.
<sven>
*figured
<marcan>
yeah I used the UART to measure clocks
<marcan>
thanks glasgow autobaud :D
<sven>
hah, nice!
<sven>
still waiting for my glasgow to arrive from that crowdfunding campaign. it's a pity the chip shortage happened just after that
<marcan>
but yeah, the clocks gate automatically depending on the pstate reg configs
<marcan>
so indeed the pstate interface is higher level
<marcan>
yeah...
<j_ey>
so the current clock driver is actually using pstates (0x23b700000 - p-state registers)
<sven>
nice. so essentially most of low-level power management is magic we can essentially ignore?
<marcan>
j_ey: yes, so that's getting rewritten as a genpd driver with 3 pstates (0, 4, 15 in pstate reg terms)
<marcan>
and as for clocks... I'd say we can get away with fixed clocks for everything, seeing as macos touches none of this, even though we kind of now know how the clock selects actually work
<sven>
ok. so for i2c i can e.g. just ignore the "clock gate" that actually a pstate and just add a fixed reference clock?
<sven>
*that's
<marcan>
yeah, I think so
<j_ey>
but it needs some other property?
<marcan>
according to the ADT, the i2c is hardcoded to refclk anyway
<sven>
yeah
<marcan>
yes, it'd reference the genpd stuff
<marcan>
(fwiw, 24M is the xtal frequency)
<sven>
so clocks = <&clk24>; or however it's called just in case they ever connect that to another clock
<marcan>
yeah
<marcan>
thinking of renaming it to refclk perhaps
<marcan>
since we now know it's the root of the clock tree
<sven>
makes sense
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Ping timeout: 480 seconds]
boardwalk has joined #asahi-dev
boardwalk has quit []
boardwalk has joined #asahi-dev
boardwalk has quit []
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
chadmed has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
* alyssa
has been looking at the corellium SPMI code
<alyssa>
been cherry-picking SPMI+RTC and doing low-hanging cleanup (checkpatch --fix is a nice one ;) )
<alyssa>
it's not ready for upstream as-is, but there's nothing obviously wrong with the code that would warrant a total rewrite
<alyssa>
(so I think iterative cleanup on that code, like j_ey is doing with pinctrl, is the way to go)
<alyssa>
the RTC driver is nice and simple
<alyssa>
DT bindings need work but that's more bikeshedding than engineering at that point :)
<sven>
(note that it needs a slightly changed dt instantiation than the code in the tipd-i2c-WIP branch)
<alyssa>
cherry-pick SPMI+RTC and did some basic cleanup
<alyssa>
so ~500 lines of corellium code added to my tree and now real time clock works
<alyssa>
(also, fixed a locking issue. did they not use lockdep?)
<alyssa>
...don't answer that
<j_ey>
I was a bit unsure of some of the locks in SPI too
aleasto has quit [Ping timeout: 480 seconds]
X-Scale has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
X-Scale` has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
<j_ey>
alyssa: can you delete the 'writel(0, pctl->base + REG_LOCK);' line in pinctrl and test pcie?
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
aleasto has joined #asahi-dev
<alyssa>
j_ey: isn't it already if 0'd?
<alyssa>
yeah it's if 0'd in the version I have and pcie works fine
aleasto has quit [Quit: Konversation terminated!]
<j_ey>
alyssa: oh ok, thanks
boardwalk has quit [Ping timeout: 480 seconds]
yuyichao has quit [Remote host closed the connection]
yuyichao has joined #asahi-dev
maor26 has joined #asahi-dev
<marcan>
sven: see pmgr/dev
<marcan>
:)
* marcan
off to sleep
<marcan>
had to add runtime PM support to the samsung uart driver because of course it didn't have it
<marcan>
(I guess nobody needs power management for UARTs...)
<marcan>
but I think this is the right way to go here
<sven>
nice!
<marcan>
I added UART2 to have a better test target that isn't the boot console
<marcan>
(that's the wifi debug thing)
<sven>
so what happens if a driver doesn't have runtime pm support? will it still get enabled if you just add that power-domains property?
<marcan>
yeah, it gets enabled, just never disabled
<sven>
alright. sounds great
<marcan>
also any unused PDs get disabled
<marcan>
so we should list all the things that we don't use
<marcan>
(should probably be an include at that point...)
<sven>
yeah. guess i can also submit i2c in the next days then :)
<marcan>
(this includes all the devices that don't even exist in the ADT, e.g. the other 6 UARTs...)
<marcan>
yeah, and also since runtime pm is totally standard stuff, you can add it now or later
<marcan>
won't break anything
<marcan>
(unlike the clocks which are more explicit)
<j_ey>
so the device tree in 94e8103b55a6ab85563883921c1b2d5ff02636ec looks pretty much like the one in the clock gate code, which means hopefully it's easy to try out with the keyboard branch I ahve
<sven>
sounds great
<marcan>
it's even more generic than the clock gate approach, because the pm stuff works fine if either side is missing
<marcan>
a driver with no PM will just keep it enabled; a driver with no associated power domain will just do nothing.
<marcan>
no failing clock ops or anything to care about there
<marcan>
I think I'm not doing the nesting properly yet, I'll look into that tomorrow
<marcan>
but you shouldn't care too much about that for leaf drivers
<sven>
yeah, that sounds good
<sven>
so just a single clock for the i2c driver that's essentially clk24 will be fine
<sven>
(to calculate the i2c clock div)
<marcan>
also I'm not implementing the 2 power states yet; that is a thing in genpd, but I'm not going to bother until we find a device where there's a good reason to go into non-full poweroff
<marcan>
yeah, exactly
<marcan>
fwiw the cpufreq stuff can be done, AIUI, with the same framework
<marcan>
i.e. there is already a generic cpufreq -> this bridge
<marcan>
so it'll just be a cluster-pstate driver along very similar lines, except that one will support OPP to set different active states
<marcan>
and then those states can depend, in the case of the pcores, on some fake-ish mcc pstate driver (it's not *really* doing that, but we can model the MCC configuration change as two pstates)
<marcan>
I was a bit worried about clocks and DT compat, but with this there's no issue there
<marcan>
in principle we're keeping full compat with the first submission DT by doing it like this
<marcan>
(the uart also shouldn't care about a missing clock; I added the second baudclk we discovered)
<marcan>
sven: for any other devices that need clock rates, we can refer to the adt clocks where available (and the freqs from iboot) and just model them as static clocks
<sven>
so i2c divides the clock by 16 before the clock div. i can either add a fixed-factor clock to the DT that does that or just do that statically in the driver
<marcan>
sven: I think usually drivers do that, the UART is the same (1.5mbaud is the actual base baudrate)
<marcan>
(due to oversampling etc)
<marcan>
just pushed dump_pmgr.py to m1n1 too
<j_ey>
marcan: what's APPLE_PMGR_PS_CLKGATE?
<sven>
sounds good
<marcan>
a power state that, in theory, clock gates but does not power gate
<marcan>
it's unclear what devices that actually makes a difference for, and whether the timings are different
<marcan>
it is very rarely used by macos
<sven>
oh, let me also push my dwc3/xhci/phy tracer
<sven>
might be useful once you start looking at those usb pd lines
<marcan>
yeah
<marcan>
ok, off to sleep :)
<marcan>
j_ey: pretty sure e.g. the uarts aren't individually power-gateable so it should be the same for those