Re: [PATCH v9 0/4] drm/tidss: Add OLDI bridge support

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

Hi,

On 28/05/2025 15:25, Aradhya Bhatia wrote:
> Hello all,
> 
> This patch series adds support for the dual OLDI TXes supported in Texas
> Instruments' AM62x and AM62Px family of SoCs. The OLDI TX hardware supports
> single-lvds, lvds-clone, and dual-lvds modes. These TXes 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.
> 
> 
> * Regarding the Dependency Patches *
> Since the OLDI TXes have a hardware dependency with the parent VP(s), the OLDI
> configuration needs to happen before that VP is enabled for streaming. VP stream
> enable takes place in tidss_crtc_atomic_enable hook. I have posted patches[0]
> allowing DRM bridges to get pre-enabled before the CRTC of that bridge is
> enabled. Without those patches, some warnings or glitches may be observed.
> 
> 
> * Regarding the Drop of Clone Mode support *
> Another key point to note is that the support for clone mode has been dropped
> from the tidss OLDI driver, from v5 onwards. If the DT is configured for a clone
> mode, the driver will report an error and exit. This has been done because the
> driver was not supporting a specific case of clone mode where 2 OLDI sink
> bridges connected to the 2 OLDI TXes require active programming (unlike the
> simple-panels which do not). The driver does not support creation of two
> encoder-bridge pipelines (along with the parent tidss driver) to allow program
> any subsequent bridges (OLDI sinks and bridges thereafter).
> The code fragments that write the OLDI config to enable clone mode have been
> kept as they are, for future, but the driver will not continue to probe if it
> detects a clone mode configuration, for the time being.
> This drop of clone mode support can be undone by applying this _soft-tested_
> patch[6] on top of this series. This patch will revert the driver to previous
> revisions and will allow OLDI sinks that don't require active programming (for
> example: simple-panels) to work with the driver. Note that this isn't the ideal
> way to run clone mode, but it just works for any bridge pipeline after OLDT TX
> that does not require additional configuration after the OLDI (for example: a
> couple of simple lvds panels connected directly to the OLDI TXes in clone mode).
> 
> 
> These patches have been tested on AM625 based Beagleplay[3] platform with a
> Lincolntech LCD185 dual-lvds panel. The patches with complete support including
> the expected devicetree configuration of the OLDI TXes can be found in the
> "next_oldi-v9_1_tests" branch of my github fork[4]. This branch also has support
> for Microtips dual-lvds panel (SK-LCD1) which is compatible with the SK-AM625
> EVM platform.
> 
> I'd appreciate it if somebody can test it, and report back if they observe any
> issues.
> 
> Thanks,
> Aradhya
> 
> * Important note about the authorship of patches *
> All the patches in the of this series were authored when I owned a "ti.com"
> based email id, i.e. <a-bhatia1@ti.com>. This email id is not in use anymore,
> and all the work done later has been part of my personal work. Since the
> original patches were authored using TI's email id, I have maintained the
> original authorships as they are, as well as their sign offs.
> 
> I have further added another sign off that uses my current (and personal) email
> id, the one that is being used to send this revision, i.e.
> <aradhya.bhatia@linux.dev>.

Thanks! I will pick these up to drm-misc-next.

 Tomi