05:18 <marcan> sven: you should have branch write access to asahilinux/linux now, only `main` is excluded

05:19 <marcan> bloom: added you too, *hint hint*

05:21 <marcan> kettenis_: let me know if you want access too; I'm fine with the external fork process too, but I think it's helpful to have regulars doing dev directly in upstream repo branches :)

05:22 <marcan> I think for m1n1 we want to keep the PR model (though I might just merge stuff outside of PRs too, it's not required), but we don't need PRs for the kernel as all of that is coordinated with upstream

05:23 <marcan> I want to eventually set up some kind of auto-merge-bot to build `main` out of golden feature branches or something like that

05:28 <jannau> marcan: did you see the pull requests in https://github.com/AsahiLinux/vdmtool/pulls? there is one from february

05:28 <marcan> oh, no, thanks, totally missed those

06:55 <Emantor> I have modified the original reclaimerlabs PD USB Breakout to include a header for the SBU pins: https://github.com/Emantor/USB-PD-Breakout/tree/topic/separate_sbu_port

07:12 <sven> marcan: sounds good, will push my stuff later today

07:12 <kettenis_> marcan: might make sense for coordinating work on DT bindings and device tree updates

07:18 <kettenis_> and while on the subject of DT bindings: Linus Walleij is taking my pinctrl binding through the pinctrl tree but the actual device tree changes need to go through some other tree

07:19 <sven> probably through marcan and then through arnd's soc tree i guess

07:20 <arnd> right

07:20 <kettenis_> would make it easier to patch up the interaction with your clock bindings

07:21 <kettenis_> oops

07:21 <kettenis_> meant to say that makes it easier to deal with the clock stuff in the pinctrl nodes

07:30 <marcan> kettenis_: invited :)

07:34 <marcan> kettenis_, sven: I think for the upcoming changes, which are mostly to "small" subsystems, it makes sense to keep a nice merge pipeline going in our tree so we can test everything together and make sure it's cohesive before/while submitting upstream

07:34 <marcan> keep our tree a couple steps ahead of mainline, just enough to validate that the ideas work, and then submit as things fall into place

07:35 <marcan> it's kind of a balance between "wasting" work if things need to be changed after upstream review and blocking on said review; bit of an optimization problem :)

07:37 <_jannau_>

07:37 <sven> sure, especially with the clock/DART stuff will will need to work together with almost everything else

07:38 <marcan> yeah

07:39 <marcan> don't want us to move too slowly to get everything super kosher for upstream; the initial bring-up was very hairy with all the arch/ stuff, but it ought to be much easier to do git cleanups for submission for all of these drivers and bindings

07:40 <sven> dart is gonna be a little bit hairy since I'll probably need to change something in the iommu subsystem to allow 4k cpu / 16k iommu pages

07:40 <sven> but the rest should be fine

07:40 <marcan> sure, but that still hopefully doesn't have much impact elsewhere

07:40 <sven> yeah

07:41 <sven> and for the clock I'll have to discuss with the maintainers how to encode the non-leafs in the device tree such that we don't have to have that in the drive

07:41 <sven> r

07:41 <marcan> we should do something like dart/{dev,for-next} pinctrl/{dev,for-next} etc

07:41 <sven> but that won't have an impact anywhere else either

07:41 <marcan> have a dev branch to hack on with impunity, and a for-next for cleaned up series

07:41 <sven> sounds good

07:41 <marcan> also we make zero promises about not force pushing for any of this

07:41 <sven> ofc :D

07:42 <marcan> `main` will also be endlessly rewritten by a bot at some point, I should set up an action for that

07:42 <marcan> and then i'll have a `base` or something which is whatever linus tree base we are currently working off of

07:44 <arnd> sven: I agree that there should be something in the dart driver to allow booting with 4K pages, but I don't think it's necessary to have isolation in that case for the initial merge. Falling back to a fixed linear map (plus swiotlb if necessary), but having proper iommu support for 16KB pages should give us enough confidence in the binding that we can change the iommu core code for small pages later

07:45 <marcan> sven: have we confirmed that dart can't do 4K pages?

07:45 <sven> yes

07:45 <marcan> sadface

07:46 <marcan> that kind of screws up isolation for distro kernels

07:46 <sven> there's even a field in one of the write-only registers at the beginning that indicates the page shift

07:47 <sven> it's probably hard-wired when they synthesise the hw block :/

07:47 <marcan> read-only you mean?

07:47 <sven> er, yes

08:02 <marcan> sven: maz doesn't think we can mix page sizes btw (other channel)

08:06 <sven> well, even better for me!

08:06 <sven> I mean, it'll kinda boot in bypass-only mode if we can somehow convince pcie to support that

08:12 <sven> dwc3 almost works there. for some reason it ignores dma-ranges though and refuses to use >32 bit addresses

08:12 <marcan> IIRC there's a flag for 32b vs 64b DMA?

08:13 <marcan> I remember something from the ps4 thing

08:13 <sven> maybe, didn't really look into it in much detail

08:14 <sven> just patched some hack in there to force 64bit and then bypass mode worked

08:34 <j_ey> so maybe 'standard' distro kernels can just bypass dart, thats the suggestion sven ?

08:34 <sven> maybe, but we shouldn't enable thunderbolt there then

08:41 <sven> this also depends on pcie working in bypass mode

08:41 <sven> which may or may not be possible

08:42 <sven> since the last time someone tried I found another bypass bit. maybe that thing helps

08:52 <marcan> depending on how the GPU does things, we might not be able to get away with bypass mode there

08:52 <marcan> e.g. userspace command buffers

10:44 <sven> I'm not sure if the gpu is behind a dart

12:37 <marcan> sven: it definitely needs page tables

13:34 <bloom> marcan: wink wink

15:08 <sven> marcan: sure, but i don't think there's an iommu node in the ADT for the gpu (or maybe i missed it)

15:08 <sven> might be yet another iommu

15:09 <sven> and who knows what that one supports

15:09 <marcan> yeah, heh

15:15 <bloom> GPU definitely has its own MMU

15:15 <bloom> might not be related to the MM on the rest of the SoC

15:24 <balrog> bloom: huh interesting!