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
