[U-Boot] Many questions about U-Boot's Driver Model

[Simon Glass]

Hi Masahiro,

On 20 September 2014 00:56, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
>
> 2014-09-20 7:25 GMT+09:00 Simon Glass <sjg at chromium.org>:
>
>> - the bind/unbind allows you to have devices which are known to the
>> system, but not yet probed. This is important in a boot loader (e.g.
>> we don't want to probe devices until they are actually needed, and
>> some will never be probed during a boot), although not really
>> necessary in an OS
>
> Uh, this view was missing from my mind.
> It is nice for faster boot.
>
>

Yes and it does make quite a difference in some cases.

>
>
>> Platform data is bound to the driver to create an new device (instance
>> of the driver, if you prefer). Linux has the same concept. See for
>> example struct platform_device_info.
>>
>> Private data is used by that device to hold its information while it
>> is active. Linux devices have this, normally in the ->p->driver_data
>> member,. See dev_get_drvdata().
>
> Now it is clearer.
>
> In Linux, "platform" looks like a bus,
> but in U-Boot it is implemented in the basic infrastructure
> (and it seems reasonable enough)
>
>

Yes.

>
>
>>>
>>> [4] What does "struct driver_info" stand for?
>>
>> It is the information used to bind platform data to a driver to
>> produce a device. See Linux's struct platform_device which is similar
>> (although in Linux the device is included in the structure).
>>
>>>
>>> I cannot understand the following comment block at all.
>>>
>>> /**
>>>  * struct driver_info - Information required to instantiate a device
>>>  *
>>>  * @name:       Device name
>>>  * @platdata:   Driver-specific platform data
>>>  */
>>> struct driver_info {
>>>         const char *name;
>>>         const void *platdata;
>>> };
>>>
>>>
>>>
>>> Does this structure give information of a driver or a device?
>>
>> driver + platform data = device
>
>
> Sorry, I am still not convinced with this part.
>
>
> In my mind, things happen in the following step:
>
> [1] Every driver is instantiated by U_BOOT_DRIVER()
> [2] Every device is instantiated by U_BOOT_DEVICE() (= struct driver_info)

s/instantiated/described/ - they are just tables in memory at this stage.

> [3] If the system finds a driver and a device with the same name, they are bound
>
>
> [1] and [2] occur at the build time
> [3] occurs at run time  (more exactly, when dm_init_and_scan()
> function is called)
>
>
> At the build time (i.e.  [3] hasn't happened yet), struct driver_info
> is information belonging to a *device*.
> (This is why I thought "struct driver_info" should be more likely
> "struct device_info".)
>
>
> After [3] happens, you are right, the device's information is attached
> to the driver
> and driver + platform data = device.
> That's what "binding" is for.
>
> Eventually, your explanation in pointing to the same one in my mind.
> But there is a slight difference of a nuance.
>
> In my understanding, "binding" is an action that couples a driver and
> a device together
> by finding the same name.   (In the device tree world, by finding
> compatible ones)
>
> Mixing up a driver and a device results in confusion.
>
>

Well I'm not going to disagree with you about the confusion. But
'device' as in 'struct udevice' is the term which means a single
instance of a driver. This same term is used in U-Boot and Linux.

So I would not say that binding couples a driver and a device, rather
that binding couples a driver and its information, to produce a
device.

>
>
>>>
>>> I am wordering if "struct driver_info" should have been named "struct device_info"?
>>>
>>
>> Possibly, although that might be confusing also, since it is not
>> really information about a device. The idea is that it is the info
>> needed for a driver to instantiate a new device.
>
> Indeed, it is information about a device.
> because .platdata is an attribute of each *device*, right?
>
>
> I am for statements:
>   - It is "information of a device"
>   - It is "information for a driver" to bind this device

I like this one ^^

>
> I am against a statement:
>   - It is "information of a driver"
>

Agreed.

>
>
>>> I think comments and namings are confusing.
>>>
>>
>> Well it looks like you have found some errors in the comments - we
>> should get those fixed. If you have time, please send a patch!
>
> I do not mind if it is a matter of accidental errors in comments. Send
> a patch and fix them, that's it.
> But I don't think so.
>
> I suspect the struct driver_info is confusing enough and these errors
> happened because of that.
>

OK. I'm resisting because I'm not sure that device_info is better,
particularly when we already have udevice. Looking at it another way,
driver_info is the info you need to find the driver so you can bind a
device to it. I'm happy to change it if we have something obviously
better.

Regards,
Simon