Message-ID: <20260130122754.4ywqarmjzgnhih7f@recreate>
Date: Fri, 30 Jan 2026 06:27:54 -0600
From: Nishanth Menon <nm@...com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
CC: Swamil Jain <s-jain1@...com>, <jyri.sarha@....fi>, <airlied@...il.com>,
	<simona@...ll.ch>, <maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
	<tzimmermann@...e.de>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>, <aradhya.bhatia@...ux.dev>, <mwalle@...nel.org>,
	<dri-devel@...ts.freedesktop.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <devarsht@...com>, <praneeth@...com>,
	<u-kumar1@...com>
Subject: Re: [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss
 compatible

On 14:00-20260130, Tomi Valkeinen wrote:
> Hi,
> 
> On 19/01/2026 12:10, Tomi Valkeinen wrote:
> > Hi,
> > 
> > On 16/01/2026 11:54, Swamil Jain wrote:
> >> TI's AM62P SoC contains two instances of the TI Keystone Display
> >> SubSystem (DSS), each with two video ports and two video planes. These
> >> instances support up to three independent video streams through OLDI,
> >> DPI, and DSI interfaces. The OLDI interfaces utilizes two OLDI
> >> transmitters OLDI0 and OLDI1.
> >>
> >> DSS0 (first instance) supports:
> >>  - With respect to OLDI Tx interfaces, DSS0 instance can either drive
> >>    both OLDI0 Tx and OLDI1 Tx together (e.g. dual link mode or clone
> >>    mode) or can only drive OLDI0 Tx in single link mode with OLDI1 being
> >>    utilized by DSS1 or left unused.
> >>  - DPI output from video port 2.
> >>
> >> DSS1 (second instance) supports:
> >>  - With respect to OLDI Tx interfaces, DSS1 instance can only drive
> >>    OLDI1 Tx given DSS0 is not utilizing that as described above.
> >>  - DSI controller output from video port 2.
> >>
> >> The two OLDI transmitters can be configured in clone mode to drive a
> >> pair of identical OLDI single-link displays. DPI outputs from
> >> DSS0 VP2, DSS1 VP1, and DSS1 VP2 are multiplexed, allowing only one
> >> DPI output at a time.
> >>
> >> Add the compatible string "ti,am62p-dss" and update related
> >> description accordingly.
> >>
> >> AM62P has different power domains for DSS and OLDI compared to other
> >> Keystone SoCs. DSS0 can have up to 3 power-domains for DSS0, OLDI0 and
> >> OLDI1, and DSS1 can have up to 2 power-domains for DSS1 and OLDI1.
> >>
> >> Signed-off-by: Swamil Jain <s-jain1@...com>
> >> ---
> >>  .../bindings/display/ti/ti,am65x-dss.yaml     | 37 ++++++++++++++++++-
> >>  1 file changed, 35 insertions(+), 2 deletions(-)
> > I think we have a bad design issue here, and I don't know how to fix it.
> > 
> > The OLDIs have been a bit difficult to model, as they are not full
> > devices: they are not on a control bus, and don't have registers, yet
> > they need configuration. Part of the config is done via separate IO
> > controls with syscon, part of the config is done via DSS's registers.
> > It's not documented, but I assume the OLDI registers in the DSS IP are
> > wired somewhat directly to the OLDI IP.
> > 
> > So currently we just consider OLDIs to be part of the DSS. We do model
> > them as separate custom DSS child nodes in the DT, so that we can model
> > the pipelines correctly. For example, to support dual-link OLDI, we have
> > two OLDI TX nodes, which get their pixel stream from a single DSS port.
> > The power-domains for the OLDIs were just set as DSS power-domains, as
> > OLDIs were part of DSS in this design.
> > 
> > This felt perhaps slightly hacky, but it also made sense and allowed us
> > to model the HW.
> > 
> > Now, with AM62P, it gets a bit interesting. We have two independent DSS
> > IPs, each of which have two output ports, and we have two OLDI TX
> > instances. The OLDI TX instances are shared between the DSS instances,
> > and the first output port on both DSS can be muxed to an OLDI. The first
> > DSS can be connected to both OLDI TXes, the second DSS can be connected
> > only to the second OLDI.
> > 
> > This DSS application note has a bit more info and some pics:
> > https://www.ti.com/lit/pdf/sprads3
> > 
> > Now, both DSS instances have identical registers for configuring both
> > OLDI instances. This is not documented, but I'm guessing that when
> > configuring the clock muxes (the clock tree is also "interesting"), it
> > will also mux the configuration wires coming from the DSS instances. So
> > when you change the parent clocks for DSS & OLDI to be the right ones to
> > use, say, OLDI TX1 on DSS1, you also change where the OLDI configuration
> > is coming from.
> > 
> > So the OLDIs are now shared, and the configuration registers are
> > duplicated and routed based on clock setup (afaiu). Clearly the OLDIs
> > can not be considered being part of DSS0 or DSS1 anymore, nor can we set
> > the OLDI power-domains in the DSS node.
> > 
> > What this series does is that it adds three OLDI nodes, two for DSS0 (as
> > DSS0 can use either one or two OLDIs) and one for DSS1. And then,
> > depending on which OLDIs you happen to use, you're supposed to set the
> > DSS power-domains accordingly, so that the DSS being used for OLDI has
> > the necessary OLDI power-domains. And connect the media graph so that if
> > your panel uses OLDI TX1 with the DSS0, you connect to that OLDI DT
> > node, but if you use the same OLDI TX1 with the DSS1, you connect to
> > another OLDI DT node. I don't think that's right at all...
> > 
> > I don't right away have a good idea (well, not even a bad idea) how this
> > should be designed.
> I still don't have a binding-idea that I would be satisfied with, but I
> guess there's just no sensible way to represent this hardware. How to
> model an IP that has its control bus changing based on a clock mux...
> 
> I think one thing we can do is move the OLDI power-domains into the OLDI
> nodes. That feels like a more correct place for them. Earlier the OLDI
> PDs were in the DSS node, as the OLDI was considered an internal part of
> the DSS. But now that the OLDIs can move from one DSS to another, this
> "OLDI is part of a DSS" model doesn't work.
> 
> However, even if it looks fine on DT side, I wonder if this will cause
> problems on the Linux side: OLDI is not a device, so I guess we still
> need to associate those PDs somehow with the DSS device.
> 
> For the issue with the control bus, I don't see a solution, so I propose
> doing what the patch here does: The two OLDIs are represented by three
> OLDI nodes in the DT: OLDI TX0 and TX1 under DSS0, OLDI TX1 under DSS1.
> Only one of the TX1s should be enabled at a time, of course.
> 
> So the DT structure would be something like this:
> 
> dss0 {
>   power-domains = <dss0 pd>;
> 
>   ports {
>     ports for DSS videoports
>   };
> 
>   oldi-transmitters {
>     oldi0: oldi@0 {
>       power-domains = <oldi0 pd>;
>         ports {
>           ports for OLDI TX0
>         }
>     };
>     oldi1: oldi@1 {
>       power-domains = <oldi1 pd>;
>         ports {
>           ports for OLDI TX1
>         }
>     };
> };
> 
> dss1 {
>   power-domains = <dss1 pd>;
> 
>   ports {
>     ports for DSS videoports
>   };
> 
>   oldi-transmitters {
>     oldi1: oldi@1 {
>       power-domains = <oldi1 pd>;
>       ports {
>         ports for OLDI TX1
>       }
>     };
> };

I was discussing something similar on #devicetree yesterday:

diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
index 8203ec5e5bb3..7902637587b4 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
@@ -29,6 +29,11 @@ properties:
   clock-names:
     const: serial
 
+  power-domains:
+    description: phandle to the associated OLDI power domain
+    items:
+      - description: OLDI power domain
+
   ti,companion-oldi:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource

Powered by blists - more mailing lists