[PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

MIPI-DSI devices, if they are controlled through the bus itself, have to
be described as a child node of the controller they are attached to.

Thus, there's no requirement on the controller having an OF-Graph output
port to model the data stream: it's assumed that it would go from the
parent to the child.

However, some bridges controlled through the DSI bus still require an
input OF-Graph port, thus requiring a controller with an OF-Graph output
port. This prevents those bridges from being used with the controllers
that do not have one without any particular reason to.

Let's drop that requirement.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
 .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
index 62c3bd4cb28d..7257fd0ae4da 100644
--- a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
@@ -51,7 +51,6 @@ properties:
           Video port for MIPI DPI output (panel or connector).
 
     required:
-      - port@0
       - port@1
 
 required:
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
index 5216c27fc0ad..a412a1da950f 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
@@ -39,7 +39,6 @@ properties:
           Video port for MIPI DPI output (panel or connector).
 
     required:
-      - port@0
       - port@1
 
 required:
-- 
2.35.1

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Laurent Pinchart]

Hi Maxime,

(CC'ing Sakari)

Thank you for the patch.

On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> MIPI-DSI devices, if they are controlled through the bus itself, have to
> be described as a child node of the controller they are attached to.
> 
> Thus, there's no requirement on the controller having an OF-Graph output
> port to model the data stream: it's assumed that it would go from the
> parent to the child.
> 
> However, some bridges controlled through the DSI bus still require an
> input OF-Graph port, thus requiring a controller with an OF-Graph output
> port. This prevents those bridges from being used with the controllers
> that do not have one without any particular reason to.
> 
> Let's drop that requirement.

I'm sure this won't come as a surprise, I'm very much opposed to this
change, for two reasons.

First, ports are part of the hardware, even if they're not connected. It
thus simplifies handling in drivers if they're always present.

Then, and that's the most important reason, I think it's a mistake not
to model the DSI data connection using OF graph unconditionally, even
when the DSI sink device is also controlled through the DSI bus (using
DCS) and is in that case a child of the DSI source device in the DT
hierarchy.

The device tree describes a control hierarchy between devices. OF graph
overlays on top of that a data transfer graph. The two are different
concepts, and the fact that DSI can sometimes be used as a control bus
doesn't change the concept. Using OF graph unconditionally to describe
the data connections for DSI leads to less variation in the device tree
structure, and thus less complexity in the implementation. We're
suffering from the fact we haven't made it a requirement in the first
place, which can't be fixed due to ABI breakage constraints, but let's
not acknowledge it as a good idea.

> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
>  .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> index 62c3bd4cb28d..7257fd0ae4da 100644
> --- a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> @@ -51,7 +51,6 @@ properties:
>            Video port for MIPI DPI output (panel or connector).
>  
>      required:
> -      - port@0
>        - port@1
>  
>  required:
> diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> index 5216c27fc0ad..a412a1da950f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> @@ -39,7 +39,6 @@ properties:
>            Video port for MIPI DPI output (panel or connector).
>  
>      required:
> -      - port@0
>        - port@1
>  
>  required:

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]

On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> (CC'ing Sakari)
> 
> Thank you for the patch.
> 
> On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > be described as a child node of the controller they are attached to.
> > 
> > Thus, there's no requirement on the controller having an OF-Graph output
> > port to model the data stream: it's assumed that it would go from the
> > parent to the child.
> > 
> > However, some bridges controlled through the DSI bus still require an
> > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > port. This prevents those bridges from being used with the controllers
> > that do not have one without any particular reason to.
> > 
> > Let's drop that requirement.
> 
> I'm sure this won't come as a surprise, I'm very much opposed to this
> change, for two reasons.
> 
> First, ports are part of the hardware, even if they're not connected. It
> thus simplifies handling in drivers if they're always present.
> 
> Then, and that's the most important reason, I think it's a mistake not
> to model the DSI data connection using OF graph unconditionally, even
> when the DSI sink device is also controlled through the DSI bus (using
> DCS) and is in that case a child of the DSI source device in the DT
> hierarchy.

That's the way we do for any other device though. You never addressed
that comment, but it's very much the same that occurs for i2c or spi
controllers and their device. They all get their data from the parent
bus. I don't see you advocate for using OF-Graph for those devices.

> The device tree describes a control hierarchy between devices. OF graph
> overlays on top of that a data transfer graph. The two are different
> concepts, and the fact that DSI can sometimes be used as a control bus
> doesn't change the concept. Using OF graph unconditionally to describe
> the data connections for DSI leads to less variation in the device tree
> structure, and thus less complexity in the implementation. We're
> suffering from the fact we haven't made it a requirement in the first
> place, which can't be fixed due to ABI breakage constraints, but let's
> not acknowledge it as a good idea.

Honestly, it doesn't matter one bit.

We have a huge discrepancy here today, and only a couple of bridges have
that arbitrary restriction. The situation you don't want to acknowledge
is the de-facto standard, by the generic binding and by what all the
bridges and panels are implementing. Even panel-simple-dsi is doing it.
So it's very much there already.

What I'm trying to address here is that some controllers that do
everything right can't be used because that restriction is completely
arbitrary and in opposition to the consensus. And they can't be used
*today*.

If we want to change that consensus, fine, but we should still have one.
Having some bridges enforcing custom rules for no reason is very much
unacceptable.

And changing that consensus won't happen overtime, we'll have to take
care of the backward compatibility, etc. So it won't fix the issue that
we can't use any bridge with any controller any time soon.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Laurent Pinchart]

Hi Maxime,

On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > Hi Maxime,
> > 
> > (CC'ing Sakari)
> > 
> > Thank you for the patch.
> > 
> > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > be described as a child node of the controller they are attached to.
> > > 
> > > Thus, there's no requirement on the controller having an OF-Graph output
> > > port to model the data stream: it's assumed that it would go from the
> > > parent to the child.
> > > 
> > > However, some bridges controlled through the DSI bus still require an
> > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > port. This prevents those bridges from being used with the controllers
> > > that do not have one without any particular reason to.
> > > 
> > > Let's drop that requirement.
> > 
> > I'm sure this won't come as a surprise, I'm very much opposed to this
> > change, for two reasons.
> > 
> > First, ports are part of the hardware, even if they're not connected. It
> > thus simplifies handling in drivers if they're always present.
> > 
> > Then, and that's the most important reason, I think it's a mistake not
> > to model the DSI data connection using OF graph unconditionally, even
> > when the DSI sink device is also controlled through the DSI bus (using
> > DCS) and is in that case a child of the DSI source device in the DT
> > hierarchy.
> 
> That's the way we do for any other device though. You never addressed
> that comment, but it's very much the same that occurs for i2c or spi
> controllers and their device. They all get their data from the parent
> bus. I don't see you advocate for using OF-Graph for those devices.

Those are different, there's no data stream independent of the control
communications.

> > The device tree describes a control hierarchy between devices. OF graph
> > overlays on top of that a data transfer graph. The two are different
> > concepts, and the fact that DSI can sometimes be used as a control bus
> > doesn't change the concept. Using OF graph unconditionally to describe
> > the data connections for DSI leads to less variation in the device tree
> > structure, and thus less complexity in the implementation. We're
> > suffering from the fact we haven't made it a requirement in the first
> > place, which can't be fixed due to ABI breakage constraints, but let's
> > not acknowledge it as a good idea.
> 
> Honestly, it doesn't matter one bit.
> 
> We have a huge discrepancy here today, and only a couple of bridges have
> that arbitrary restriction. The situation you don't want to acknowledge
> is the de-facto standard, by the generic binding and by what all the
> bridges and panels are implementing. Even panel-simple-dsi is doing it.
> So it's very much there already.

It's here, and I think we should move away from it for new DSI sinks.
I'd like OF graph to be used consistently for new drivers. We can't
change existing DT bindings and drivers to drop support for the
non-OF-graph description due to ABI stability, but we can avoid
repeating the mistake going forward.

> What I'm trying to address here is that some controllers that do
> everything right can't be used because that restriction is completely
> arbitrary and in opposition to the consensus. And they can't be used
> *today*.
> 
> If we want to change that consensus, fine, but we should still have one.
> Having some bridges enforcing custom rules for no reason is very much
> unacceptable.
> 
> And changing that consensus won't happen overtime, we'll have to take
> care of the backward compatibility, etc. So it won't fix the issue that
> we can't use any bridge with any controller any time soon.

I don't think that's the issue at hand here. You can still use a
non-OF-graph DT event if the nodes for the two bridges affected by this
patch define a port@0. It can just be left unconnected.

I do agree it will cause some DT bindings for DCS-based DSI sinks to
have ports will others won't. If your concern is that all DT bindings
should be coherent, would you be OK with a patch that makes the sink
port mandatory in all DT bindings for DSI bridges and panels (and fixes
the mainline DT sources accordingly to make sure they validate) ? The
port would not be connected of course (at least when used with DSI
source drivers that don't use OF graph today). That would make DT
bindings coherent, and would be a first step towards using OF graph
everywhere.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5243 bytes --]

On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > > Hi Maxime,
> > > 
> > > (CC'ing Sakari)
> > > 
> > > Thank you for the patch.
> > > 
> > > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > > be described as a child node of the controller they are attached to.
> > > > 
> > > > Thus, there's no requirement on the controller having an OF-Graph output
> > > > port to model the data stream: it's assumed that it would go from the
> > > > parent to the child.
> > > > 
> > > > However, some bridges controlled through the DSI bus still require an
> > > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > > port. This prevents those bridges from being used with the controllers
> > > > that do not have one without any particular reason to.
> > > > 
> > > > Let's drop that requirement.
> > > 
> > > I'm sure this won't come as a surprise, I'm very much opposed to this
> > > change, for two reasons.
> > > 
> > > First, ports are part of the hardware, even if they're not connected. It
> > > thus simplifies handling in drivers if they're always present.
> > > 
> > > Then, and that's the most important reason, I think it's a mistake not
> > > to model the DSI data connection using OF graph unconditionally, even
> > > when the DSI sink device is also controlled through the DSI bus (using
> > > DCS) and is in that case a child of the DSI source device in the DT
> > > hierarchy.
> > 
> > That's the way we do for any other device though. You never addressed
> > that comment, but it's very much the same that occurs for i2c or spi
> > controllers and their device. They all get their data from the parent
> > bus. I don't see you advocate for using OF-Graph for those devices.
> 
> Those are different, there's no data stream independent of the control
> communications.

Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.

> > > The device tree describes a control hierarchy between devices. OF graph
> > > overlays on top of that a data transfer graph. The two are different
> > > concepts, and the fact that DSI can sometimes be used as a control bus
> > > doesn't change the concept. Using OF graph unconditionally to describe
> > > the data connections for DSI leads to less variation in the device tree
> > > structure, and thus less complexity in the implementation. We're
> > > suffering from the fact we haven't made it a requirement in the first
> > > place, which can't be fixed due to ABI breakage constraints, but let's
> > > not acknowledge it as a good idea.
> > 
> > Honestly, it doesn't matter one bit.
> > 
> > We have a huge discrepancy here today, and only a couple of bridges have
> > that arbitrary restriction. The situation you don't want to acknowledge
> > is the de-facto standard, by the generic binding and by what all the
> > bridges and panels are implementing. Even panel-simple-dsi is doing it.
> > So it's very much there already.
> 
> It's here, and I think we should move away from it for new DSI sinks.
> I'd like OF graph to be used consistently for new drivers. We can't
> change existing DT bindings and drivers to drop support for the
> non-OF-graph description due to ABI stability, but we can avoid
> repeating the mistake going forward.
>
> > What I'm trying to address here is that some controllers that do
> > everything right can't be used because that restriction is completely
> > arbitrary and in opposition to the consensus. And they can't be used
> > *today*.
> > 
> > If we want to change that consensus, fine, but we should still have one.
> > Having some bridges enforcing custom rules for no reason is very much
> > unacceptable.
> > 
> > And changing that consensus won't happen overtime, we'll have to take
> > care of the backward compatibility, etc. So it won't fix the issue that
> > we can't use any bridge with any controller any time soon.
> 
> I don't think that's the issue at hand here. You can still use a
> non-OF-graph DT event if the nodes for the two bridges affected by this
> patch define a port@0. It can just be left unconnected.
> 
> I do agree it will cause some DT bindings for DCS-based DSI sinks to
> have ports will others won't. If your concern is that all DT bindings
> should be coherent, would you be OK with a patch that makes the sink
> port mandatory in all DT bindings for DSI bridges and panels (and fixes
> the mainline DT sources accordingly to make sure they validate) ? The
> port would not be connected of course (at least when used with DSI
> source drivers that don't use OF graph today). That would make DT
> bindings coherent, and would be a first step towards using OF graph
> everywhere.

I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
discussion is not going to be fairly controversial and I don't see how
that can be solved quickly. So, as a second step, why not. But this one
needs to come first.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Laurent Pinchart]

Hi Maxime,

On Thu, Mar 24, 2022 at 03:23:24PM +0100, Maxime Ripard wrote:
> On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> > On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > > > Hi Maxime,
> > > > 
> > > > (CC'ing Sakari)
> > > > 
> > > > Thank you for the patch.
> > > > 
> > > > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > > > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > > > be described as a child node of the controller they are attached to.
> > > > > 
> > > > > Thus, there's no requirement on the controller having an OF-Graph output
> > > > > port to model the data stream: it's assumed that it would go from the
> > > > > parent to the child.
> > > > > 
> > > > > However, some bridges controlled through the DSI bus still require an
> > > > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > > > port. This prevents those bridges from being used with the controllers
> > > > > that do not have one without any particular reason to.
> > > > > 
> > > > > Let's drop that requirement.
> > > > 
> > > > I'm sure this won't come as a surprise, I'm very much opposed to this
> > > > change, for two reasons.
> > > > 
> > > > First, ports are part of the hardware, even if they're not connected. It
> > > > thus simplifies handling in drivers if they're always present.
> > > > 
> > > > Then, and that's the most important reason, I think it's a mistake not
> > > > to model the DSI data connection using OF graph unconditionally, even
> > > > when the DSI sink device is also controlled through the DSI bus (using
> > > > DCS) and is in that case a child of the DSI source device in the DT
> > > > hierarchy.
> > > 
> > > That's the way we do for any other device though. You never addressed
> > > that comment, but it's very much the same that occurs for i2c or spi
> > > controllers and their device. They all get their data from the parent
> > > bus. I don't see you advocate for using OF-Graph for those devices.
> > 
> > Those are different, there's no data stream independent of the control
> > communications.
> 
> Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.
> 
> > > > The device tree describes a control hierarchy between devices. OF graph
> > > > overlays on top of that a data transfer graph. The two are different
> > > > concepts, and the fact that DSI can sometimes be used as a control bus
> > > > doesn't change the concept. Using OF graph unconditionally to describe
> > > > the data connections for DSI leads to less variation in the device tree
> > > > structure, and thus less complexity in the implementation. We're
> > > > suffering from the fact we haven't made it a requirement in the first
> > > > place, which can't be fixed due to ABI breakage constraints, but let's
> > > > not acknowledge it as a good idea.
> > > 
> > > Honestly, it doesn't matter one bit.
> > > 
> > > We have a huge discrepancy here today, and only a couple of bridges have
> > > that arbitrary restriction. The situation you don't want to acknowledge
> > > is the de-facto standard, by the generic binding and by what all the
> > > bridges and panels are implementing. Even panel-simple-dsi is doing it.
> > > So it's very much there already.
> > 
> > It's here, and I think we should move away from it for new DSI sinks.
> > I'd like OF graph to be used consistently for new drivers. We can't
> > change existing DT bindings and drivers to drop support for the
> > non-OF-graph description due to ABI stability, but we can avoid
> > repeating the mistake going forward.
> >
> > > What I'm trying to address here is that some controllers that do
> > > everything right can't be used because that restriction is completely
> > > arbitrary and in opposition to the consensus. And they can't be used
> > > *today*.
> > > 
> > > If we want to change that consensus, fine, but we should still have one.
> > > Having some bridges enforcing custom rules for no reason is very much
> > > unacceptable.
> > > 
> > > And changing that consensus won't happen overtime, we'll have to take
> > > care of the backward compatibility, etc. So it won't fix the issue that
> > > we can't use any bridge with any controller any time soon.
> > 
> > I don't think that's the issue at hand here. You can still use a
> > non-OF-graph DT event if the nodes for the two bridges affected by this
> > patch define a port@0. It can just be left unconnected.
> > 
> > I do agree it will cause some DT bindings for DCS-based DSI sinks to
> > have ports will others won't. If your concern is that all DT bindings
> > should be coherent, would you be OK with a patch that makes the sink
> > port mandatory in all DT bindings for DSI bridges and panels (and fixes
> > the mainline DT sources accordingly to make sure they validate) ? The
> > port would not be connected of course (at least when used with DSI
> > source drivers that don't use OF graph today). That would make DT
> > bindings coherent, and would be a first step towards using OF graph
> > everywhere.
> 
> I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
> discussion is not going to be fairly controversial and I don't see how
> that can be solved quickly. So, as a second step, why not. But this one
> needs to come first.

I don't think we need to flip the switch in one go, even on the DT
binding side, we could agree on a direction for new bindings and then
migrate the existing ones. The migration time should be minimized
though, I agree about your cargo cult comment though, it's painful. And
it shouldn't be difficult to convert all DT bindings in one go if we
decide to do so. Changing drivers would be more complex, but that
doesn't need to be tied to the bindings.

tl;dr: I'm fine dropping the required port@0 here short term to avoid
divergence in bindings, as long as it won't be used as an argument
against me in the future to make port@0 mandatory again :-)


-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 6601 bytes --]

On Thu, Mar 24, 2022 at 04:50:04PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> On Thu, Mar 24, 2022 at 03:23:24PM +0100, Maxime Ripard wrote:
> > On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> > > On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > > > > Hi Maxime,
> > > > > 
> > > > > (CC'ing Sakari)
> > > > > 
> > > > > Thank you for the patch.
> > > > > 
> > > > > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > > > > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > > > > be described as a child node of the controller they are attached to.
> > > > > > 
> > > > > > Thus, there's no requirement on the controller having an OF-Graph output
> > > > > > port to model the data stream: it's assumed that it would go from the
> > > > > > parent to the child.
> > > > > > 
> > > > > > However, some bridges controlled through the DSI bus still require an
> > > > > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > > > > port. This prevents those bridges from being used with the controllers
> > > > > > that do not have one without any particular reason to.
> > > > > > 
> > > > > > Let's drop that requirement.
> > > > > 
> > > > > I'm sure this won't come as a surprise, I'm very much opposed to this
> > > > > change, for two reasons.
> > > > > 
> > > > > First, ports are part of the hardware, even if they're not connected. It
> > > > > thus simplifies handling in drivers if they're always present.
> > > > > 
> > > > > Then, and that's the most important reason, I think it's a mistake not
> > > > > to model the DSI data connection using OF graph unconditionally, even
> > > > > when the DSI sink device is also controlled through the DSI bus (using
> > > > > DCS) and is in that case a child of the DSI source device in the DT
> > > > > hierarchy.
> > > > 
> > > > That's the way we do for any other device though. You never addressed
> > > > that comment, but it's very much the same that occurs for i2c or spi
> > > > controllers and their device. They all get their data from the parent
> > > > bus. I don't see you advocate for using OF-Graph for those devices.
> > > 
> > > Those are different, there's no data stream independent of the control
> > > communications.
> > 
> > Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.
> > 
> > > > > The device tree describes a control hierarchy between devices. OF graph
> > > > > overlays on top of that a data transfer graph. The two are different
> > > > > concepts, and the fact that DSI can sometimes be used as a control bus
> > > > > doesn't change the concept. Using OF graph unconditionally to describe
> > > > > the data connections for DSI leads to less variation in the device tree
> > > > > structure, and thus less complexity in the implementation. We're
> > > > > suffering from the fact we haven't made it a requirement in the first
> > > > > place, which can't be fixed due to ABI breakage constraints, but let's
> > > > > not acknowledge it as a good idea.
> > > > 
> > > > Honestly, it doesn't matter one bit.
> > > > 
> > > > We have a huge discrepancy here today, and only a couple of bridges have
> > > > that arbitrary restriction. The situation you don't want to acknowledge
> > > > is the de-facto standard, by the generic binding and by what all the
> > > > bridges and panels are implementing. Even panel-simple-dsi is doing it.
> > > > So it's very much there already.
> > > 
> > > It's here, and I think we should move away from it for new DSI sinks.
> > > I'd like OF graph to be used consistently for new drivers. We can't
> > > change existing DT bindings and drivers to drop support for the
> > > non-OF-graph description due to ABI stability, but we can avoid
> > > repeating the mistake going forward.
> > >
> > > > What I'm trying to address here is that some controllers that do
> > > > everything right can't be used because that restriction is completely
> > > > arbitrary and in opposition to the consensus. And they can't be used
> > > > *today*.
> > > > 
> > > > If we want to change that consensus, fine, but we should still have one.
> > > > Having some bridges enforcing custom rules for no reason is very much
> > > > unacceptable.
> > > > 
> > > > And changing that consensus won't happen overtime, we'll have to take
> > > > care of the backward compatibility, etc. So it won't fix the issue that
> > > > we can't use any bridge with any controller any time soon.
> > > 
> > > I don't think that's the issue at hand here. You can still use a
> > > non-OF-graph DT event if the nodes for the two bridges affected by this
> > > patch define a port@0. It can just be left unconnected.
> > > 
> > > I do agree it will cause some DT bindings for DCS-based DSI sinks to
> > > have ports will others won't. If your concern is that all DT bindings
> > > should be coherent, would you be OK with a patch that makes the sink
> > > port mandatory in all DT bindings for DSI bridges and panels (and fixes
> > > the mainline DT sources accordingly to make sure they validate) ? The
> > > port would not be connected of course (at least when used with DSI
> > > source drivers that don't use OF graph today). That would make DT
> > > bindings coherent, and would be a first step towards using OF graph
> > > everywhere.
> > 
> > I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
> > discussion is not going to be fairly controversial and I don't see how
> > that can be solved quickly. So, as a second step, why not. But this one
> > needs to come first.
> 
> I don't think we need to flip the switch in one go, even on the DT
> binding side, we could agree on a direction for new bindings and then
> migrate the existing ones. The migration time should be minimized
> though, I agree about your cargo cult comment though, it's painful. And
> it shouldn't be difficult to convert all DT bindings in one go if we
> decide to do so. Changing drivers would be more complex, but that
> doesn't need to be tied to the bindings.
> 
> tl;dr: I'm fine dropping the required port@0 here short term to avoid
> divergence in bindings, as long as it won't be used as an argument
> against me in the future to make port@0 mandatory again :-)

That's what I had in mind all along, so it's fine by me :)

And I plan on staying far away from that discussion

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Tomi Valkeinen]

Hi Maxime,

On 24/03/2022 16:23, Maxime Ripard wrote:
> On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
>> On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
>>> On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
>>>> Hi Maxime,
>>>>
>>>> (CC'ing Sakari)
>>>>
>>>> Thank you for the patch.
>>>>
>>>> On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
>>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
>>>>> be described as a child node of the controller they are attached to.
>>>>>
>>>>> Thus, there's no requirement on the controller having an OF-Graph output
>>>>> port to model the data stream: it's assumed that it would go from the
>>>>> parent to the child.
>>>>>
>>>>> However, some bridges controlled through the DSI bus still require an
>>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
>>>>> port. This prevents those bridges from being used with the controllers
>>>>> that do not have one without any particular reason to.
>>>>>
>>>>> Let's drop that requirement.
>>>>
>>>> I'm sure this won't come as a surprise, I'm very much opposed to this
>>>> change, for two reasons.
>>>>
>>>> First, ports are part of the hardware, even if they're not connected. It
>>>> thus simplifies handling in drivers if they're always present.
>>>>
>>>> Then, and that's the most important reason, I think it's a mistake not
>>>> to model the DSI data connection using OF graph unconditionally, even
>>>> when the DSI sink device is also controlled through the DSI bus (using
>>>> DCS) and is in that case a child of the DSI source device in the DT
>>>> hierarchy.
>>>
>>> That's the way we do for any other device though. You never addressed
>>> that comment, but it's very much the same that occurs for i2c or spi
>>> controllers and their device. They all get their data from the parent
>>> bus. I don't see you advocate for using OF-Graph for those devices.
>>
>> Those are different, there's no data stream independent of the control
>> communications.
> 
> Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.

Have those devices had the need for OF graphs? For display and capture 
we have a clear need. I don't think we should sometimes use OF graphs 
and sometimes not, but rather use them consistently at least in any new 
driver.

>>>> The device tree describes a control hierarchy between devices. OF graph
>>>> overlays on top of that a data transfer graph. The two are different
>>>> concepts, and the fact that DSI can sometimes be used as a control bus
>>>> doesn't change the concept. Using OF graph unconditionally to describe
>>>> the data connections for DSI leads to less variation in the device tree
>>>> structure, and thus less complexity in the implementation. We're
>>>> suffering from the fact we haven't made it a requirement in the first
>>>> place, which can't be fixed due to ABI breakage constraints, but let's
>>>> not acknowledge it as a good idea.
>>>
>>> Honestly, it doesn't matter one bit.
>>>
>>> We have a huge discrepancy here today, and only a couple of bridges have
>>> that arbitrary restriction. The situation you don't want to acknowledge
>>> is the de-facto standard, by the generic binding and by what all the
>>> bridges and panels are implementing. Even panel-simple-dsi is doing it.
>>> So it's very much there already.
>>
>> It's here, and I think we should move away from it for new DSI sinks.
>> I'd like OF graph to be used consistently for new drivers. We can't
>> change existing DT bindings and drivers to drop support for the
>> non-OF-graph description due to ABI stability, but we can avoid
>> repeating the mistake going forward.
>>
>>> What I'm trying to address here is that some controllers that do
>>> everything right can't be used because that restriction is completely
>>> arbitrary and in opposition to the consensus. And they can't be used
>>> *today*.
>>>
>>> If we want to change that consensus, fine, but we should still have one.
>>> Having some bridges enforcing custom rules for no reason is very much
>>> unacceptable.
>>>
>>> And changing that consensus won't happen overtime, we'll have to take
>>> care of the backward compatibility, etc. So it won't fix the issue that
>>> we can't use any bridge with any controller any time soon.
>>
>> I don't think that's the issue at hand here. You can still use a
>> non-OF-graph DT event if the nodes for the two bridges affected by this
>> patch define a port@0. It can just be left unconnected.
>>
>> I do agree it will cause some DT bindings for DCS-based DSI sinks to
>> have ports will others won't. If your concern is that all DT bindings
>> should be coherent, would you be OK with a patch that makes the sink
>> port mandatory in all DT bindings for DSI bridges and panels (and fixes
>> the mainline DT sources accordingly to make sure they validate) ? The
>> port would not be connected of course (at least when used with DSI
>> source drivers that don't use OF graph today). That would make DT
>> bindings coherent, and would be a first step towards using OF graph
>> everywhere.
> 
> I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
> discussion is not going to be fairly controversial and I don't see how
> that can be solved quickly. So, as a second step, why not. But this one
> needs to come first.

I feel like I don't quite understand the problem and the discussion.

What's the problem this fixes? DT validation? Why not just fix the dts 
files which use these devices (although I didn't see any in mainline), 
by adding the port nodes?

Or is the argument that we should also support "implicit ports" when the 
control and data busses are the same?

  Tomi

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 7642 bytes --]

Hi Tomi,

On Fri, Mar 25, 2022 at 12:42:15PM +0200, Tomi Valkeinen wrote:
> On 24/03/2022 16:23, Maxime Ripard wrote:
> > On Thu, Mar 24, 2022 at 03:43:42PM +0200, Laurent Pinchart wrote:
> > > On Thu, Mar 24, 2022 at 09:18:19AM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 23, 2022 at 10:38:19PM +0200, Laurent Pinchart wrote:
> > > > > Hi Maxime,
> > > > > 
> > > > > (CC'ing Sakari)
> > > > > 
> > > > > Thank you for the patch.
> > > > > 
> > > > > On Wed, Mar 23, 2022 at 04:48:23PM +0100, Maxime Ripard wrote:
> > > > > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > > > > be described as a child node of the controller they are attached to.
> > > > > > 
> > > > > > Thus, there's no requirement on the controller having an OF-Graph output
> > > > > > port to model the data stream: it's assumed that it would go from the
> > > > > > parent to the child.
> > > > > > 
> > > > > > However, some bridges controlled through the DSI bus still require an
> > > > > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > > > > port. This prevents those bridges from being used with the controllers
> > > > > > that do not have one without any particular reason to.
> > > > > > 
> > > > > > Let's drop that requirement.
> > > > > 
> > > > > I'm sure this won't come as a surprise, I'm very much opposed to this
> > > > > change, for two reasons.
> > > > > 
> > > > > First, ports are part of the hardware, even if they're not connected. It
> > > > > thus simplifies handling in drivers if they're always present.
> > > > > 
> > > > > Then, and that's the most important reason, I think it's a mistake not
> > > > > to model the DSI data connection using OF graph unconditionally, even
> > > > > when the DSI sink device is also controlled through the DSI bus (using
> > > > > DCS) and is in that case a child of the DSI source device in the DT
> > > > > hierarchy.
> > > > 
> > > > That's the way we do for any other device though. You never addressed
> > > > that comment, but it's very much the same that occurs for i2c or spi
> > > > controllers and their device. They all get their data from the parent
> > > > bus. I don't see you advocate for using OF-Graph for those devices.
> > > 
> > > Those are different, there's no data stream independent of the control
> > > communications.
> > 
> > Fine, then you have Ethernet PHYs, or any MMIO device that does DMA.
> 
> Have those devices had the need for OF graphs?

No, they don't. It's kind of my point actually :)

> For display and capture we have a clear need. I don't think we should
> sometimes use OF graphs and sometimes not, but rather use them
> consistently at least in any new driver.

There's a clear need when the data don't follow the obvious path, ie
when there's a direct FIFO between a CRTC and its connector. If it was
going through that obvious path, like an Ethernet PHY, then we wouldn't
need it.

A device being controlled through the DSI bus has that obvious path. If
it's taking its data through the DSI bus, but is being controlled by an
i2c bus, then it needs an OF-graph node...

> > > > > The device tree describes a control hierarchy between devices. OF graph
> > > > > overlays on top of that a data transfer graph. The two are different
> > > > > concepts, and the fact that DSI can sometimes be used as a control bus
> > > > > doesn't change the concept. Using OF graph unconditionally to describe
> > > > > the data connections for DSI leads to less variation in the device tree
> > > > > structure, and thus less complexity in the implementation. We're
> > > > > suffering from the fact we haven't made it a requirement in the first
> > > > > place, which can't be fixed due to ABI breakage constraints, but let's
> > > > > not acknowledge it as a good idea.
> > > > 
> > > > Honestly, it doesn't matter one bit.
> > > > 
> > > > We have a huge discrepancy here today, and only a couple of bridges have
> > > > that arbitrary restriction. The situation you don't want to acknowledge
> > > > is the de-facto standard, by the generic binding and by what all the
> > > > bridges and panels are implementing. Even panel-simple-dsi is doing it.
> > > > So it's very much there already.
> > > 
> > > It's here, and I think we should move away from it for new DSI sinks.
> > > I'd like OF graph to be used consistently for new drivers. We can't
> > > change existing DT bindings and drivers to drop support for the
> > > non-OF-graph description due to ABI stability, but we can avoid
> > > repeating the mistake going forward.
> > > 
> > > > What I'm trying to address here is that some controllers that do
> > > > everything right can't be used because that restriction is completely
> > > > arbitrary and in opposition to the consensus. And they can't be used
> > > > *today*.
> > > > 
> > > > If we want to change that consensus, fine, but we should still have one.
> > > > Having some bridges enforcing custom rules for no reason is very much
> > > > unacceptable.
> > > > 
> > > > And changing that consensus won't happen overtime, we'll have to take
> > > > care of the backward compatibility, etc. So it won't fix the issue that
> > > > we can't use any bridge with any controller any time soon.
> > > 
> > > I don't think that's the issue at hand here. You can still use a
> > > non-OF-graph DT event if the nodes for the two bridges affected by this
> > > patch define a port@0. It can just be left unconnected.
> > > 
> > > I do agree it will cause some DT bindings for DCS-based DSI sinks to
> > > have ports will others won't. If your concern is that all DT bindings
> > > should be coherent, would you be OK with a patch that makes the sink
> > > port mandatory in all DT bindings for DSI bridges and panels (and fixes
> > > the mainline DT sources accordingly to make sure they validate) ? The
> > > port would not be connected of course (at least when used with DSI
> > > source drivers that don't use OF graph today). That would make DT
> > > bindings coherent, and would be a first step towards using OF graph
> > > everywhere.
> > 
> > I'm trying to fix a (recent) mistake/cargo-cult in new bindings. That
> > discussion is not going to be fairly controversial and I don't see how
> > that can be solved quickly. So, as a second step, why not. But this one
> > needs to come first.
> 
> I feel like I don't quite understand the problem and the discussion.
> 
> What's the problem this fixes? DT validation? Why not just fix the dts files
> which use these devices (although I didn't see any in mainline), by adding
> the port nodes?
> 
> Or is the argument that we should also support "implicit ports" when the
> control and data busses are the same?

... But the discussion really is two-fold.

The problem this patch addresses is that there's two odd bridges that
have an inconsistent binding with how the rest of the similar devices
now. It was a mistake that slipped through review, we should address it.

Then, there's the larger discussion of whether or not we want to push
the OF-graph for everyone. But that will require some kind of consensus,
some work on the MIPI-DSI encoders that don't have that kind of support,
in a backward compatible manner, etc. It's not going to happen
over-night, especially since it seems like it's something that would be
nice to have, but no-one is really interested in actually making it
happen.

And we shouldn't wait for that to happen to fix the inconsistency
mentioned above.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Rob Herring]

On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> MIPI-DSI devices, if they are controlled through the bus itself, have to
> be described as a child node of the controller they are attached to.
> 
> Thus, there's no requirement on the controller having an OF-Graph output
> port to model the data stream: it's assumed that it would go from the
> parent to the child.
> 
> However, some bridges controlled through the DSI bus still require an
> input OF-Graph port, thus requiring a controller with an OF-Graph output
> port. This prevents those bridges from being used with the controllers
> that do not have one without any particular reason to.
> 
> Let's drop that requirement.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
>  .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
>  2 files changed, 2 deletions(-)
> 

I tend to agree with port@0 not being needed and really like 
consistency.

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Marek Vasut]

On 4/1/22 01:52, Rob Herring wrote:
> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
>> MIPI-DSI devices, if they are controlled through the bus itself, have to
>> be described as a child node of the controller they are attached to.
>>
>> Thus, there's no requirement on the controller having an OF-Graph output
>> port to model the data stream: it's assumed that it would go from the
>> parent to the child.
>>
>> However, some bridges controlled through the DSI bus still require an
>> input OF-Graph port, thus requiring a controller with an OF-Graph output
>> port. This prevents those bridges from being used with the controllers
>> that do not have one without any particular reason to.
>>
>> Let's drop that requirement.
>>
>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>> ---
>>   .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
>>   .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
>>   2 files changed, 2 deletions(-)
>>
> 
> I tend to agree with port@0 not being needed and really like
> consistency.

The consistent thing to do would be to always use port@0 and OF graph, no ?

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Laurent Pinchart]

On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> On 4/1/22 01:52, Rob Herring wrote:
> > On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> >> MIPI-DSI devices, if they are controlled through the bus itself, have to
> >> be described as a child node of the controller they are attached to.
> >>
> >> Thus, there's no requirement on the controller having an OF-Graph output
> >> port to model the data stream: it's assumed that it would go from the
> >> parent to the child.
> >>
> >> However, some bridges controlled through the DSI bus still require an
> >> input OF-Graph port, thus requiring a controller with an OF-Graph output
> >> port. This prevents those bridges from being used with the controllers
> >> that do not have one without any particular reason to.
> >>
> >> Let's drop that requirement.
> >>
> >> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >> ---
> >>   .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> >>   .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> >>   2 files changed, 2 deletions(-)
> >>
> > 
> > I tend to agree with port@0 not being needed and really like
> > consistency.
> 
> The consistent thing to do would be to always use port@0 and OF graph, no ?

I think that's the direction we should take in the long term. I'm not
opposed to a short-term consistency-focussed patch that makes the port
optional, as long as there's an agreement on the long term goal and this
patch won't be used as an argument against it in the future.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Rob Herring]

On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> On 4/1/22 01:52, Rob Herring wrote:
> > On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> > > MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > be described as a child node of the controller they are attached to.
> > > 
> > > Thus, there's no requirement on the controller having an OF-Graph output
> > > port to model the data stream: it's assumed that it would go from the
> > > parent to the child.
> > > 
> > > However, some bridges controlled through the DSI bus still require an
> > > input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > port. This prevents those bridges from being used with the controllers
> > > that do not have one without any particular reason to.
> > > 
> > > Let's drop that requirement.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > ---
> > >   .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> > >   .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> > >   2 files changed, 2 deletions(-)
> > > 
> > 
> > I tend to agree with port@0 not being needed and really like
> > consistency.
> 
> The consistent thing to do would be to always use port@0 and OF graph, no ?

I guess it depends how wide our scope for consistency is. Just DSI bus 
controlled bridges? DSI panels? All bridges and panels? Any panel 
without a control interface has the same dilemma as those can be a child 
of the display controller (or bridge) and not even use OF graph. 

All simple panels don't require 'port' either. That's presumably only 
consistent because we made a single schema. I'd assume 'non-simple' 
panels with their own schema are not consistent.

Rob

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Marek Vasut]

On 4/1/22 19:34, Rob Herring wrote:
> On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
>> On 4/1/22 01:52, Rob Herring wrote:
>>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
>>>> be described as a child node of the controller they are attached to.
>>>>
>>>> Thus, there's no requirement on the controller having an OF-Graph output
>>>> port to model the data stream: it's assumed that it would go from the
>>>> parent to the child.
>>>>
>>>> However, some bridges controlled through the DSI bus still require an
>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
>>>> port. This prevents those bridges from being used with the controllers
>>>> that do not have one without any particular reason to.
>>>>
>>>> Let's drop that requirement.
>>>>
>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>> ---
>>>>    .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
>>>>    .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
>>>>    2 files changed, 2 deletions(-)
>>>>
>>>
>>> I tend to agree with port@0 not being needed and really like
>>> consistency.
>>
>> The consistent thing to do would be to always use port@0 and OF graph, no ?
> 
> I guess it depends how wide our scope for consistency is. Just DSI bus
> controlled bridges? DSI panels? All bridges and panels? Any panel
> without a control interface has the same dilemma as those can be a child
> of the display controller (or bridge) and not even use OF graph.

I would likely opt for the OF graph in all cases, panels, bridges, 
controllers. Then it would be consistent.

> All simple panels don't require 'port' either. That's presumably only
> consistent because we made a single schema. I'd assume 'non-simple'
> panels with their own schema are not consistent.

Maybe we would start requiring that port even for simple panels ?
The port is physically there on that panel after all.

[...]

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Rob Herring]

On Fri, Apr 1, 2022 at 1:06 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/1/22 19:34, Rob Herring wrote:
> > On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> >> On 4/1/22 01:52, Rob Herring wrote:
> >>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> >>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
> >>>> be described as a child node of the controller they are attached to.
> >>>>
> >>>> Thus, there's no requirement on the controller having an OF-Graph output
> >>>> port to model the data stream: it's assumed that it would go from the
> >>>> parent to the child.
> >>>>
> >>>> However, some bridges controlled through the DSI bus still require an
> >>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
> >>>> port. This prevents those bridges from being used with the controllers
> >>>> that do not have one without any particular reason to.
> >>>>
> >>>> Let's drop that requirement.
> >>>>
> >>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>> ---
> >>>>    .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> >>>>    .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> >>>>    2 files changed, 2 deletions(-)
> >>>>
> >>>
> >>> I tend to agree with port@0 not being needed and really like
> >>> consistency.
> >>
> >> The consistent thing to do would be to always use port@0 and OF graph, no ?
> >
> > I guess it depends how wide our scope for consistency is. Just DSI bus
> > controlled bridges? DSI panels? All bridges and panels? Any panel
> > without a control interface has the same dilemma as those can be a child
> > of the display controller (or bridge) and not even use OF graph.
>
> I would likely opt for the OF graph in all cases, panels, bridges,
> controllers. Then it would be consistent.
>
> > All simple panels don't require 'port' either. That's presumably only
> > consistent because we made a single schema. I'd assume 'non-simple'
> > panels with their own schema are not consistent.
>
> Maybe we would start requiring that port even for simple panels ?
> The port is physically there on that panel after all.

Fix this in all the dts files and then I'll agree. Though I think this
ship has already sailed. I'd like to someday get to platforms without
warnings and not just keep adding new warnings.

Rob

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Marek Vasut]

On 4/1/22 20:21, Rob Herring wrote:
> On Fri, Apr 1, 2022 at 1:06 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 4/1/22 19:34, Rob Herring wrote:
>>> On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
>>>> On 4/1/22 01:52, Rob Herring wrote:
>>>>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
>>>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
>>>>>> be described as a child node of the controller they are attached to.
>>>>>>
>>>>>> Thus, there's no requirement on the controller having an OF-Graph output
>>>>>> port to model the data stream: it's assumed that it would go from the
>>>>>> parent to the child.
>>>>>>
>>>>>> However, some bridges controlled through the DSI bus still require an
>>>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
>>>>>> port. This prevents those bridges from being used with the controllers
>>>>>> that do not have one without any particular reason to.
>>>>>>
>>>>>> Let's drop that requirement.
>>>>>>
>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>> ---
>>>>>>     .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
>>>>>>     .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
>>>>>>     2 files changed, 2 deletions(-)
>>>>>>
>>>>>
>>>>> I tend to agree with port@0 not being needed and really like
>>>>> consistency.
>>>>
>>>> The consistent thing to do would be to always use port@0 and OF graph, no ?
>>>
>>> I guess it depends how wide our scope for consistency is. Just DSI bus
>>> controlled bridges? DSI panels? All bridges and panels? Any panel
>>> without a control interface has the same dilemma as those can be a child
>>> of the display controller (or bridge) and not even use OF graph.
>>
>> I would likely opt for the OF graph in all cases, panels, bridges,
>> controllers. Then it would be consistent.
>>
>>> All simple panels don't require 'port' either. That's presumably only
>>> consistent because we made a single schema. I'd assume 'non-simple'
>>> panels with their own schema are not consistent.
>>
>> Maybe we would start requiring that port even for simple panels ?
>> The port is physically there on that panel after all.
> 
> Fix this in all the dts files and then I'll agree. Though I think this
> ship has already sailed. I'd like to someday get to platforms without
> warnings and not just keep adding new warnings.

I doubt we can fix existing DTs, but can we at least require it for new 
DTs ?

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Rob Herring]

On Fri, Apr 1, 2022 at 1:25 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/1/22 20:21, Rob Herring wrote:
> > On Fri, Apr 1, 2022 at 1:06 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 4/1/22 19:34, Rob Herring wrote:
> >>> On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> >>>> On 4/1/22 01:52, Rob Herring wrote:
> >>>>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> >>>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
> >>>>>> be described as a child node of the controller they are attached to.
> >>>>>>
> >>>>>> Thus, there's no requirement on the controller having an OF-Graph output
> >>>>>> port to model the data stream: it's assumed that it would go from the
> >>>>>> parent to the child.
> >>>>>>
> >>>>>> However, some bridges controlled through the DSI bus still require an
> >>>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
> >>>>>> port. This prevents those bridges from being used with the controllers
> >>>>>> that do not have one without any particular reason to.
> >>>>>>
> >>>>>> Let's drop that requirement.
> >>>>>>
> >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>> ---
> >>>>>>     .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> >>>>>>     .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> >>>>>>     2 files changed, 2 deletions(-)
> >>>>>>
> >>>>>
> >>>>> I tend to agree with port@0 not being needed and really like
> >>>>> consistency.
> >>>>
> >>>> The consistent thing to do would be to always use port@0 and OF graph, no ?
> >>>
> >>> I guess it depends how wide our scope for consistency is. Just DSI bus
> >>> controlled bridges? DSI panels? All bridges and panels? Any panel
> >>> without a control interface has the same dilemma as those can be a child
> >>> of the display controller (or bridge) and not even use OF graph.
> >>
> >> I would likely opt for the OF graph in all cases, panels, bridges,
> >> controllers. Then it would be consistent.
> >>
> >>> All simple panels don't require 'port' either. That's presumably only
> >>> consistent because we made a single schema. I'd assume 'non-simple'
> >>> panels with their own schema are not consistent.
> >>
> >> Maybe we would start requiring that port even for simple panels ?
> >> The port is physically there on that panel after all.
> >
> > Fix this in all the dts files and then I'll agree. Though I think this
> > ship has already sailed. I'd like to someday get to platforms without
> > warnings and not just keep adding new warnings.
>
> I doubt we can fix existing DTs, but can we at least require it for new
> DTs ?

We don't have any way to do that currently and get to warning free for
all DTs. We'd need to be able to disable specific checks for specific
DTs. I've thought about it, but haven't come up with a way to do it.

Rob

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Laurent Pinchart]

On Fri, Apr 01, 2022 at 01:33:15PM -0500, Rob Herring wrote:
> On Fri, Apr 1, 2022 at 1:25 PM Marek Vasut wrote:
> > On 4/1/22 20:21, Rob Herring wrote:
> > > On Fri, Apr 1, 2022 at 1:06 PM Marek Vasut wrote:
> > >> On 4/1/22 19:34, Rob Herring wrote:
> > >>> On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> > >>>> On 4/1/22 01:52, Rob Herring wrote:
> > >>>>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> > >>>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
> > >>>>>> be described as a child node of the controller they are attached to.
> > >>>>>>
> > >>>>>> Thus, there's no requirement on the controller having an OF-Graph output
> > >>>>>> port to model the data stream: it's assumed that it would go from the
> > >>>>>> parent to the child.
> > >>>>>>
> > >>>>>> However, some bridges controlled through the DSI bus still require an
> > >>>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
> > >>>>>> port. This prevents those bridges from being used with the controllers
> > >>>>>> that do not have one without any particular reason to.
> > >>>>>>
> > >>>>>> Let's drop that requirement.
> > >>>>>>
> > >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > >>>>>> ---
> > >>>>>>     .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> > >>>>>>     .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> > >>>>>>     2 files changed, 2 deletions(-)
> > >>>>>>
> > >>>>>
> > >>>>> I tend to agree with port@0 not being needed and really like
> > >>>>> consistency.
> > >>>>
> > >>>> The consistent thing to do would be to always use port@0 and OF graph, no ?
> > >>>
> > >>> I guess it depends how wide our scope for consistency is. Just DSI bus
> > >>> controlled bridges? DSI panels? All bridges and panels? Any panel
> > >>> without a control interface has the same dilemma as those can be a child
> > >>> of the display controller (or bridge) and not even use OF graph.
> > >>
> > >> I would likely opt for the OF graph in all cases, panels, bridges,
> > >> controllers. Then it would be consistent.
> > >>
> > >>> All simple panels don't require 'port' either. That's presumably only
> > >>> consistent because we made a single schema. I'd assume 'non-simple'
> > >>> panels with their own schema are not consistent.
> > >>
> > >> Maybe we would start requiring that port even for simple panels ?
> > >> The port is physically there on that panel after all.
> > >
> > > Fix this in all the dts files and then I'll agree. Though I think this
> > > ship has already sailed. I'd like to someday get to platforms without
> > > warnings and not just keep adding new warnings.
> >
> > I doubt we can fix existing DTs, but can we at least require it for new
> > DTs ?
> 
> We don't have any way to do that currently and get to warning free for
> all DTs. We'd need to be able to disable specific checks for specific
> DTs. I've thought about it, but haven't come up with a way to do it.

I think Marek may have meant new bindings. While I do agree that
inconsistencies in sources can cause new submissions to blindly copy
mistakes, it shouldn't be a reason in itself to carry historical binding
design mistakes in new bindings.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Rob Herring]

On Fri, Apr 01, 2022 at 09:48:28PM +0300, Laurent Pinchart wrote:
> On Fri, Apr 01, 2022 at 01:33:15PM -0500, Rob Herring wrote:
> > On Fri, Apr 1, 2022 at 1:25 PM Marek Vasut wrote:
> > > On 4/1/22 20:21, Rob Herring wrote:
> > > > On Fri, Apr 1, 2022 at 1:06 PM Marek Vasut wrote:
> > > >> On 4/1/22 19:34, Rob Herring wrote:
> > > >>> On Fri, Apr 01, 2022 at 03:22:19AM +0200, Marek Vasut wrote:
> > > >>>> On 4/1/22 01:52, Rob Herring wrote:
> > > >>>>> On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> > > >>>>>> MIPI-DSI devices, if they are controlled through the bus itself, have to
> > > >>>>>> be described as a child node of the controller they are attached to.
> > > >>>>>>
> > > >>>>>> Thus, there's no requirement on the controller having an OF-Graph output
> > > >>>>>> port to model the data stream: it's assumed that it would go from the
> > > >>>>>> parent to the child.
> > > >>>>>>
> > > >>>>>> However, some bridges controlled through the DSI bus still require an
> > > >>>>>> input OF-Graph port, thus requiring a controller with an OF-Graph output
> > > >>>>>> port. This prevents those bridges from being used with the controllers
> > > >>>>>> that do not have one without any particular reason to.
> > > >>>>>>
> > > >>>>>> Let's drop that requirement.
> > > >>>>>>
> > > >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > >>>>>> ---
> > > >>>>>>     .../devicetree/bindings/display/bridge/chipone,icn6211.yaml      | 1 -
> > > >>>>>>     .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml     | 1 -
> > > >>>>>>     2 files changed, 2 deletions(-)
> > > >>>>>>
> > > >>>>>
> > > >>>>> I tend to agree with port@0 not being needed and really like
> > > >>>>> consistency.
> > > >>>>
> > > >>>> The consistent thing to do would be to always use port@0 and OF graph, no ?
> > > >>>
> > > >>> I guess it depends how wide our scope for consistency is. Just DSI bus
> > > >>> controlled bridges? DSI panels? All bridges and panels? Any panel
> > > >>> without a control interface has the same dilemma as those can be a child
> > > >>> of the display controller (or bridge) and not even use OF graph.
> > > >>
> > > >> I would likely opt for the OF graph in all cases, panels, bridges,
> > > >> controllers. Then it would be consistent.
> > > >>
> > > >>> All simple panels don't require 'port' either. That's presumably only
> > > >>> consistent because we made a single schema. I'd assume 'non-simple'
> > > >>> panels with their own schema are not consistent.
> > > >>
> > > >> Maybe we would start requiring that port even for simple panels ?
> > > >> The port is physically there on that panel after all.
> > > >
> > > > Fix this in all the dts files and then I'll agree. Though I think this
> > > > ship has already sailed. I'd like to someday get to platforms without
> > > > warnings and not just keep adding new warnings.
> > >
> > > I doubt we can fix existing DTs, but can we at least require it for new
> > > DTs ?
> > 
> > We don't have any way to do that currently and get to warning free for
> > all DTs. We'd need to be able to disable specific checks for specific
> > DTs. I've thought about it, but haven't come up with a way to do it.
> 
> I think Marek may have meant new bindings. While I do agree that
> inconsistencies in sources can cause new submissions to blindly copy
> mistakes, it shouldn't be a reason in itself to carry historical binding
> design mistakes in new bindings.

This patch and the whole thread is about consistency of existing 
bindings. 

The only way to get some consistency reliably (beyond depending on 
reviews which doesn't achieve it) is either have a meta-schema to check 
something or make it a common schema. If we have new and old bindings, 
then we'd need panel-simple-old.yaml and panel-simple-new.yaml. There's 
other options probably, but not without more work on the tools.

Rob

Re: (subset) [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> MIPI-DSI devices, if they are controlled through the bus itself, have to
> be described as a child node of the controller they are attached to.
> 
> Thus, there's no requirement on the controller having an OF-Graph output
> port to model the data stream: it's assumed that it would go from the
> parent to the child.
> 
> [...]

Applied to drm/drm-misc (drm-misc-fixes).

Thanks!
Maxime