On Mon, Jun 2, 2014 at 8:26 PM, Simon Glass sjg@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