On Mon, Nov 18, 2013 at 04:37:51PM +0100, Thierry Reding wrote: > Very nice. This is in fact very similar to a skeleton I started to > implement locally. The names vary to some degree, but the general > approach is the same. > > This also happens to be very similar to what Tegra DRM does, just as a > set of helpers rather than a bus type. I like it a lot. > > In particular this gives every driver a good amount of flexibility to > implement the matching in a way that's appropriate. On hardware where > the relationships are hierarchical, a driver can use that to its > advantage. Whenever that's not possible it can be done using phandles > or any other meta data that fits the particular use-case. Indeed - I set out to solve the following problems: - How do we deal with a componentised device such that we can find all of its component devices, and know when we have them all? - How can we probe the master device when we know we have all the components? - How do we tear down the master device when one of the components is removed? I intentionally didn't want the code to answer the question about how we specify how the components are organised - that's a subject best left to the subsystem and/or device, since it's something which will most likely vary. > Do you have a branch somewhere that I could use to test this with? Not yet - and there probably won't be, because the code itself is not large - it's currently less than 500 lines. The code has evolved over time - with imx-drm as a guinea pig. The code which I have so far committed (and some people are using in patch form on the carrier-1 boards) is an earlier version, which just caters for proper init ordering and making it possible to unbind the "master" device. It gets that init ordering by using deferred probing if there's no connectors, or the CRTCs which the connectors refer to are missing - it needs no changes to the DT representation. Since then, I've augmented it as I described and that's currently just as an additional patch on top which adds the master device idea - which does need those additional changes. Logically, it can't stay as two separate patches, because it won't be possible to "migrate" to it in stages. So I'm fully intending to squash that all down to one patch which adds the core code (probably ultimately into drivers/base). IOW, watch this space this week. :) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
