[U-Boot] Driver Model and DTS Parsing

[Jon Loeliger]

On Mon, Jun 2, 2014 at 8:26 PM, Simon Glass <sjg at chromium.org> wrote:
>
> Driver model works by looking up compatible strings in the top-level
> nodes and binding a driver for each one it finds.

I get that.

I'm saying that isn't sufficient.

> The exynos pinctrl device tree binding does not have a compatible
> string in each of its banks. In fact it just has a single compatible
> string at the level above the banks. So there seems to be no
> alternative but to iterate through the banks binding devices as we go.
>
> So we get a bind call on the pinctrl node and then bind each of the banks.

Right.  That's fine for this board and DTS.

However, the existing parsing structure isn't sufficient yet.

>> Instead, I think it should be a recursive structure essentially
>> identical in structure to the Linux of_platform_populate() function.
>> There should be a compatible matching step, and then the
>> call to bind the specific instance.
>>
>> Am I missing something here?  Or is this code that just needs to
>> be developed further still?
>
> Certainly this could be done,

Excellent.  I'm saying it should be done.  Specifically, a recursive,
top-down implementation will allow the right parent node to grab
iterative control and handle the sub-nodes that can't handle themselves.
Like the Linux DTS parsing, we'll need to add handling of bus nodes.

But we have to put in place the top-down structure so that we *do*
iterate through the parents properly and at multiple levels.

> ... and it's a small change but this code
> doesn't exist yet.

OK, I'll play that game:  It's an important change and it
needs to exist soon. :-)

> I deliberately left this out of the implementation
> until we have I2C implemented, or something similar. Then it will be
> clearer what is needed here.
>
> My concern is partly that access to the device may be mediated through
> the parent and thus not discoverable by the child. As an example, the
> Chrome OS EC driver can attached to I2C, SPI or LPC. The connection
> needs to be made at the parent level, which provides a
> 'communications' layer for the generic driver.

Right.  A top-down approach will allow for that sort of handling.

> So in short I think we need to address these things and make the
> decisions as we go. For the same reason I didn't implement driver
> model for SPL or pre-relocation (although I have a series out for the
> latter now).
>
> A lot of things will be clearer to me when I2C is ported over.

Sure.  In the meantime, the GPIO model suffers.  Understood. :-)

So two procedural questions:

First, is there a DM repo.  No, I don't mean an "x86 repo gathering DM" patches.
I mean an actual repo with a DM moderator?  I ask because I am carrying around
patches that are going to take for-*ever* to hit mainline...  You know.

Second, how would you like to advance the DM's DTS parsing infrastructure?
Do you want me to take a crack some patches?  Would you rather do it?
Can we get a common basis of patches (repo) somewhere?

> Regards,
> Simon

Thanks,
jdl