[PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property

[Laurent Pinchart]

Hi Maxime,

On Thu, Feb 20, 2020 at 06:53:07PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2020 at 08:10:06PM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> >>>> On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> >>>>> On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> >>>>>> SoCs that have multiple TCONs can use the two set of pins on the first TCON
> >>>>>> to drive a dual-link display. Add a property to enable the dual link.
> >>>>>>
> >>>>>> Signed-off-by: Maxime Ripard <maxime at cerno.tech>
> >>>>>> ---
> >>>>>>  .../bindings/display/allwinner,sun4i-a10-tcon.yaml         | 7 +++++++
> >>>>>>  1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> index 86ad617d2327..aa6dd8409dbc 100644
> >>>>>> --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> @@ -105,6 +105,13 @@ properties:
> >>>>>>          - const: edp
> >>>>>>          - const: lvds
> >>>>>>
> >>>>>> +  allwinner,lvds-dual-link:
> >>>>>> +    type: boolean
> >>>>>> +    description: |
> >>>>>> +      On a SoC with two TCON with LVDS support, the first TCON can
> >>>>>> +      operate over both pins sets to output in a dual-link setup. This
> >>>>>> +      will be triggered by setting this property.
> >>>>>
> >>>>> Could you maybe provide an example of how this property is supposed to
> >>>>> be used ? I'm especially wondering what ports are used in that case and
> >>>>> how they're connected.
> >>>>
> >>>> It's pretty trivial to support, it's only a property to set on the
> >>>> encoder node itself.
> >>>>
> >>>> I'm not really sure what you meant by your question with the ports
> >>>> though :/
> >>>
> >>> I assume that, in the single-link case, you have two TCON instances that
> >>> operate independently, each of them with one port that models an LVDS
> >>> connection to a panel.
> >>
> >> Indeed,
> >>
> >>> In the dual-link mode, how does that look like ? Does the TCON
> >>> instance that operate in dual-link mode have two ports in DT ? There
> >>> are two physical ports, so I think it makes sense to always have two
> >>> ports in DT. That's what we're doing for the LVDS encoders on R-Car
> >>> Gen3, in order to specify in DT which LVDS input of the dual-link
> >>> panel is connected to which LVDS output of the SoC. That allows
> >>> configuring the LVDS encoder to send the even and odd pixels on the
> >>> right port.
> >>
> >> As far as I can tell, you can't control that in our TCON. It just on
> >> more lanes, that's it. Also, we currently have multiple ports, to map
> >> another feature of the TCON, which is that it can drive directly a
> >> panel, or will send its output to the HDMI / TV encoders. Adding
> >> another port in that will break the current binding we have.
> >
> > This will create one issue though, in that the dual-link sinks are
> > supposed to have two input ports, in order to expose the odd and even
> > pixels ordering. If you have a single ouput port in your TCON, how will
> > you interface with such sinks ?
> 
> I guess we could create multiple endpoints in the same port? That's
> not going to be trivial either though given the current binding we
> have :/

That's however not really how endpoints are supposed to be used.

Let's try to find a solution. Could you show me a DT example that
explains why having two ports would create backward-compatibility issues
?

-- 
Regards,

Laurent Pinchart