From: Boris Brezillon <boris.brezillon@collabora.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org, Nikita Yushchenko <nikita.yoush@cogentembedded.com>, Mark Rutland <mark.rutland@arm.com>, Jernej Skrabec <jernej.skrabec@siol.net>, Neil Armstrong <narmstrong@baylibre.com>, Andrey Smirnov <andrew.smirnov@gmail.com>, Jonas Karlman <jonas@kwiboo.se>, Rob Herring <robh+dt@kernel.org>, Andrzej Hajda <a.hajda@samsung.com>, devicetree@vger.kernel.org, Thierry Reding <thierry.reding@gmail.com>, intel-gfx-trybot@lists.freedesktop.org, kernel@collabora.com, Sam Ravnborg <sam@ravnborg.org>, Chris Healy <cphealy@gmail.com> Subject: Re: [PATCH v10 09/12] dt-bindings: display: bridge: lvds-codec: Add new bus-width prop Date: Tue, 25 Feb 2020 10:13:54 +0100 [thread overview] Message-ID: <20200225101354.5f621ccb@collabora.com> (raw) In-Reply-To: <20200224223139.GA29578@pendragon.ideasonboard.com> On Tue, 25 Feb 2020 00:31:39 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Boris, > > Thank you for the patch. > > On Tue, Jan 28, 2020 at 02:55:11PM +0100, Boris Brezillon wrote: > > Add the bus-width property to describe the input bus format. > > > > v10: > > * Add changelog to the commit message > > * Add Rob's R-b > > > > v8 -> v9: > > * No changes > > > > v7: > > * Rebase on top of lvds-codec changes > > * Drop the data-mapping property > > > > v4 -> v6: > > * Not part of the series > > > > v3: > > * New patch > > > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> > > Reviewed-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/display/bridge/lvds-codec.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > index 8f373029f5d2..7c4e42f4de61 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > @@ -55,6 +55,14 @@ properties: > > description: | > > For LVDS encoders, port 0 is the parallel input > > For LVDS decoders, port 0 is the LVDS input > > + properties: > > + bus-width: > > + allOf: > > + - $ref: /schemas/types.yaml#/definitions/uint32 > > + - enum: [18, 24] > > + - default: 24 > > + description: > > + Number of data lines used to transmit the RGB data. > > This is a bit unclear. First of all, depending on whether the node is an > LVDS encoder or decoder, port@0 is either a parallel input or an LVDS > input. The property mentiones RGB data, does it mean it apply to LVDS > encoders only ? Or should it be in port@1 for LVDS decoders ? Right, I only considered the encoder case here. For the decoder case, we don't need a bus-width prop yet, as the bus format output is currently enforced by the bus format input of the next component in the chain (panel/next-bridge), but that might change if we start dealing with panel/bridges supporting several input formats and expecting the LVDS encoder/decoder to select one. What we do need for the decoder case though, is a data-mapping prop, otherwise this LVDS bridge exposes a FIXED in-format and the previous element in the chain has to use its 'default' output format (which might not be appropriate). Maybe we should go for Sam's approach and expose a data-mapping prop on both ends of the bridge (that implies describing RGB/DPI bus width using the data-mapping prop), this way we wouldn't have to distinguish the encoder/decoder case. > > Then, I'm not sure what the property describes. Is it the number of data > lanes that the chip has ? Or the number of lanes routed on the board ? It's the number of lanes routed on the board. I'll clarify that. > Should it be specified only if the number of lanes on the board is > different than the maximum number of lanes of the hardware ? You mean default number of lanes (24)? Well, I guess defining it explicitly is not a bad thing, so, even if the default is already 24, I don't see a problem setting bus-width = <24>. Actually, maybe that's even better if we force new users to explicitly define the number of lanes exposed on the DPI interface, but we definitely need this default value if we want to keep things backward compatible. Not sure how to express that (it's not mandatory, it's not optional, it's recommended :-)). > A more > detailed description is needed. > > Updating the example would also be useful. I can do that too.
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>, Mark Rutland <mark.rutland@arm.com>, Jernej Skrabec <jernej.skrabec@siol.net>, Neil Armstrong <narmstrong@baylibre.com>, Andrey Smirnov <andrew.smirnov@gmail.com>, Jonas Karlman <jonas@kwiboo.se>, dri-devel@lists.freedesktop.org, Andrzej Hajda <a.hajda@samsung.com>, devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Thierry Reding <thierry.reding@gmail.com>, intel-gfx-trybot@lists.freedesktop.org, kernel@collabora.com, Sam Ravnborg <sam@ravnborg.org>, Chris Healy <cphealy@gmail.com> Subject: Re: [PATCH v10 09/12] dt-bindings: display: bridge: lvds-codec: Add new bus-width prop Date: Tue, 25 Feb 2020 10:13:54 +0100 [thread overview] Message-ID: <20200225101354.5f621ccb@collabora.com> (raw) In-Reply-To: <20200224223139.GA29578@pendragon.ideasonboard.com> On Tue, 25 Feb 2020 00:31:39 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Boris, > > Thank you for the patch. > > On Tue, Jan 28, 2020 at 02:55:11PM +0100, Boris Brezillon wrote: > > Add the bus-width property to describe the input bus format. > > > > v10: > > * Add changelog to the commit message > > * Add Rob's R-b > > > > v8 -> v9: > > * No changes > > > > v7: > > * Rebase on top of lvds-codec changes > > * Drop the data-mapping property > > > > v4 -> v6: > > * Not part of the series > > > > v3: > > * New patch > > > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> > > Reviewed-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/display/bridge/lvds-codec.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > index 8f373029f5d2..7c4e42f4de61 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > @@ -55,6 +55,14 @@ properties: > > description: | > > For LVDS encoders, port 0 is the parallel input > > For LVDS decoders, port 0 is the LVDS input > > + properties: > > + bus-width: > > + allOf: > > + - $ref: /schemas/types.yaml#/definitions/uint32 > > + - enum: [18, 24] > > + - default: 24 > > + description: > > + Number of data lines used to transmit the RGB data. > > This is a bit unclear. First of all, depending on whether the node is an > LVDS encoder or decoder, port@0 is either a parallel input or an LVDS > input. The property mentiones RGB data, does it mean it apply to LVDS > encoders only ? Or should it be in port@1 for LVDS decoders ? Right, I only considered the encoder case here. For the decoder case, we don't need a bus-width prop yet, as the bus format output is currently enforced by the bus format input of the next component in the chain (panel/next-bridge), but that might change if we start dealing with panel/bridges supporting several input formats and expecting the LVDS encoder/decoder to select one. What we do need for the decoder case though, is a data-mapping prop, otherwise this LVDS bridge exposes a FIXED in-format and the previous element in the chain has to use its 'default' output format (which might not be appropriate). Maybe we should go for Sam's approach and expose a data-mapping prop on both ends of the bridge (that implies describing RGB/DPI bus width using the data-mapping prop), this way we wouldn't have to distinguish the encoder/decoder case. > > Then, I'm not sure what the property describes. Is it the number of data > lanes that the chip has ? Or the number of lanes routed on the board ? It's the number of lanes routed on the board. I'll clarify that. > Should it be specified only if the number of lanes on the board is > different than the maximum number of lanes of the hardware ? You mean default number of lanes (24)? Well, I guess defining it explicitly is not a bad thing, so, even if the default is already 24, I don't see a problem setting bus-width = <24>. Actually, maybe that's even better if we force new users to explicitly define the number of lanes exposed on the DPI interface, but we definitely need this default value if we want to keep things backward compatible. Not sure how to express that (it's not mandatory, it's not optional, it's recommended :-)). > A more > detailed description is needed. > > Updating the example would also be useful. I can do that too. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-02-25 9:14 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-28 13:55 [PATCH v10 00/12] drm: Add support for bus-format negotiation Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 01/12] drm/bridge: Add a drm_bridge_state object Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 02/12] drm/rcar-du: Plug atomic state hooks to the default implementation Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 03/12] drm/bridge: analogix: " Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 04/12] drm/bridge: Patch atomic hooks to take a drm_bridge_state Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 05/12] drm/bridge: Add an ->atomic_check() hook Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 06/12] drm/bridge: Add the necessary bits to support bus format negotiation Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 07/12] drm/imx: pd: Use bus format/flags provided by the bridge when available Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 08/12] drm/bridge: lvds-codec: Implement basic bus format negotiation Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-02-24 23:03 ` Laurent Pinchart 2020-02-24 23:03 ` Laurent Pinchart 2020-02-25 6:15 ` Sam Ravnborg 2020-02-25 6:15 ` Sam Ravnborg 2020-02-25 8:44 ` Boris Brezillon 2020-02-25 8:44 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 09/12] dt-bindings: display: bridge: lvds-codec: Add new bus-width prop Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-31 17:12 ` Sam Ravnborg 2020-01-31 17:12 ` Sam Ravnborg 2020-01-31 17:23 ` Boris Brezillon 2020-01-31 17:23 ` Boris Brezillon 2020-02-24 22:31 ` Laurent Pinchart 2020-02-24 22:31 ` Laurent Pinchart 2020-02-25 9:13 ` Boris Brezillon [this message] 2020-02-25 9:13 ` Boris Brezillon 2020-03-09 10:35 ` Boris Brezillon 2020-03-09 10:35 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 10/12] drm/bridge: panel: Propage bus format/flags Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-31 17:25 ` Boris Brezillon 2020-01-31 17:25 ` Boris Brezillon 2020-02-24 22:34 ` Laurent Pinchart 2020-02-24 22:34 ` Laurent Pinchart 2020-02-25 8:45 ` Boris Brezillon 2020-02-25 8:45 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 11/12] drm/panel: simple: Fix the lt089ac29000 bus_format Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-28 13:55 ` [PATCH v10 12/12] ARM: dts: imx: imx51-zii-rdu1: Fix the display pipeline definition Boris Brezillon 2020-01-28 13:55 ` Boris Brezillon 2020-01-31 15:42 ` [PATCH v10 00/12] drm: Add support for bus-format negotiation Boris Brezillon 2020-01-31 15:42 ` Boris Brezillon 2020-01-31 16:51 ` Sam Ravnborg 2020-01-31 16:51 ` Sam Ravnborg 2020-01-31 18:08 ` Daniel Vetter 2020-01-31 18:08 ` Daniel Vetter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200225101354.5f621ccb@collabora.com \ --to=boris.brezillon@collabora.com \ --cc=a.hajda@samsung.com \ --cc=andrew.smirnov@gmail.com \ --cc=cphealy@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx-trybot@lists.freedesktop.org \ --cc=jernej.skrabec@siol.net \ --cc=jonas@kwiboo.se \ --cc=kernel@collabora.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=mark.rutland@arm.com \ --cc=narmstrong@baylibre.com \ --cc=nikita.yoush@cogentembedded.com \ --cc=robh+dt@kernel.org \ --cc=sam@ravnborg.org \ --cc=thierry.reding@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.