[PATCH 1/2] video: ARM CLCD: Add DT support

[Pawel Moll]

On Wed, 2013-09-11 at 22:14 +0100, Sylwester Nawrocki wrote:
> Yes, I wasn't aware then that your "video RAM" is a separate chip attached
> to a distinct bus.
> My idea was to reuse memory node structure, including "reserved-memory"
> compatible value (note there are some fixups pending and those names are
> subject to change). Not sure about the property in CLCD device node
> containing phandle to the memory node (currently 'memory-region').

As I just told Steven, I'll just make it painfully low-level property
defining "address you have to generate to access base of the
framebuffer". Of course one can still go the CMA way, if such need
arises.

> > Ok, I see what you're saying. Yes, this could be done. No, I don't claim
> > to have enough expertise either (micrometers??? :-O ;-) The other thing
> > is that I don't really expect generic CDF bindings to cover such things.
> > They will (hopefully) only describe what's connected with what. And the
> > drivers should know how. Of course they may need the dimensions&  alike
> > in the tree (of course having them standardised would help here), but
> > it's not a CDF job to provide those.
> 
> Of course it's always easier to define couple of DT properties that would
> cover part of functionality of some specific device. But then such 
> properties should be prefixed with vendor name AFAIU, since they are
> not approved as common ones and useful for wider set of devices.

This is a policy that changed many times already...

Anyway, I think I've got an idea how to render the problem custom panel
properties invalid. If so, I'll send another version of the patch.

>  From the device tree perspective CDF is just a collection of (display
> related) devices and a complete set of DT properties will be needed to
> describe them. Certainly some share of device-specific properties should
> be expected. Links between (sub)devices can be already described in DT by
> the binding documented in video-interfaces.txt.

Whether to use the v4l scheme or not still seems to be a bone of
contention between the video and the DRM/KMS folk, so I wouldn't draw
any conclusions yet.

Paweł