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

[Stephen Warren <swarren@wwwdotorg.org>]

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.