Hi Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> In such a mode, the first LVDS encoder emits even data, and the
> second LVDS encoder emits odd data. This patch documents property
> renesas,swap-data, used to swap even and odd data around.
>
> Signed-off-by: Fabrizio Castro <[email protected]>
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> index dece79e..8980179 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -52,6 +52,11 @@ Optional properties:
> mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> and shall point to the second encoder to be used as a companion in dual-link
> mode. It shall not be set for any other LVDS encoder.
> +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> + emits even data, and the second LVDS encoder emits odd data. When property
> + renesas,swap-data is specified, the data emitted by the two encoders will be
> + swapped around. This property can only be used in conjunction with property
> + renesas,companion.
From an LVDS encoder point of view this is more a configuration option
than a description of the hardware. Wouldn't it be better for the LVDS
sink to report which of the odd or even pixels it expects on each of its
endpoints ? The LVDS encoder driver could then query that at runtime and
configure itself accordingly. Ideally this should be queried through the
drm_bridge_timings structure (or through a similar mean), not through
DT. An LVDS sink that has a fixed mapping of odd/even pixels to
endpoints wouldn't need the information to be specified in DT at all.
>
>
> Example:
--
Regards,
Laurent Pinchart
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart <[email protected]>
> Sent: 02 August 2019 08:44
> Subject: Re: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> > R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> > In such a mode, the first LVDS encoder emits even data, and the
> > second LVDS encoder emits odd data. This patch documents property
> > renesas,swap-data, used to swap even and odd data around.
> >
> > Signed-off-by: Fabrizio Castro <[email protected]>
> > ---
> > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > index dece79e..8980179 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > @@ -52,6 +52,11 @@ Optional properties:
> > mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> > and shall point to the second encoder to be used as a companion in dual-link
> > mode. It shall not be set for any other LVDS encoder.
> > +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> > + emits even data, and the second LVDS encoder emits odd data. When property
> > + renesas,swap-data is specified, the data emitted by the two encoders will be
> > + swapped around. This property can only be used in conjunction with property
> > + renesas,companion.
>
> From an LVDS encoder point of view this is more a configuration option
> than a description of the hardware. Wouldn't it be better for the LVDS
> sink to report which of the odd or even pixels it expects on each of its
> endpoints ?
Yes, that would be my preference too, and it would be better, I am just not entirely
what's the best place for this information though
> The LVDS encoder driver could then query that at runtime and
> configure itself accordingly. Ideally this should be queried through the
> drm_bridge_timings structure (or through a similar mean), not through
> DT. An LVDS sink that has a fixed mapping of odd/even pixels to
> endpoints wouldn't need the information to be specified in DT at all.
Isn't drm_bridge_timings specific for bridges?
Thanks!
Fab
>
> >
> >
> > Example:
>
> --
> Regards,
>
> Laurent Pinchart
Hi Fabrizio,
On Mon, Aug 05, 2019 at 08:59:51AM +0000, Fabrizio Castro wrote:
> > From: Laurent Pinchart <[email protected]>
> > Sent: 02 August 2019 08:44
> > Subject: Re: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
> >
> > Hi Fabrizio,
> >
> > Thank you for the patch.
> >
> > On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> > > R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> > > In such a mode, the first LVDS encoder emits even data, and the
> > > second LVDS encoder emits odd data. This patch documents property
> > > renesas,swap-data, used to swap even and odd data around.
> > >
> > > Signed-off-by: Fabrizio Castro <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > index dece79e..8980179 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > @@ -52,6 +52,11 @@ Optional properties:
> > > mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> > > and shall point to the second encoder to be used as a companion in dual-link
> > > mode. It shall not be set for any other LVDS encoder.
> > > +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> > > + emits even data, and the second LVDS encoder emits odd data. When property
> > > + renesas,swap-data is specified, the data emitted by the two encoders will be
> > > + swapped around. This property can only be used in conjunction with property
> > > + renesas,companion.
> >
> > From an LVDS encoder point of view this is more a configuration option
> > than a description of the hardware. Wouldn't it be better for the LVDS
> > sink to report which of the odd or even pixels it expects on each of its
> > endpoints ?
>
> Yes, that would be my preference too, and it would be better, I am just not entirely
> what's the best place for this information though
>
> > The LVDS encoder driver could then query that at runtime and
> > configure itself accordingly. Ideally this should be queried through the
> > drm_bridge_timings structure (or through a similar mean), not through
> > DT. An LVDS sink that has a fixed mapping of odd/even pixels to
> > endpoints wouldn't need the information to be specified in DT at all.
>
> Isn't drm_bridge_timings specific for bridges?
Its name makes it specific to bridges, but the information it contains
could equally apply to panels. I would thus use it for both, possibly
after renaming it.
--
Regards,
Laurent Pinchart
Hi Laurent,
> From: [email protected] <[email protected]> On Behalf Of Laurent Pinchart
> Sent: 05 August 2019 10:36
> Subject: Re: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
>
> Hi Fabrizio,
>
> On Mon, Aug 05, 2019 at 08:59:51AM +0000, Fabrizio Castro wrote:
> > > From: Laurent Pinchart <[email protected]>
> > > Sent: 02 August 2019 08:44
> > > Subject: Re: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
> > >
> > > Hi Fabrizio,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> > > > R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> > > > In such a mode, the first LVDS encoder emits even data, and the
> > > > second LVDS encoder emits odd data. This patch documents property
> > > > renesas,swap-data, used to swap even and odd data around.
> > > >
> > > > Signed-off-by: Fabrizio Castro <[email protected]>
> > > > ---
> > > > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > > index dece79e..8980179 100644
> > > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > > @@ -52,6 +52,11 @@ Optional properties:
> > > > mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> > > > and shall point to the second encoder to be used as a companion in dual-link
> > > > mode. It shall not be set for any other LVDS encoder.
> > > > +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> > > > + emits even data, and the second LVDS encoder emits odd data. When property
> > > > + renesas,swap-data is specified, the data emitted by the two encoders will be
> > > > + swapped around. This property can only be used in conjunction with property
> > > > + renesas,companion.
> > >
> > > From an LVDS encoder point of view this is more a configuration option
> > > than a description of the hardware. Wouldn't it be better for the LVDS
> > > sink to report which of the odd or even pixels it expects on each of its
> > > endpoints ?
> >
> > Yes, that would be my preference too, and it would be better, I am just not entirely
> > what's the best place for this information though
> >
> > > The LVDS encoder driver could then query that at runtime and
> > > configure itself accordingly. Ideally this should be queried through the
> > > drm_bridge_timings structure (or through a similar mean), not through
> > > DT. An LVDS sink that has a fixed mapping of odd/even pixels to
> > > endpoints wouldn't need the information to be specified in DT at all.
> >
> > Isn't drm_bridge_timings specific for bridges?
>
> Its name makes it specific to bridges, but the information it contains
> could equally apply to panels. I would thus use it for both, possibly
> after renaming it.
Will give this a try then.
Thanks,
Fab
>
> --
> Regards,
>
> Laurent Pinchart