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
to the tidss's display core - which consists of a CRTC, an Encoder (dummy) and a
bridge (dummy). On the other end, it attaches to OLDI sinks (panels or other
bridges).

Since the OLDI TX have a hardware dependency with the VP, 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 a patch allowing DRM
bridges to get pre-enabled before the CRTC of that bridge is enabled[0]. Without
that patch, some warnings or glitches can be seen.

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_v4_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.

Due to lack of hardware, I haven't been able to test single-link / cloned
single-link OLDI modes. I have only used a sample cloned single-link DTBO and
booted the board with it. I didn't see any probe_deferred errors (as seen
previously), and the `kmsprint` utility enumerated the display details fine.

Regardless, I'd appreciate it if somebody can test it, and report back if they
observe any issues.

Thanks,
Aradhya


Additional Notes:

* Important note about a false positive in dtbs_check *
Both the ports, port0 and port1, are required for the OLDI functionality to
work. The schema suggests this condition too. Additionally, the OLDI devicetree
node is expected to be defined in the soc.dtsi file, and kept as disabled.
Over the current platforms (Beagleplay and SK-AM625 EVM), the OLDI panel is not
always attached, and hence we use a DT overlay to add panel details - which is
where we enable the OLDI nodes. The structure of files is like this -

- soc.dtsi                  (OLDI disabled)
- soc-baseboard.dts         (OLDI disabled)
- soc-baseboard-panel.dtso  (OLDI enabled)

During dtbs_check runs, it was observed that the check was not able to rule out
OLDI issues even when its DT was disabled in the soc-baseboard.dts. It is
impractical and impossible to add OLDI ports prior to the panel overlay file.
While the dtbs_check usually ignores checking disabled devicetree nodes, it was
unable to do so in the OLDI's case.


* 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>.

---

Change Log:
V4:
  - Implement fixes suggested by Krzysztof Kozlowski:
    - Squash patches v3:2/4 and v3:3/4 to v4:2/3, and add more hardware details
      in commit description.
    - Change the serial clock name for OLDI, from "s_clk" to "serial".
    - Fix the required condition in the OLDI schema.
    - Other minor fixes.
  - Change "oldi-txes" OLDI DT node name to "oldi-transmitters".
  - Update secondary-OLDI property requirements to be more relaxing for AM62P
    DSS configuration.

V3:
  - Fix the dt_binding_check warning in patch 3/4[5] by adding
    "additionalProperties" constraint.

V2:
  - Add all the R-b and A-b tags from Laurent Pinchart, Rob Herring, and
    Tomi Valkeinen.
  - Reword the subject for patch 1/4.
  - Reword the commit descriptions to add proper hardware detail.
  - Drop the change in schema reference for port@0 in patch 3/4.
  - Lots of improvements for patch 4/4.
    * Refactor OLDI selection logic in tidss_oldi_tx_power().
    * Add "companion_instance" support to identify the OLDI index in
      dual-link or cloned sinle-link modes.
    * De-initialize tidss_oldi during tidss removal.
    * Use dev_err_probe() instead of dev_err().
    * Drop OLDI(n) macro.
    * Move OLDI Config register bits to tidss_dispc_regs.h.
    * Drop oldi bridge atomic_check().
    * s/%d/%u for all print instances of "oldi_instance".
    * Move OLDI init after DISPC init in tidss_probe.
    * Use devm_drm_of_get_bridge() instead of
      drm_of_find_panel_or_bridge() to find the next bridge and drop all
      the drm_panel support from tidss_oldi.

Previous revisions:
V3: https://lore.kernel.org/all/20240716084248.1393666-1-a-bhatia1@ti.com/
V2: https://lore.kernel.org/all/20240715200953.1213284-1-a-bhatia1@ti.com/
V1: https://lore.kernel.org/all/20240511193055.1686149-1-a-bhatia1@ti.com/


[0]: Dependency Patch: 
("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/20240622110929.3115714-11-a-bhatia1@ti.com/

[1]: AM62 OLDI Series - v7
https://lore.kernel.org/all/20230125113529.13952-1-a-bhatia1@ti.com/

[2]: AM62 DSS Series - v9
https://lore.kernel.org/all/20230616150900.6617-1-a-bhatia1@ti.com/

[3]: TI AM625 SoC based Beagleplay platform
https://www.beagleboard.org/boards/beagleplay

[4]: GitHub Fork for OLDI tests
https://github.com/aradhya07/linux-ab/tree/next_oldi_v4_tests

[5]: ("ti,am65x-dss.yaml: oldi-txes: Missing additionalProperties/
      unevaluatedProperties constraint")
https://lore.kernel.org/all/172107979988.1595945.9666141982402158422.robh@kernel.org/

Aradhya Bhatia (3):
  dt-bindings: display: ti,am65x-dss: Re-indent the example
  dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
  drm/tidss: Add OLDI bridge support

 .../bindings/display/ti/ti,am625-oldi.yaml    | 119 ++++
 .../bindings/display/ti/ti,am65x-dss.yaml     | 195 ++++++-
 MAINTAINERS                                   |   1 +
 drivers/gpu/drm/tidss/Makefile                |   3 +-
 drivers/gpu/drm/tidss/tidss_dispc.c           |  20 +-
 drivers/gpu/drm/tidss/tidss_dispc.h           |   4 +
 drivers/gpu/drm/tidss/tidss_dispc_regs.h      |  14 +
 drivers/gpu/drm/tidss/tidss_drv.c             |   9 +
 drivers/gpu/drm/tidss/tidss_drv.h             |   5 +
 drivers/gpu/drm/tidss/tidss_oldi.c            | 537 ++++++++++++++++++
 drivers/gpu/drm/tidss/tidss_oldi.h            |  51 ++
 11 files changed, 935 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
 create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.h


base-commit: cfba9f07a1d6aeca38f47f1f472cfb0ba133d341
-- 
2.34.1

Thank you for the patches, Aradhya!

On Sun, 2024-11-24 at 20:06 +0530, Aradhya Bhatia wrote:
> Regardless, I'd appreciate it if somebody can test it, and report back if they
> observe any issues.

I've tried to test the patchset with necessary pre-requisites and DT additions
with a single channel LVDS pannel and while I'm not successful yet, I've also noticed
the following warning:

tidss 30200000.dss: vp0: Clock rate 24285714 differs over 5% from requested 37000000

even though later the clock seems to be correctly set up:

$ cat /sys/kernel/debug/clk/clk_summary 

                                 enable  prepare  protect                                duty  hardware                            connection
   clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
---------------------------------------------------------------------------------------------------------------------------------------------
 clk:186:6                           1       1        0        250000000   0          0     50000      Y   30200000.dss                    fck                      
                                                                                                           deviceless                      no_connection_id         
 clk:186:4                           0       0        0        0           0          0     50000      Y   deviceless                      no_connection_id         
 clk:186:3                           0       0        0        170000000   0          0     50000      Y   deviceless                      no_connection_id         
    clk:186:2                        0       0        0        170000000   0          0     50000      Y      30200000.dss                    vp2                      
                                                                                                              deviceless                      no_connection_id         
 clk:186:0                           1       1        0        259090909   0          0     50000      Y   oldi@0                          serial                   
                                                                                                           deviceless                      no_connection_id         
    clock-divider-oldi               1       1        0        37012987    0          0     50000      Y      30200000.dss                    vp1                      

Looks like "clock-divider-oldi" doesn't propagate clk_set_rate() to the parent,
but the parent is being set later independently?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Hi Alexander,

Thank you for testing and reviewing the patches!

On 19/03/25 23:30, Sverdlin, Alexander wrote:
> Thank you for the patches, Aradhya!
> 
> On Sun, 2024-11-24 at 20:06 +0530, Aradhya Bhatia wrote:
>> Regardless, I'd appreciate it if somebody can test it, and report back if they
>> observe any issues.
> 
> I've tried to test the patchset with necessary pre-requisites and DT additions
> with a single channel LVDS pannel and while I'm not successful yet, I've also noticed
> the following warning:
> 
> tidss 30200000.dss: vp0: Clock rate 24285714 differs over 5% from requested 37000000
> 
> even though later the clock seems to be correctly set up:
> 
> $ cat /sys/kernel/debug/clk/clk_summary 
> 
>                                  enable  prepare  protect                                duty  hardware                            connection
>    clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
> ---------------------------------------------------------------------------------------------------------------------------------------------
>  clk:186:6                           1       1        0        250000000   0          0     50000      Y   30200000.dss                    fck                      
>                                                                                                            deviceless                      no_connection_id         
>  clk:186:4                           0       0        0        0           0          0     50000      Y   deviceless                      no_connection_id         
>  clk:186:3                           0       0        0        170000000   0          0     50000      Y   deviceless                      no_connection_id         
>     clk:186:2                        0       0        0        170000000   0          0     50000      Y      30200000.dss                    vp2                      
>                                                                                                               deviceless                      no_connection_id         
>  clk:186:0                           1       1        0        259090909   0          0     50000      Y   oldi@0                          serial                   
>                                                                                                            deviceless                      no_connection_id         
>     clock-divider-oldi               1       1        0        37012987    0          0     50000      Y      30200000.dss                    vp1                      
> 
> Looks like "clock-divider-oldi" doesn't propagate clk_set_rate() to the parent,
> but the parent is being set later independently?
> 

Yes, you are right. The "clock-divider-oldi" does not propagate the
clk_set_rate() to the parent.

The actual parent clock is now owned by the oldi bridge driver, and that
is what sets the clock rate (7 * pixel freq). The equivalent action from
tidss vp (DRM crtc) is a no op in cases of OLDI display pipeline.

Usually, the DRM crtc is enabled first, before _any_ of the DRM bridges
get pre_enabled or enabled.

Since, OLDI is a DRM bridge, the OLDI enable (and by extension the
actual clk_set_rate()) takes place _after_ the DRM crtc has been
enabled (which is why you see the parent being set later on).

DRM crtc enable is where tidss vp attempts (and fails) to set the clock
rate, causing the warning you see initially.


I have attempted to re-order the bridge pre_enable and crtc enable calls
in these patches[0], separately.

While you have mentioned that you did add the prerequisites, could you
confirm that you applied the (now older) dependency patch mentioned in
the v4 cover-letter[1]?
Ideally, you should not observe these concerns if [1] were successfully
applied.

More importantly, if you are already on latest linux-next, I would
request you to use v6 of this OLDI series[2], along with the latest
dependency patches[0], as the older dependency patch is simply not
applicable on latest kernel anymore! =)

I'd appreciate it if you are able to test the latest revisions on your
single-link setup, and report back any issue you see! Thank you! =)


-- 
Regards
Aradhya



[0]: Pre Requisite patches that re-order crtc/encoder/bridge sequences
(latest revision).

a. ("drm/atomic-helper: Refactor crtc & encoder-bridge op loops into
separate functions")
https://lore.kernel.org/all/20250226155737.565931-3-aradhya.bhatia@linux.dev/

b. ("drm/atomic-helper: Separate out bridge pre_enable/post_disable from
enable/disable")
https://lore.kernel.org/all/20250226155737.565931-4-aradhya.bhatia@linux.dev/

c. ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/20250226155737.565931-5-aradhya.bhatia@linux.dev/


[1]: Dependency patch mentioned in v4 OLDI series.
("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/20240622110929.3115714-11-a-bhatia1@ti.com/


[2]: Latest OLDI series (v6)
https://lore.kernel.org/all/20250226181300.756610-1-aradhya.bhatia@linux.dev/

Hi Aradhya!

On Thu, 2025-03-20 at 18:54 +0530, Aradhya Bhatia wrote:
> > I've tried to test the patchset with necessary pre-requisites and DT additions
> > with a single channel LVDS pannel and while I'm not successful yet, I've also noticed
> > the following warning:
> > 
> > tidss 30200000.dss: vp0: Clock rate 24285714 differs over 5% from requested 37000000

...

> While you have mentioned that you did add the prerequisites, could you
> confirm that you applied the (now older) dependency patch mentioned in
> the v4 cover-letter[1]?
> Ideally, you should not observe these concerns if [1] were successfully
> applied.
> 
> More importantly, if you are already on latest linux-next, I would
> request you to use v6 of this OLDI series[2], along with the latest
> dependency patches[0], as the older dependency patch is simply not
> applicable on latest kernel anymore! =)

Thanks for all the hints and links! I can confirm that with linux-next and this
time all the necessary dependencies applied, I don't see the above warning.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Hi Alexander,

On 26/03/25 00:27, Sverdlin, Alexander wrote:
> Hi Aradhya!
> 
> On Thu, 2025-03-20 at 18:54 +0530, Aradhya Bhatia wrote:
>>> I've tried to test the patchset with necessary pre-requisites and DT additions
>>> with a single channel LVDS pannel and while I'm not successful yet, I've also noticed
>>> the following warning:
>>>
>>> tidss 30200000.dss: vp0: Clock rate 24285714 differs over 5% from requested 37000000
> 
> ...
> 
>> While you have mentioned that you did add the prerequisites, could you
>> confirm that you applied the (now older) dependency patch mentioned in
>> the v4 cover-letter[1]?
>> Ideally, you should not observe these concerns if [1] were successfully
>> applied.
>>
>> More importantly, if you are already on latest linux-next, I would
>> request you to use v6 of this OLDI series[2], along with the latest
>> dependency patches[0], as the older dependency patch is simply not
>> applicable on latest kernel anymore! =)
> 
> Thanks for all the hints and links! I can confirm that with linux-next and this
> time all the necessary dependencies applied, I don't see the above warning.
> 

I am glad it worked! Thank you for taking the time out, and testing the
patches!  =)

-- 
Regards
Aradhya

Hi Aradhya!

On Thu, 2025-03-20 at 18:54 +0530, Aradhya Bhatia wrote:
> While you have mentioned that you did add the prerequisites, could you
> confirm that you applied the (now older) dependency patch mentioned in
> the v4 cover-letter[1]?
> Ideally, you should not observe these concerns if [1] were successfully
> applied.

Seems that I've indeed missed most of the dependencies and only had
"drm/bridge: Introduce early_enable and late disable" so that it builds ;-)

> More importantly, if you are already on latest linux-next, I would
> request you to use v6 of this OLDI series[2], along with the latest
> dependency patches[0], as the older dependency patch is simply not
> applicable on latest kernel anymore! =)
> 
> I'd appreciate it if you are able to test the latest revisions on your
> single-link setup, and report back any issue you see! Thank you! =)

Thanks for the references!
I'll update, test and get back to you!

> [0]: Pre Requisite patches that re-order crtc/encoder/bridge sequences
> (latest revision).
> 
> a. ("drm/atomic-helper: Refactor crtc & encoder-bridge op loops into
> separate functions")
> https://lore.kernel.org/all/20250226155737.565931-3-aradhya.bhatia@linux.dev/
> 
> b. ("drm/atomic-helper: Separate out bridge pre_enable/post_disable from
> enable/disable")
> https://lore.kernel.org/all/20250226155737.565931-4-aradhya.bhatia@linux.dev/
> 
> c. ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
> https://lore.kernel.org/all/20250226155737.565931-5-aradhya.bhatia@linux.dev/
> 
> 
> [1]: Dependency patch mentioned in v4 OLDI series.
> ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
> https://lore.kernel.org/all/20240622110929.3115714-11-a-bhatia1@ti.com/
> 
> 
> [2]: Latest OLDI series (v6)
> https://lore.kernel.org/all/20250226181300.756610-1-aradhya.bhatia@linux.dev/

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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?

> to the tidss's display core - which consists of a CRTC, an Encoder (dummy) and a
> bridge (dummy). On the other end, it attaches to OLDI sinks (panels or other
> bridges).
> 
> Since the OLDI TX have a hardware dependency with the VP, 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 a patch allowing DRM
> bridges to get pre-enabled before the CRTC of that bridge is enabled[0]. Without
> that patch, some warnings or glitches can be seen.
> 
> 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_v4_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.
> 
> Due to lack of hardware, I haven't been able to test single-link / cloned
> single-link OLDI modes. I have only used a sample cloned single-link DTBO and
> booted the board with it. I didn't see any probe_deferred errors (as seen
> previously), and the `kmsprint` utility enumerated the display details fine.
> 
> Regardless, I'd appreciate it if somebody can test it, and report back if they
> observe any issues.
> 
> Thanks,
> Aradhya
> 
> 
> Additional Notes:
> 
> * Important note about a false positive in dtbs_check *
> Both the ports, port0 and port1, are required for the OLDI functionality to
> work. The schema suggests this condition too. Additionally, the OLDI devicetree
> node is expected to be defined in the soc.dtsi file, and kept as disabled.
> Over the current platforms (Beagleplay and SK-AM625 EVM), the OLDI panel is not
> always attached, and hence we use a DT overlay to add panel details - which is
> where we enable the OLDI nodes. The structure of files is like this -
> 
> - soc.dtsi                  (OLDI disabled)
> - soc-baseboard.dts         (OLDI disabled)
> - soc-baseboard-panel.dtso  (OLDI enabled)
> 
> During dtbs_check runs, it was observed that the check was not able to rule out
> OLDI issues even when its DT was disabled in the soc-baseboard.dts. It is
> impractical and impossible to add OLDI ports prior to the panel overlay file.
> While the dtbs_check usually ignores checking disabled devicetree nodes, it was
> unable to do so in the OLDI's case.

While there might be something amiss with dtbs_check, what's the problem 
with adding both port nodes to the soc.dtsi? If you have no endpoints 
there, it's not connected to anything.

  Tomi

> 
> 
> * 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>.
> 
> ---
> 
> Change Log:
> V4:
>    - Implement fixes suggested by Krzysztof Kozlowski:
>      - Squash patches v3:2/4 and v3:3/4 to v4:2/3, and add more hardware details
>        in commit description.
>      - Change the serial clock name for OLDI, from "s_clk" to "serial".
>      - Fix the required condition in the OLDI schema.
>      - Other minor fixes.
>    - Change "oldi-txes" OLDI DT node name to "oldi-transmitters".
>    - Update secondary-OLDI property requirements to be more relaxing for AM62P
>      DSS configuration.
> 
> V3:
>    - Fix the dt_binding_check warning in patch 3/4[5] by adding
>      "additionalProperties" constraint.
> 
> V2:
>    - Add all the R-b and A-b tags from Laurent Pinchart, Rob Herring, and
>      Tomi Valkeinen.
>    - Reword the subject for patch 1/4.
>    - Reword the commit descriptions to add proper hardware detail.
>    - Drop the change in schema reference for port@0 in patch 3/4.
>    - Lots of improvements for patch 4/4.
>      * Refactor OLDI selection logic in tidss_oldi_tx_power().
>      * Add "companion_instance" support to identify the OLDI index in
>        dual-link or cloned sinle-link modes.
>      * De-initialize tidss_oldi during tidss removal.
>      * Use dev_err_probe() instead of dev_err().
>      * Drop OLDI(n) macro.
>      * Move OLDI Config register bits to tidss_dispc_regs.h.
>      * Drop oldi bridge atomic_check().
>      * s/%d/%u for all print instances of "oldi_instance".
>      * Move OLDI init after DISPC init in tidss_probe.
>      * Use devm_drm_of_get_bridge() instead of
>        drm_of_find_panel_or_bridge() to find the next bridge and drop all
>        the drm_panel support from tidss_oldi.
> 
> Previous revisions:
> V3: https://lore.kernel.org/all/20240716084248.1393666-1-a-bhatia1@ti.com/
> V2: https://lore.kernel.org/all/20240715200953.1213284-1-a-bhatia1@ti.com/
> V1: https://lore.kernel.org/all/20240511193055.1686149-1-a-bhatia1@ti.com/
> 
> 
> [0]: Dependency Patch:
> ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
> https://lore.kernel.org/all/20240622110929.3115714-11-a-bhatia1@ti.com/
> 
> [1]: AM62 OLDI Series - v7
> https://lore.kernel.org/all/20230125113529.13952-1-a-bhatia1@ti.com/
> 
> [2]: AM62 DSS Series - v9
> https://lore.kernel.org/all/20230616150900.6617-1-a-bhatia1@ti.com/
> 
> [3]: TI AM625 SoC based Beagleplay platform
> https://www.beagleboard.org/boards/beagleplay
> 
> [4]: GitHub Fork for OLDI tests
> https://github.com/aradhya07/linux-ab/tree/next_oldi_v4_tests
> 
> [5]: ("ti,am65x-dss.yaml: oldi-txes: Missing additionalProperties/
>        unevaluatedProperties constraint")
> https://lore.kernel.org/all/172107979988.1595945.9666141982402158422.robh@kernel.org/
> 
> Aradhya Bhatia (3):
>    dt-bindings: display: ti,am65x-dss: Re-indent the example
>    dt-bindings: display: ti: Add schema for AM625 OLDI Transmitter
>    drm/tidss: Add OLDI bridge support
> 
>   .../bindings/display/ti/ti,am625-oldi.yaml    | 119 ++++
>   .../bindings/display/ti/ti,am65x-dss.yaml     | 195 ++++++-
>   MAINTAINERS                                   |   1 +
>   drivers/gpu/drm/tidss/Makefile                |   3 +-
>   drivers/gpu/drm/tidss/tidss_dispc.c           |  20 +-
>   drivers/gpu/drm/tidss/tidss_dispc.h           |   4 +
>   drivers/gpu/drm/tidss/tidss_dispc_regs.h      |  14 +
>   drivers/gpu/drm/tidss/tidss_drv.c             |   9 +
>   drivers/gpu/drm/tidss/tidss_drv.h             |   5 +
>   drivers/gpu/drm/tidss/tidss_oldi.c            | 537 ++++++++++++++++++
>   drivers/gpu/drm/tidss/tidss_oldi.h            |  51 ++
>   11 files changed, 935 insertions(+), 23 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
>   create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.c
>   create mode 100644 drivers/gpu/drm/tidss/tidss_oldi.h
> 
> 
> base-commit: cfba9f07a1d6aeca38f47f1f472cfb0ba133d341

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.

> 
>> to the tidss's display core - which consists of a CRTC, an Encoder
>> (dummy) and a
>> bridge (dummy). On the other end, it attaches to OLDI sinks (panels or
>> other
>> bridges).
>>
>> Since the OLDI TX have a hardware dependency with the VP, 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 a patch allowing
>> DRM
>> bridges to get pre-enabled before the CRTC of that bridge is
>> enabled[0]. Without
>> that patch, some warnings or glitches can be seen.
>>
>> 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_v4_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.
>>
>> Due to lack of hardware, I haven't been able to test single-link / cloned
>> single-link OLDI modes. I have only used a sample cloned single-link
>> DTBO and
>> booted the board with it. I didn't see any probe_deferred errors (as seen
>> previously), and the `kmsprint` utility enumerated the display details
>> fine.
>>
>> Regardless, I'd appreciate it if somebody can test it, and report back
>> if they
>> observe any issues.
>>
>> Thanks,
>> Aradhya
>>
>>
>> Additional Notes:
>>
>> * Important note about a false positive in dtbs_check *
>> Both the ports, port0 and port1, are required for the OLDI
>> functionality to
>> work. The schema suggests this condition too. Additionally, the OLDI
>> devicetree
>> node is expected to be defined in the soc.dtsi file, and kept as
>> disabled.
>> Over the current platforms (Beagleplay and SK-AM625 EVM), the OLDI
>> panel is not
>> always attached, and hence we use a DT overlay to add panel details -
>> which is
>> where we enable the OLDI nodes. The structure of files is like this -
>>
>> - soc.dtsi                  (OLDI disabled)
>> - soc-baseboard.dts         (OLDI disabled)
>> - soc-baseboard-panel.dtso  (OLDI enabled)
>>
>> During dtbs_check runs, it was observed that the check was not able to
>> rule out
>> OLDI issues even when its DT was disabled in the soc-baseboard.dts. It is
>> impractical and impossible to add OLDI ports prior to the panel
>> overlay file.
>> While the dtbs_check usually ignores checking disabled devicetree
>> nodes, it was
>> unable to do so in the OLDI's case.
> 
> While there might be something amiss with dtbs_check, what's the problem
> with adding both port nodes to the soc.dtsi? If you have no endpoints
> there, it's not connected to anything.
>

Ran dtbs_check with this. The errors are silenced indeed. I didn't
really like having empty ports in an already long DSS devicetree node,
but this way the checks remain clean. I will use this for DT patches.
Thank you! =)

> 
[...]
> 

-- 
Regards
Aradhya

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

Hi,

On 04/12/24 00:06, Tomi Valkeinen wrote:
> 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"?
> 

Right... The driver does not account for such a case at present. The
simple panels don't require any additional programming, which is why a
clone mode with them just happens to work out.

Since there is still only 1 VP behind this, there could only be a single
crtc. Perhaps, we can have an additional tidss encoder (connected to the
same crtc) to start this another encoder-bridge chain. I am still murky
with the details here, but I will try to see what needs to be done.

Thank you! =)


-- 
Regards
Aradhya