[U-Boot] Driver Model and DTS Parsing

[Simon Glass]

+Stephen

Hi Jon,

On 3 June 2014 07:39, Jon Loeliger <loeliger at gmail.com> wrote:

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

Linux has created all sorts of opaque data structures in the device world.
I am rather hoping that with driver model we can keep a lot of things
attached directly to 'struct udevice' and not have every uclass have lots
of private inaccessible data. An example is GPIO banks. Yes we could
introduce a secondary data structure for this but then no one can find the
GPIO banks, driver model's commands can't list them and everything becomes
a special case for GPIOs.

The uclass idea helps a lot - by categorising devices according to type,
and the operations they support, it should be possible for devices to at
least know what they are talking to.

I hit this badly when converting the charger manager code in Linux to
device tree. I ended up adding lots of special case functions and new APIs
just to be able to find the devices for battery, charger, etc. Partly this
is because Linux apparently has no way to find a device from a node, and
partly that is because of all the opaque second-level data structures which
appear.


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

I can't see why in the case you bring up this feature is important for
GPIOs. I suggested you add an amba driver. A perfectly reasonable thing for
an amba driver to do is to scan its peripherals and bind them. You could
add a helper function for doing that perhaps? The good thing is that if the
amba bus needs any configuration or deals with interrupts you have
somewhere to put that logic.


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

Not really. We could create one easily enough. I'll send an email.


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

Please go ahead, but also consider what I have said above. I really want to
keep things simple and visible to the 'dm tree' command, etc.

Regards,
Simon