[U-Boot] Driver Model Thoughts

[Marek Vasut]

Dear Simon Glass,

> Hi Marek,
> 
> On Mon, Apr 22, 2013 at 2:00 AM, Marek Vasut <marex at denx.de> wrote:
> > Hi Simon,
> > 
> >> Hi Marek,
> >> 
> >> Another U-Boot engineer and I are looking at running up driver model.
> > 
> > Good, I'm now free of the shackles of the university project. Bring it
> > on.
> > 
> >> It seems to work in sandbox quite nicely. I had half a mind to try to
> >> get some core patches together for this merge window, but have
> >> questions.
> >> 
> >> For 'struct instance' it seems to be an attempt to keep the constant
> >> data separate from the dynamic data to reduce early RAM usage. But
> >> when I look at struct driver_instance, it seems to have a 'struct
> >> instance' within it (not a pointer). So doesn't this defeat that
> >> benefit? You presumably can't put struct driver_instance in read-only
> >> memory because you need it updates its flags.
> > 
> > Honestly, I can't tell. I was never able to properly understand it from
> > Pavel's explanation.
> 
> OK, I guess we need to make this work so we will have a think about it.
> 
> >> I still have trouble keeping track of some of the naming - e.g. and
> >> instance feels to me like it should be called a device, and the naming
> >> of 'core' seems odd although I do understand the concept. Also
> >> bind/unbind seems like register/unregister to me - but maybe there is
> >> a difference.
> >> 
> >> There is:
> >> 
> >> struct driver_info
> >> struct instance
> >> struct core_instance
> >> struct driver_instance
> >> struct u_boot_driver
> >> struct u_boot_core
> >> 
> >> Anyway I'll leave that alone for now.
> >> 
> >> There seems to be a lot of boilerplate code about. For example the
> >> bind/unbind methods just call a core_...() function and it seems that
> >> the core library could do this itself. It seems to me that some of the
> >> methods could be NULL for most drivers, and that would reduce the
> >> porting effort.
> >> 
> >> If we do this I would like to build in device tree from the start so
> >> that on boards that use CONFIG_OF_CONTROL there is no need for static
> >> data.
> >> 
> >> I think the existing 'demo' driver is a really good idea since it
> >> gives people something to copy.
> > 
> > The driver model has one fundamental flaw -- when used with SPL (where
> > you usually have one single device for everything), it's not optimized
> > away and only brings in overhead. That's why I'd love to see some more
> > work put into this.
> 
> Are you talking about using static init of the tables or actually not
> having driver model infrastructure at all in SPL?

I'd love to have it present, but it'd also be nice if parts of it could be 
optimized out -- like the cores tracking only one device would be useless, thus 
be optimized out.

> For the single device I assume you mean the storage device holding
> U-Boot. How much overhead is added in this case? I wonder what an
> acceptable overhead is?

KiB of code. That'd make it hard for platforms like mx31pdk which need to 
squeeze SPL into 2k of memory.

> Expecting it to be totally optimised away seems ambitious - for one
> thing how will the driver code be called if not through dm?

We can still have some stubs for SPL maybe?

> > Another thing that comes to mind are those .bind()/.unbind() calls which
> > make porting drivers from Linux harder. Yet they make sense as they
> > produce an in- memory representation of the driver tree without starting
> > the hardware. Another
> 
> I think they can mostly just be NULL, with dm doing the work in the common
> case.

I think so too.

> > thing I never understood that Pavel mentioned is that sometimes the
> > hardware must be started so that .bind() can be successfully finished.
> > This was probably since it is sometimes uncertain to which cores the
> > hardware can provide services.
> 
> In that case I suggest we have bind do the minimum it can (add the
> driver into the structures with the single known parent perhaps) and
> then let probe add new bindings.
> 
> An example might be USB where it can add a network device when it
> starts up. But in that case we won't even find the device until we
> start up USB.

Sounds reasonable.

> > btw. building in DT from the start would be a nice idea. I'd say we
> > should re- think the design first and maybe align it a bit more with
> > Linux kernel.
> 
> Yes makes sense. We at least need to make sure that each deviation is
> for a good reason. I would prefer that the naming becomes a little
> more similar.

Agreed

> I mostly understand the bind/unbind side, but I want to at least ask
> the question as to whether it would be possible to delay the binding
> until we do the probe, which is delayed until we need the device? We
> actually have a full list of drivers in the image anyway if we care to
> look - so we can create a list of devices anytime we want. Perhaps a
> 'lazy' approach to binding makes some sense? That would fit well with
> things like USB which have to have delayed binding/probing anyway.\
> 
> I'm still getting my head around this stuff though.

How would you do such lazy binding? Take SPI flash for example, which is always 
part of the hardware. How would you bind this on demand?

My understanding is that U-Boot should be aware of such SPI flash and it's 
location and to what bus it is connected. That way the SPI flash can then be 
easily activated. (aka. the full "known" part of device tree is readily 
constructed right when the u-boot starts, things like USB can be added later).