[U-Boot] Driver Model Thoughts

Simon Glass sjg at chromium.org
Mon Apr 22 07:39:15 CEST 2013


Hi Marek,

Another U-Boot engineer and I are looking at running up driver model.

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.

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.

Regards,
Simon


More information about the U-Boot mailing list