[U-Boot] Driver Model Thoughts

[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?

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?

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

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

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

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

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.

> Best regards,
> Marek Vasut

Regards,
Simon