On Thu, Feb 20, 2020 at 09:13:39PM +0200, Laurent Pinchart wrote: > 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 > ? Sure, here is what the DT looks like for the SoC this patch was relevant for (but we have the issue on multiple SoCs, all sharing pretty much the same binding as far as ports go): https://elixir.bootlin.com/linux/v5.6-rc3/source/arch/arm/boot/dts/sun7i-a20.dtsi#L406 And here is the binding part: https://elixir.bootlin.com/linux/v5.6-rc3/source/arch/arm/boot/dts/sun7i-a20.dtsi#L406 As you can see, in that binding, ports were used to differentiate between output and input, each of the output being an endpoint (since we can't have the TCON driving multiple output at once). Adding multiple ports would kind of break that, and would break the general idea behind that binding (and the rest of the display pipeline). Maxime
Attachment:
signature.asc
Description: PGP signature
