[U-Boot] Driver Model Thoughts

[Marek Vasut]

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.

> 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.

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 
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.

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.

Best regards,
Marek Vasut