| Message ID | 20211127032405.283435-1-marex@denx.de |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | [1/4] dt-bindings: display: bridge: tc358867: Document DPI output support | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/dt-meta-schema | success | |
| robh/dtbs-check | success |
Hi Marek, Thank you for the patch. On Sat, Nov 27, 2021 at 04:24:02AM +0100, Marek Vasut wrote: > The TC358767/TC358867/TC9595 are all capable of operating in multiple > modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the > DPI output port, which can now be connected both as input and output. > > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Andrzej Hajda <a.hajda@samsung.com> > Cc: Jernej Skrabec <jernej.skrabec@siol.net> > Cc: Jonas Karlman <jonas@kwiboo.se> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > Cc: Neil Armstrong <narmstrong@baylibre.com> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: devicetree@vger.kernel.org > To: dri-devel@lists.freedesktop.org > --- > .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > 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. > > port@2: > $ref: /schemas/graph.yaml#/properties/port >
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.
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.
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.
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
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@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@0 not connected scanout -> port@1 (DPI input) -> port@2 (eDP output) -> panel - If port@1 not connected scanout -> port@0 (DSI input) -> port@2 (eDP output) -> panel - If port@2 not connected scanout -> port@0 (DSI input) -> port@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.
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. port@2: $ref: /schemas/graph.yaml#/properties/port
The TC358767/TC358867/TC9595 are all capable of operating in multiple modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the DPI output port, which can now be connected both as input and output. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)