On Sun, Jun 28, 2026 at 03:27:48PM -0600, James Hilliard wrote: > On Sun, Jun 28, 2026 at 10:16 AM Andre Przywara <[email protected]> > wrote: > > > > On Fri, 26 Jun 2026 14:51:50 -0600 > > James Hilliard <[email protected]> wrote: > > > > Hi James, > > > > > sunxi SPL normally uses the legacy MMC interface while U-Boot > > > proper uses the DM driver. Boards which enable SPL_DM_MMC need > > > > I think I mentioned this before: enabling the device model in the SPL > > (or not) is not a *device* decision, but a platform one. > > I'm a bit confused here, uboot's configuration system from what I can tell > is designed to allow enabling device model for specific devices and even > for specific drivers.
Right. And to be clear, in your tree you're working to upstream out of, only the h616 platforms end up enabling SPL_DM and not all of the existing ARCH_SUNXI, yes? > Why would this need to be a platform level decision? Given that boards > that don't have enough SRAM for SPL DM support tend to be older, we > will presumably want to migrate newer boards to SPL DM at some point > in the future anyways. > > > And for > > technical reasons, mostly to support older devices, which have no other > > choice, but also to keep it simple and the SPL small, we do not use DM > > in the SPL on Allwinner boards. > > I mean, this seems to me to be justification for continuing to support > legacy drivers, not justification for not supporting DM as well since there > are also many sunxi boards that don't have that limitation. This would be a separate set of potential cleanups to evaluate later on. > > I see the SPL as the continuation of the > > BootROM, which is completely board agnostic. > > At a minimum SPL is still fairly SoC specific. Although in practice it seems > to not be all that board agnostic, I think if anything DM support makes it > more agnostic by allowing better factoring of the device specific stuff. > > > The SPL can mimic this > > behaviour, to follow the decisions that the BootROM made, for instance > > about the boot device. The only difference here is the DRAM > > initialisation, which requires some board specific data, but so far we > > got away with just hardcoding it. > > This is one of a few reasons I wanted to get SPL DM functional on sunxi. > > > If that is not good anymore, I think > > we can find other solutions than pulling in the whole world of SPL_DM > > support. > > > > So what is the purpose of this exercise, why do you want DM_SPL > > supported? > > Some cryptoengine uboot drivers I was working on adding seemed to > need DM_SPL, also I think handling DRAM profiles becomes easier with > it somewhat. > > > Keep in mind that there are 178 Allwinner boards supported in > > U-Boot, so there better would be good reasons to change something > > fundamental like this for all of them. It changing it for a number of > > them is not better, because this doubles the test matrix, so we have to > > test now that it works on both legacy and DM_SPL boards - which frankly > > nobody will do. > > Well it doesn't actually double the test matrix since presumably boards > that are not SPL DM compatible will continue to use non-DM drivers only. And today nothing ARCH_SUNXI enables SPL, but they all could enable it today and get an assortment of failures. With what James is doing, some could now enable it and have it work, or more easily work. > Wouldn't we typically just pick either DM or non-DM configs for upstream > uboot testing/configs for any particular board to avoid maintaining more > configurations than necessary in the test matrix? > > > And aside from that, please do NOT add any more #ifdef's to the U-Boot > > code. > > This seemed to be how other subsystems handled both DM and non-DM > driver support, is there a better way? So looking at this patch, it needs to be split up a whole lot more, to make it easier to review and clearer what's being changed. Also, there's a lot of places in code where it looks like you're handling dependencies that Kconfig should handle instead. By which I mean, if we have SPL_DM_MMC and we're in the driver, we don't need to handle SPL_DM_CLK=n or SPL_OF_REAL=n. You can find examples of that, but they're older code that also needs to be cleaned up. It might be the case that the driver itself needs some re-organization first to make what your end goal needs, easier to do. -- Tom
signature.asc
Description: PGP signature
