[PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings

[Marek Vasut]

On 2/4/21 7:38 PM, Doug Anderson wrote:
> Hi,

Hi,

[...]

>>>> +properties:
>>>> +  compatible:
>>>> +    const: ti,sn65dsi83
>>>> +
>>>> +  reg:
>>>> +    const: 0x2d
>>>> +
>>>> +  enable-gpios:
>>>> +    maxItems: 1
>>>> +    description: GPIO specifier for bridge_en pin (active high).
>>>
>>> I see two regulators: vcc and vcore.  Shouldn't those be listed?
>>
>> Those are not implemented and not tested, so if someone needs them later
>> on, they can be added then.
> 
> Sure.  I guess it can go either way.  For the regulator it'd the kind
> of thing that's super easy to add support for and hard to mess up.

If someone can test those regulators (I might be able to, in next 
revision of hardware, we'll see), then this can be added.

>>>> +          endpoint:
>>>> +            type: object
>>>> +            additionalProperties: false
>>>> +            properties:
>>>> +              remote-endpoint: true
>>>> +              data-lanes:
>>>> +                description: array of physical DSI data lane indexes.
>>>
>>> The chip doesn't allow for arbitrary remapping here, right?  So you're
>>> just using this as the official way to specify the number of lanes?  I
>>> guess the only valid values are:
>>>
>>> <0>
>>> <0 1>
>>> <0 1 2>
>>> <0 1 2 3>
>>
>> Shouldn't that be <1 2 3 4> ?
> 
> The data manual refers to the channels starting at 0, so if it's
> arbitrary that seems a better way to go?

Either way is OK, but before I change this, I would like some 
confirmation this enumeration really is arbitrary.

>>> In sn65dsi86 we attempted to enforce that a valid option was selected
>>> for the output lanes.  Could you do something similar?  If nothing
>>> else adding a description of the valid options would be good.
>>
>> I saw the binding, but I was under the impressions the DSI86 can do lane
>> reordering, isn't that the case ? Maybe I misunderstood it.
> 
> DSI86 can reorder the output lanes quite flexibly.  It can't reorder
> the input lanes, though.

The eDP ones ? OK

>> But yes, if you have a suggestion how to make a non-cryptic list of
>> those four lane mapping options, please do share this info.
> 
> I doubt I can write this correctly without a whole lot of futzing /
> messing, but maybe something like:
> 
> data-lanes:
>    oneOf:
>      - items:
>          - 0
>      - items:
>          - 0
>          - 1
>      - items:
>          - 0
>          - 1
>          - 2
>      - items:
>          - 0
>          - 1
>          - 2
>          - 3
> 

I was hoping for some better syntax. Maybe there is one ?