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@xxxxxxxxxx> > >>>>>> --- > >>>>>> .../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
