On 03/10/2014 12:42 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
>>> I like that idea. I would prefer making the 'port' nodes mandatory and the
>>> 'ports' and 'endpoint' nodes optional. Leaving the 'port' node out
>>> slightly decreases readability in my opinion, but making the 'endpoint'
>>> node optional increases it. That's just my point of view though.
>>
>> I want to propose another solution to simplify bindings, in fact I have
>> few ideas to consider:
>>
>> 1. Use named ports instead of address-cells/regs. Ie instead of
>> port@number schema, use port-function. This will allow to avoid ports
>> node and #address-cells, #size-cells, reg properties.
>> Additionally it should increase readability of the bindings.
>>
>> device {
>> port-dsi {
>> endpoint { ... };
>> };
>> port-rgb {
>> endpoint { ... };
>> };
>> };
>>
>> It is little bit like with gpios vs reset-gpios properties.
>> Another advantage I see we do not need do mappings of port numbers
>> to functions between dts, drivers and documentation.
>
> The problem with this approach is that ports are identified by a number
> inside
> the kernel, so we would still need to define name to number mappings, or
> switch to port names internally first.
The mapping will be only internal in the driver.
Anyway the bindings should be kernel agnostic.
Andrzej
>
>> 2. Similar approach can be taken to endpoint nodes, in fact
>> as endpoints are children of port node and as I understand port node
>> have no other children we can use any name instead of endpoint@number,
>> of course some convention can be helpful.
>>
>> device {
>> port-dsi {
>> ep-soc1 { ... };
>> ep-soc2 { ... };
>> };
>> port-rgb {
>> ep-panel { ... };
>> };
>> };
>
> I see less issues here, as we don't need to number endpoints if I'm not
> mistaken.
>
>> I would like to add that those ideas would work nicely with Sylwester's
>> proposition of skipping endpoints nodes in case there is only one
>> endpoint - the most common cases are devices with one or two ports, each
>> port having only one remote endpoint.
>> The complete graph for DSI/LVDS bridge I work recently will look like:
>>
>> dsim {
>> dsim_ep: port-dsi {
>> remote-endpoint = <&bridge_dsi_ep>;
>> };
>> };
>>
>> bridge {
>> bridge_dsi_ep: port-dsi {
>> remote-endpoint = <&dsim_ep>;
>> };
>> bridge_lvds_ep: port-lvds {
>> remote-endpoint = <&panel_ep>;
>> };
>> };
>>
>> panel {
>> port-lvds {
>> remote-endpoint <&bridge_lvds_ep>;
>> };
>> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
