Message-ID: <9ade7a5d-dd87-4a08-9fdd-c24eb20e733c@ideasonboard.com>
Date: Tue, 3 Dec 2024 20:36:04 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Aradhya Bhatia <aradhya.bhatia@...ux.dev>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Nishanth Menon
 <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
 Devarsh Thakkar <devarsht@...com>, Praneeth Bajjuri <praneeth@...com>,
 Udit Kumar <u-kumar1@...com>, Jayesh Choudhary <j-choudhary@...com>,
 Francesco Dolcini <francesco@...cini.it>,
 Alexander Sverdlin <alexander.sverdlin@...mens.com>,
 Max Krummenacher <max.oss.09@...il.com>,
 DRI Development List <dri-devel@...ts.freedesktop.org>,
 Devicetree List <devicetree@...r.kernel.org>,
 Linux Kernel List <linux-kernel@...r.kernel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jyri Sarha <jyri.sarha@....fi>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Thomas Zimmermann <tzimmermann@...e.de>, Maxime Ripard <mripard@...nel.org>,
 David Airlie <airlied@...il.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Simona Vetter <simona@...ll.ch>
Subject: Re: [PATCH v4 0/3] drm/tidss: Add OLDI bridge support

Hi,

On 03/12/2024 20:14, Aradhya Bhatia wrote:
> Hi,
> 
> On 03/12/24 17:42, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 24/11/2024 16:36, Aradhya Bhatia wrote:
>>> Hello all,
>>>
>>> This patch series add support for the dual OLDI TXes supported in Texas
>>> Instruments' AM62x and AM62Px family of SoCs. The OLDI TXes support
>>> single-lvds
>>> lvds-clone, and dual-lvds modes. These have now been represented
>>> through DRM
>>> bridges within TI-DSS.
>>>
>>>    - Some history and hardware description for this patch series.
>>>
>>> This patch series is a complete re-vamp from the previously posted
>>> series[1] and
>>> hence, the version index has been reset to v1. The OLDI support from
>>> that series
>>> was dropped and only the base support for AM62x DSS was kept (and
>>> eventually
>>> merged)[2].
>>>
>>> The OLDI display that the tidss driver today supports, could not be
>>> extended for
>>> the newer SoCs. The OLDI display in tidss is modelled after the DSS
>>> and OLDI
>>> hardware in the AM65x SoC. The DSS in AM65x SoC, has two video-ports.
>>> Both these
>>> video-ports (VP) output DPI video signals. One of the DPI output (from
>>> VP1) from
>>> the DSS connects to a singular OLDI TX present inside the SoC. There
>>> is no other
>>> way for the DPI from VP1 to be taken out of the SoC. The other DPI output
>>> however - the one from VP2 - is taken out of the SoC as is. Hence we
>>> have an
>>> OLDI bus output and a DPI bus output from the SoC. Since the VP1 and
>>> OLDI are
>>> tightly coupled, the tidss driver considers them as a single entity.
>>> That is
>>> why, any OLDI sink connects directly to the DSS ports in the OF graphs.
>>>
>>> The newer SoCs have varying DSS and OLDI integrations.
>>>
>>> The AM62x DSS also has 2 VPs. The 2nd VP, VP2, outputs DPI signals
>>> which are
>>> taken out of the SoC - similar to the AM65x above. For the VP1, there
>>> are 2 OLDI
>>> TXes. These OLDI TXes can only receive DPI signals from VP1, and don't
>>> connect
>>> to VP2 at all.
>>>
>>> The AM62Px SoC has 2 OLDI TXes like AM62x SoC. However, the AM62Px SoC
>>> also has
>>> 2 separate DSSes. The 2 OLDI TXes can now be shared between the 2 VPs
>>> of the 2
>>> DSSes.
>>>
>>> The addition of the 2nd OLDI TX (and a 2nd DSS in AM62Px) creates a
>>> need for
>>> some major changes for a full feature experience.
>>>
>>> 1. The OF graph needs to be updated to accurately show the data flow.
>>> 2. The tidss and OLDI drivers now need to support the dual-link and
>>> the cloned
>>>      single-link OLDI video signals.
>>> 3. The drivers also need to support the case where 2 OLDI TXes are
>>> connected to
>>>      2 different VPs - thereby creating 2 independent streams of
>>> single-link OLDI
>>>      outputs.
>>>
>>> Note that the OLDI does not have registers of its own. It is still
>>> dependent on
>>> the parent VP. The VP that provides the DPI video signals to the OLDI
>>> TXes, also
>>> gives the OLDI TXes all the config data. That is to say, the hardware
>>> doesn't
>>> sit on the bus directly - but does so through the DSS.
>>>
>>> In light of all of these hardware variations, it was decided to have a
>>> separate
>>> OLDI driver (unlike AM65x) but not entirely separate so as to be a
>>> platform
>>> device. The OLDI TXes are now being represented as DRM bridges under
>>> the tidss.
>>>
>>> Also, since the DRM framework only really supports a linear encoder-
>>> bridge
>>> chain, the OLDI driver creates a DRM bridge ONLY for the primary OLDI
>>> TX in
>>> cases of dual-link or cloned single-link OLDI modes. That bridge then
>>> attaches
>>
>> How does the clone case work, then? There are two panels, what does the
>> second one connect to?
> 
> For the clone case, the devicetree will show the true connections - as
> they are in the hardware.
> 
> 2 endpoints from a single DSS VP devicetree port will be connected to 2
> OLDIs, OLDI0 and OLDI1. The outputs of these OLDIs will be connected to
> 2 distinct single-link panels.
> 
> The driver and DRM side of things do not show the same picture, however.
> The tidss_oldi code creates and registers a drm_bridge only for the
> primary OLDI. The driver is capable of detecting the expected OLDI mode,
> and if a companion OLDI is present, then the primary OLDI drm_bridge
> keeps a note of that.
> 
> The clock and config resources are shared between the primary and
> companion OLDI hardware. So configuring the primary OLDI takes care of
> the companion too.
> The only case where it is not shared is the OLDI IO bit in the Control
> MMR (ctrl_mmr) region. But, since the primary OLDI drm_bridge remains
> aware about the presence of companion OLDI, it makes sure to enable /
> disable the comapnion OLDI IO when required.

But if there's just one bridge (for the first oldi), how is the second 
panel connected to the DRM pipeline? Who e.g. calls the 
drm_panel_funcs.enable() in the panel driver for the second panel?

Or, say, if we have two LVDS->HDMI bridges, with the cloning setup, how 
does all the plumbing work if "DRM framework only really supports a 
linear encoder-bridge chain"?

  Tomi

Powered by blists - more mailing lists