Hi, On 17/10/13 11:28, Dave Airlie wrote: >> >> My biggest concern here is that this will not be compatible with the CDF DT >> bindings. They're not complete yet, but they will require connections between >> entities to be described in DT, in a way very similar (or actually identical) >> to the V4L2 DT bindings, documented in >> Documentation/devicetree/bindings/media/video-interfaces.txt. Could you have a >> look at that ? Please ignore all optional properties beside remote-endpoint, >> as they're V4L2 specific. >> >> I also plan to specify video bus parameters in DT for CDF, but this hasn't >> been finalized yet. >> > > While I understand this, I don't see why CDF can't enhance these > bindings if it has > requirements > than they have without disturbing the panel ones, > > is DT really that inflexible? > > It seems that have a simple description for basic panels like Thierry wants > to support, that can be enhanced for the other cases in the future should > suffice, I really don't like blocking stuff that makes things work on the chance > of something that isn't upstream yet, its sets a bad precedent, its also breaks > the perfect is the enemy of good rule Just my opinion, but yes, DT is that inflexible. DT bindings are like a syscall. Once they are there, you need to support them forever. That support can, of course, include some kind of DT data converters or such, that try to convert old bindings to new bindings at kernel boot. In practice even such converter may be enough, if some important piece of data in the new bindings is missing, and this data was implicit in a driver. In that case the conversion, or parts of it, must be done later, in that specific driver. Even that may be difficult, if the piece of data should actually be handled by some other driver. In that case there's probably need for some kind of global look-up table or such, so that the drivers can work around the problem of missing information. I've been working with DT bindings for OMAP display subsystem for something like 1.5 years. Still not merged, as they are not perfect, and I'm scared to push them in non-perfect form, as that could result in some kind of DT-binding-converter-hell described above. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
