[PATCH 1/4] dt-bindings: display: bridge: tc358867: Document DPI output support

[Marek Vasut]

On 2/3/22 13:23, Maxime Ripard wrote:
> On Tue, Dec 07, 2021 at 06:32:38PM +0100, Marek Vasut wrote:
>> On 12/7/21 18:03, Laurent Pinchart wrote:
>>> On Tue, Dec 07, 2021 at 05:47:29PM +0100, Marek Vasut wrote:
>>>> On 12/7/21 17:43, Laurent Pinchart wrote:
>>>>
>>>> [...]
>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
>>>>>> index f1541cc05297..5cfda6f2ba69 100644
>>>>>> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
>>>>>> @@ -61,8 +61,8 @@ properties:
>>>>>>           port at 1:
>>>>>>             $ref: /schemas/graph.yaml#/properties/port
>>>>>>             description: |
>>>>>> -            DPI input port. The remote endpoint phandle should be a
>>>>>> -            reference to a valid DPI output endpoint node
>>>>>> +            DPI input/output port. The remote endpoint phandle should be a
>>>>>> +            reference to a valid DPI output or input endpoint node.
>>>>>
>>>>> I assume the mode of operation (input or output) will be fixed for a
>>>>> given hardware design. Isn't this something that should be recorded in
>>>>> DT ? It would simplify configuration of the device in the driver.
>>>>
>>>> Currently the configuration (DSI-to-DPI / DPI-to-eDP) is inferred from
>>>> the presence of DPI panel. If DPI panel present, DSI-to-DPI, else,
>>>> DPI-to-eDP.
>>>
>>> I've had a look at the driver side, and it seems to complicate things
>>> quite a bit. It seems that specifying the mode of operation explicitly
>>> in DT could make software implementations quite a bit simpler.
>>
>> Do you have any specific suggestion ? I explored multiple options while
>> writing that DSI-to-DPI driver code, this one was the simplest and least
>> redundant one.
> 
> Can we leverage the bus-type property of endpoints?

We could, but should we really add a property only for the sake of 
adding a property ? The driver can figure out whether this endpoint is 
DSI-input or DSI-output without such a new property.

Now that I look at the datasheet, the logic can be even simpler:

- If port at 0 not connected
   scanout -> port at 1 (DPI input) -> port at 2 (eDP output) -> panel

- If port at 1 not connected
   scanout -> port at 0 (DSI input) -> port at 2 (eDP output) -> panel

- If port at 2 not connected
   scanout -> port at 0 (DSI input) -> port at 1 (DPI output) -> panel

So with this kind of test in the driver, the driver can determine how 
the TC bridge is wired, without any extra props.