08:36 <sven> jannau: first step for the locked DART cleanup: get rid of the forced-locked for the disp0 dart that contains the framebuffer and just allocate the framebuffer manually for now instead of trying to take over the one provided by m1n1

08:36 <sven> eventually we probably still want to re-use that memory but for now I'd get rid of that hack just to make everything a bit easier

08:37 <sven> before i write about the second step, how familiar are you with the iommu subsystem?

08:39 <ChaosPrincess> is there some sort of a write-up/documenatation/etc on locked darts?

08:39 <sven> it just means that you can't change any of the registers

08:39 <sven> it's a bit iboot sets for the dcp dart

08:40 <ChaosPrincess> so, how does reclaiming memory will work then, dcp can unlock it?

08:40 <sven> jannau: note that getting rid of the forced-locked is a bit tricky since DCP will still try to access the framebuffer when linux already took over and cleared the pagetables. not sure what the easiest way there is

08:40 <sven> ChaosPrincess: what do you mean with reclaim memory?

08:41 <_jannau_> sven: almost not familiar at all. I looked over the dart commits and I figured out how to map the dcp crashlog buffer

08:41 <sven> locked dart for us mostly means that we can't point that dart to our own first level pagetable but instead have to hack around the dart driver to re-use that first level pagetables

08:43 <sven> jannau: okay. i'll write a bit more about that later then

08:45 <ChaosPrincess> sven: ok, got it

08:47 <sven> if it's not possible to work around the constant framebuffer scanout we'll have to do a bit more invasive surgery to essentially get the iommu subsystem to remap the framebuffer before it replaces the pagetables. there's a thread somewhere on the iommu list because someone else also needs something like that.

08:47 <sven> or just hack the DART driver to scan out existing pagetables and recreate them on a domain attach

08:48 <sven> i think if it's easily possibly to disable the framebuffer scanout while linux attached disp0 and re-creates pagetables i'd go with that for now

08:51 <maz> sven: there was this: https://lore.kernel.org/linux-iommu/YTelDHx2REIIvV%2FN@orome.fritz.box/T/

08:52 <_jannau_> macos clears all planes as first swap during boot. that hopefully removes the boot framebuffer scanout

08:52 <sven> yes! that's what i was thinking about, thanks

08:52 <sven> wasn't able to find it

08:52 <maz> though this assumes idmap.

08:52 <sven> i think at the end there was some brief discussion about non idmaps, but there never was any conclusion

08:53 <maz> it's been going on for at least 5 years, with various patch series.

08:56 <sven> great :/

08:57 <sven> there goes my hope that someone else would solve that problem for us

08:57 <sven> jannau: so the problem is that DCP will continue to scan out the buffer even before the first swap but the moment the disp0 DART is probed that framebuffer will disappear

08:58 <sven> (well, not DCP but the actual display controller but same difference)

09:02 <maz> sven: the best bet would be to pick the series and to push it forward. it is the lack of persistent engagement that ruined the effort so far.

09:08 <_jannau_> but to disable scan out we need dcp. is dart reconfigured at probe time or only when the first iommu domain attaches?

10:33 <kloenk> Hi, trying to hack a bit on m1n1 right now. The path argument to adt_get_reg (type int), does it always have the size 8? or is it dynamic?

11:37 <sven> jannau: a default DMA Domain is attached when the device is probed

11:38 <sven> that also makes everything a bit more complex since we will have to switch to a domain that can be controlled with the raw iommu api

11:38 <sven> so the whole locked dart thing has to support detaching and attaching domains eventually

11:39 <sven> (while always keeping the DCP firmware maps)

12:15 <kettenis> can't you just reserver the iova's used by the framebuffer to stop the iommu code fro messing about with those mappings?

12:34 <sven> the iommu subsystem will overwrite whatever pagetable is present and drop all mappings when doing that

12:34 <sven> there's no mechanism to keep certain iovas around, that's what that patch series linked above is about

12:37 <sven> what we can do is to essentially read out the pagetable and re-create the mapping, and that's essentially what "cleaning up the locked dart hacks" is about

13:23 <alyssa> sven: thank you for reminding me why i stopped working on dcp

13:35 <sven> alyssa: so that means if jannau fixes those issues you'll return? :>

13:36 <alyssa> sven: 3d awaits

13:36 <sven> even better!

13:36 <alyssa> and what do you mean return i just did a pile of mesa work for the M1 a week ago

13:36 <sven> return to DCP

23:05 <jannau> sven: I guess noboby checked if something else needs to be mapped. proof of concept seems to work but kernel hangs after dcp-piodma attaches to the iommu domain

23:06 <jannau> mapping the framebuffer also for stream 4 of dart-disp0 is not enough

23:15 <jannau> it has a region just after the framebuffer mapped, only referenced in carveout-memory-map

23:16 <jannau> stream 0 has also one additional page mapped

23:23 <alyssa> sounds like you're having fun

23:26 <jannau> yes, except for dealing with devicetree