Re: [RFR 2/2] drm/panel: Add simple panel support

On 10/17/2013 09:49 AM, Tomi Valkeinen wrote:

Hi,

On 17/10/13 11:28, Dave Airlie wrote:

quoted

quoted

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.