Dear Simon Glass,
Hi Marek,
On Mon, Apr 22, 2013 at 2:00 AM, Marek Vasut marex@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).