On 10/17/2013 09:49 AM, Tomi Valkeinen wrote: > 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. I don't really agree. A specific DT binding is supposed to be an ABI; something that can only be changed in a backwards-compatible way (perhaps only in a forwards-compatible way too). However, I see no reason you can't have a simple DT binding now, and create a more complex DT binding later. Both can exist (be defined). Now, because DT is an ABI, we can't remove kernel support for the old binding. > 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. I don't think we need a converter for that; just leave in both the old and new parser/driver and treat them as different things. There's no reason that a new kernel must provide new features when given an old DT written to the old binding, and hence a new kernel can just treat the old DT with the old code. -- 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
