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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/10/13 13:40, Laurent Pinchart wrote:

>> panel {
>> 	remote = <&remote-endpoint>;
>> 	common-video-property = <asd>;
>> };
>>
>> panel {
>> 	port {
>> 		endpoint {
>> 			remote = <&remote-endpoint>;
>> 			common-video-property = <asd>;
>> 		};
>> 	};
>> };
> 
> Please note that the common video properties would be in the panel node, not 
> in the endpoint node (unless you have specific requirements to do so, which 
> isn't the common case).

Hmm, well, the panel driver must look for its properties either in the
panel node, or in the endpoint node (I guess it could look them from
both, but that doesn't sound good).

If you write the panel driver, and in all your cases the properties work
fine in the panel node, does that mean they'll work fine with everybody?

I guess there are different kinds of properties. Something like a
regulator is obviously property of the panel. But anything related to
the video itself, like DPI's bus width, or perhaps even something like
"orientation" if the panel supports such, could need to be in the
endpoint node.

But yes, I understand what you mean. With "common-video-property" I
meant common properties like DPI bus width.

>> If that can be supported in the SW by adding complexity to a few functions,
>> and it covers practically all the panels, isn't it worth it?
>>
>> Note that I have not tried this, so I don't know if there are issues.
>> It's just a thought. Even if there's need for a endpoint node, perhaps
>> the port node can be made optional.
> 
> It can be worth it, as long as we make sure that simplified bindings cover the 
> needs of the generic code.
> 
> We could assume that, if the port subnode isn't present, the device will have 
> a single port, with a single endpoint. However, isn't the number of endpoints 

Right.

> a system property rather than a device property ? If a port of a device is 

Yes.

> connected to two remote ports it will require two endpoints. We could select 
> the simplified or full bindings based on the system topology though.

The drivers should not know about simplified/normal bindings. They
should use CDF DT helper functions to get the port and endpoint
information. The helper functions would do the assuming.

 Tomi


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux