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@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? Maxime
Attachment:
signature.asc
Description: PGP signature
