10:12 <sven> https://github.com/AsahiLinux/m1n1/pull/34 adds support to enable clocks from device tree entires

10:12 <sven> with one small weirdness that i haven't been able to figure out: clocks can be aliased to other clocks but sometimes such a chain leads to nowhere

10:18 <kettenis> sven: with that diff we could enable the pcie clock and apply the tunables?

10:18 <sven> we could probably enable the pcie clock. haven't looked into tunables yet

10:21 <kettenis> after I'm done dealing with the 8-bit ASID fallout properly in the OpenBSD kernel, I'm going to look into using m1n1 such that I can get all the cores running

10:22 <sven> i guess calling pmgr_adt_clocks_enable with /arm-io/{apcie,apciec0,apciec1,dart-apcie0,dart-apcie1} or so should bring up those clocks i guess

10:24 <sven> for linux we could just extract the addresses of these clocks from apple's device tree and put them into the regular linux device tree

10:25 <kettenis> to apply the tunables you need to enable the clocks such that you can access the pcie host bridge registers

10:25 <sven> oh, duh, that makes sense :)

10:25 <kettenis> the alternative is to export the tunables like corellium does

10:27 <sven> hrm, i feel like we should take care of the tunables in either m1n1 or u-boot if possible

10:30 <j`ey> kettenis: can you not use the spin table stuff that m1n1 does?

10:31 <kettenis> u-boot uses standard device trees

10:31 <kettenis> so having u-boot parsing the apple device tree would mean m1n1 has to pass its address somehow

10:32 <kettenis> and would mean some code uplication

10:32 <sven> okay. so that means we essentially need to do this in m1n1

10:32 <kettenis> j`ey: I could if I was using m1n1

10:33 <j`ey> oh right

10:33 <kettenis> still using the corellium preloader at this point because I need the tunables to bring up PCIe

10:36 <kettenis> right now u-boot applies the tunables and brings up PCIe

10:36 <kettenis> so the OpenBSD driver for PCIe is pretty simple

10:38 <sven> yeah, i think we should definitely apply any tunables we can before we jump to the bsd/linux/whatever kernel

10:41 <sven> for usb there are different ones for device vs. host mode though. let me see if there are more cases where the tunables depend on some decision the kernel would make

10:41 <sven> tunable-device 00 00 00 00 08 00 00 00 00 70 00 00 00 00 00 00 |.........p......|

10:41 <sven> tunable-host 00 00 00 00 08 00 00 00 00 70 00 00 00 70 00 00 |.........p...p..|

10:41 <sven> not a big difference, so worse case that's just a quirk in dwc3 then

10:41 <sven> *worst

13:51 <sven> https://github.com/AsahiLinux/m1n1/pull/35 aaand tunables support

13:51 <sven> pcie needs more magic though. just enabling clocks isn't enough to make the MMIO range readable

13:54 <arnd> kettenis: do you need anything beyond the config space access for PCIe in the kernel today?

13:55 <sven> erm, no. scratch that. i'm just an idiot as usual. looks like enabling clocks is actually enough to make PCIe accessible

16:20 <marcan> sven: as long as the tunables don't need re-applying except for full system sleep, it makes sense to do the tunables entirely in m1n1

16:20 <marcan> for full system sleep, AIUI we're going to need some kind of extended hook anyway

16:20 <marcan> because of the RVBAR issue

16:20 <marcan> (and to apply chicken bits etc)

16:20 <marcan> so we can then do the tunables there, however we decide to handle that

16:21 <marcan> but we can just ignore all that stuff for now

16:21 <marcan> the only thing that would be somewhat annoying is if we can't power down peripherals without re-applying tunables either, i.e. power gating kills all those settings too, but we'll worry about that when we get there and figure out how much power it saves us

16:23 <marcan> I'm going to spend today writing the first progress report, let's see how that goes :)

16:23 <marcan> *tomorrow

16:40 <kettenis> arnd: I need to do some MSI config because the u-boot driver skips that

16:42 <kettenis> I also have some code to establish MSI interrupts on behalf of devices

16:43 <kettenis> other than that it is essentially just a "pci-host-ecam-generic" driver

17:24 <sven> marcan: sounds good