On Mon, Jun 2, 2014 at 8:26 PM, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
