On Mon, Nov 18, 2013 at 04:11:51PM +0000, Russell King - ARM Linux wrote: > 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. :) Will do! Thanks for doing this. Thierry
Attachment:
pgpLTO3dsIIby.pgp
Description: PGP signature
