Hi Laurent,
Thank you for your feedback!
From: Laurent Pinchart laurent.pinchart@ideasonboard.com 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 fabrizio.castro@bp.renesas.com
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