drm/tidss: Add OLDI bridge support

From: Aradhya Bhatia <[email protected]>

The OLDI transmitters (TXes) do not have registers of their own, and are dependent on the source video-ports (VPs) from the DSS to provide configuration data. This hardware doesn't directly sit on the internal bus of the SoC, but does so via the DSS. Hence, the OLDI TXes are supposed to be child nodes under the DSS, and not independent devices.

Two of the OLDI TXes can function in tandem to output dual-link OLDI output, or cloned single-link outputs. In these cases, one OLDI will be the primary OLDI, and the other one, a companion. The following diagram represents such a configuration.

+-----+-----+         +-------+
|     |     |         |       |
|     | VP1 +----+--->+ OLDI0 |  (Primary - may need companion)
|     |     |    |    |       |
| DSS +-----+    |    +-------+
|     |     |    |
|     | VP2 |    |    +-------+
|     |     |    |    |       |
+-----+-----+    +--->+ OLDI1 |  (Companion OLDI)
                      |       |
                      +-------+

The DSS in AM625 SoC has a configuration like the one above. The AM625 DSS VP1 (port@0) can connect and control 2 OLDI TXes, to use them in dual-link or cloned single-link OLDI modes. It is only the VP1 that can connect to either OLDI TXes for the AM625 DSS, and not the VP2.

Alternatively, on some future TI SoCs, along with the above configuration, the OLDI TX can _also_ connect to separate video sources, making them work entirely independent of each other. In this case, neither of the OLDIs are "companion" or "secondary" OLDIs, and nor do they require one. They both are independent and primary OLDIs. The following diagram represents such a configuration.

+-----+-----+               +-------+
|     |     |               |       |
|     | VP1 +--+----------->+ OLDI0 |  (Primary - may need companion)
|     |     |  |            |       |
|     +-----+  |            +-------+
|     |     |  |
|     | VP2 |  |
|     |     |  |
| DSS +-----+  |   +---+    +-------+
|     |     |  +-->+ M |    |       |
|     | VP3 +----->+ U +--->+ OLDI1 |  (Companion or Primary)
|     |     |      | X |    |       |
|     +-----+      +---+    +-------+
|     |     |
|     | VP4 |
|     |     |
+-----+-----+

Note that depending on the mux configuration, the OLDIs can either be working together in tandem - sourced by VP1, OR, they could be working independently sourced by VP1 and VP3 respectively.
The idea is to support all the configurations with this OLDI TX schema.

The OLDI functionality is further supported by a system-control module, which contains a few registers to control OLDI IO power and other electrical characteristics of the IO lanes.

Add devicetree binding schema for the OLDI TXes to support various configurations, and extend their support to the AM625 DSS.

Signed-off-by Aradhya Bhatia <[email protected]>

Signed-off-by Aradhya Bhatia <[email protected]>

---
 .../bindings/display/ti/ti,am625-oldi.yaml    | 119 ++++++++++++++
 .../bindings/display/ti/ti,am65x-dss.yaml     | 153 ++++++++++++++++++
 MAINTAINERS                                   |   1 +
 3 files changed, 273 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml

Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml new file +82 -0

new file mode 100644
index 000000000000..51b24db04e89
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM625 OLDI Transmitter
+
+maintainers:
+  - Tomi Valkeinen <[email protected]>
+  - Aradhya Bhatia <[email protected]>
+
+description:
+  The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized RGB
+  pixel data transmission between host and flat panel display over LVDS (Low
+  Voltage Differential Sampling) interface. The OLDI TX consists of 7-to-1 data
+  serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS output
+  formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB or
+  padded and un-padded 18-bit RGB bus formats as input.
+
+properties:
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: serial clock input for the OLDI transmitters
+
+  clock-names:
+    const: serial
+
+  ti,companion-oldi:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      phandle to companion OLDI transmitter. This property is mandatory for the
+      primarty OLDI TX if the OLDI TXes are expected to work either in dual-lvds
+      mode or in clone mode. This property should point to the secondary OLDI
+      TX.
+
+  ti,secondary-oldi:
+    type: boolean
+    description:
+      Boolean property to mark the OLDI transmitter as the secondary one, when the
+      OLDI hardware is expected to run as a companion HW, in cases of dual-lvds
+      mode or clone mode. The primary OLDI hardware is responsible for all the
+      hardware configuration.
+
+  ti,oldi-io-ctrl:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      phandle to syscon device node mapping OLDI IO_CTRL registers found in the
+      control MMR region. These registers are required to toggle the I/O lane
+      power, and control its electrical characteristics.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Parallel RGB input port
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: LVDS output port
+
+    required:
+      - port@0
+      - port@1
+
+allOf:
+  - if:
+      required:
+        - ti,secondary-oldi
+    then:
+      properties:
+        ti,companion-oldi: false
+
+required:
+  - reg
+  - clocks
+  - clock-names

Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml new file +27 -0

+        #address-cells = <1>;
+        #size-cells = <0>;
+        oldi: oldi@0 {
+            reg = <0>;
+            clocks = <&k3_clks 186 0>;
+            clock-names = "serial";
+            ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    reg = <0>;
+                    oldi_in: endpoint {
+                        remote-endpoint = <&dpi_out>;
+                    };
+                };
+                port@1 {
+                    reg = <1>;
+                    oldi_out: endpoint {
+                        remote-endpoint = <&panel_in>;
+                    };
+                };
+            };
+        };
+    };
+
+...

Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +18 -0

index 399d68986326..eb6a65f9970d 100644
@@ -91,6 +91,24 @@ properties:
           For AM625 DSS, the internal DPI output port node from video
           port 1.
           For AM62A7 DSS, the port is tied off inside the SoC.
+        properties:
+          endpoint@0:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description:
+              For AM625 DSS, VP Connection to OLDI0.
+              For AM65X DSS, OLDI output from the SoC.
+
+          endpoint@1:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description:
+              For AM625 DSS, VP Connection to OLDI1.
+
+        anyOf:
+          - required:
+              - endpoint
+          - required:
+              - endpoint@0
+              - endpoint@1
 
       port@1:
         $ref: /schemas/graph.yaml#/properties/port

Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +2 -0

+
 allOf:
   - if:
       properties:

@@ -123,6 +161,19 @@ allOf:
         ports:
           properties:
             port@0: false
+            oldi-transmitters: false

Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +104 -0

+          properties:
+            endpoint@1: false
 
 required:
   - compatible

@@ -171,3 +222,105 @@ examples:
             };
         };
     };
+
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        dss1: dss@30200000 {
+            compatible = "ti,am625-dss";
+            reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+                  <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+                  <0x00 0x30206000 0x00 0x1000>, /* vid */
+                  <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+                  <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+                  <0x00 0x3020a000 0x00 0x1000>, /* vp1 */
+                  <0x00 0x3020b000 0x00 0x1000>, /* vp2 */
+                  <0x00 0x30201000 0x00 0x1000>; /* common1 */
+            reg-names = "common", "vidl1", "vid",
+                        "ovr1", "ovr2", "vp1", "vp2", "common1";
+            power-domains = <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>;
+            clocks =        <&k3_clks 186 6>,
+                            <&vp1_clock>,
+                            <&k3_clks 186 2>;
+            clock-names = "fck", "vp1", "vp2";
+            interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+            oldi-transmitters {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                oldi0: oldi@0 {
+                    reg = <0>;
+                    clocks = <&k3_clks 186 0>;
+                    clock-names = "serial";
+                    ti,companion-oldi = <&oldi1>;
+                    ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+                    ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        port@0 {
+                            reg = <0>;
+                            oldi0_in: endpoint {
+                                remote-endpoint = <&dpi0_out0>;
+                            };
+                        };
+                        port@1 {
+                            reg = <1>;
+                            oldi0_out: endpoint {
+                                remote-endpoint = <&panel_in0>;
+                            };
+                        };
+                    };
+                };
+                oldi1: oldi@1 {
+                    reg = <1>;
+                    clocks = <&k3_clks 186 0>;
+                    clock-names = "serial";
+                    ti,secondary-oldi;
+                    ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+                    ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        port@0 {
+                            reg = <0>;
+                            oldi1_in: endpoint {
+                                remote-endpoint = <&dpi0_out1>;
+                            };
+                        };
+                        port@1 {
+                            reg = <1>;
+                            oldi1_out: endpoint {
+                                remote-endpoint = <&panel_in1>;
+                            };
+                        };
+                    };
+                };
+            };
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    #address-cells = <1>;
+                    #size-cells = <0>;
+                    reg = <0>;
+                    dpi0_out0: endpoint@0 {
+                        reg = <0>;
+                        remote-endpoint = <&oldi0_in>;
+                    };
+                    dpi0_out1: endpoint@1 {
+                        reg = <1>;
+                        remote-endpoint = <&oldi1_in>;
+                    };
+                };
+                port@1 {
+                    reg = <1>;
+                    dpi1_out: endpoint {
+                        remote-endpoint = <&hdmi_bridge>;
+                    };
+                };
+            };
+        };
+    };

MAINTAINERS +1 -0

index 93415153247b..d47a56c4d276 100644
@@ -7817,6 +7817,7 @@ M:	Tomi Valkeinen <[email protected]>
 L:	[email protected]
 S:	Maintained
 T:	git https://gitlab.freedesktop.org/drm/misc/kernel.git
+F:	Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
 F:	Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
 F:	Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
 F:	Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml

Signature · 1 line

2.34.1

From: Aradhya Bhatia <[email protected]>

The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it possible to connect them in dual-link or cloned single-link OLDI display modes. The current OLDI support in tidss_dispc.c can only support for a single OLDI TX, connected to a VP and doesn't really support configuration of OLDIs in the other modes. The current OLDI support in tidss_dispc.c also works on the principle that the OLDI output can only be served by one, and only one, DSS video-port. This isn't the case in the AM62Px SoC, where there are 2 DSS controllers present that share the OLDI TXes.

Having their own devicetree and their own bridge entity will help support the various display modes and sharing possiblilities of the OLDI hardware.

For all these reasons, add support for the OLDI TXes as DRM bridges.

drivers/gpu/drm/tidss/tidss_oldi.c new file +8 -0

+int tidss_oldi_init(struct tidss_device *tidss)
+{
+	struct tidss_oldi *oldi;
+	struct device_node *child;
+	struct drm_bridge *bridge;
+	u32 parent_vp, oldi_instance, companion_instance;
+	enum tidss_oldi_link_type link_type = OLDI_MODE_UNSUPPORTED;
+	struct device_node *oldi_parent;

drivers/gpu/drm/tidss/tidss_oldi.c new file +15 -0

+		ret = get_parent_dss_vp(child, &parent_vp);
+		if (ret) {
+			if (ret == -ENODEV) {
+				/*
+				 * ENODEV means that this particular OLDI node
+				 * is not connected with the DSS, which is not
+				 * a harmful case. There could be another OLDI
+				 * which may still be connected.
+				 * Continue to search for that.
+				 */
+				ret = 0;
+				continue;
+			}
+			goto err_put_node;
+		}

Hi Aradhya!

Quoted 17 lines · Aradhya Bhatia

From: Aradhya Bhatia <[email protected]>

The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it possible to connect them in dual-link or cloned single-link OLDI display modes. The current OLDI support in tidss_dispc.c can only support for a single OLDI TX, connected to a VP and doesn't really support configuration of OLDIs in the other modes. The current OLDI support in tidss_dispc.c also works on the principle that the OLDI output can only be served by one, and only one, DSS video-port. This isn't the case in the AM62Px SoC, where there are 2 DSS controllers present that share the OLDI TXes.

Having their own devicetree and their own bridge entity will help support the various display modes and sharing possiblilities of the OLDI hardware.

For all these reasons, add support for the OLDI TXes as DRM bridges.

...

Quoted 14 lines

drivers/gpu/drm/tidss/tidss_oldi.c new file +14 -0

+int tidss_oldi_init(struct tidss_device *tidss)
+{
+	struct tidss_oldi *oldi;
+	struct device_node *child;
+	struct drm_bridge *bridge;
+	u32 parent_vp, oldi_instance, companion_instance;
+	enum tidss_oldi_link_type link_type = OLDI_MODE_UNSUPPORTED;
+	struct device_node *oldi_parent;
+	int ret = 0;
+
+	tidss->num_oldis = 0;
+
+	oldi_parent = of_get_child_by_name(tidss->dev->of_node, "oldi-transmitters");
+	if (!oldi_parent)

drivers/gpu/drm/tidss/tidss_oldi.c line 427

Quoted 4 lines

drivers/gpu/drm/tidss/tidss_oldi.c new file +4 -0

+		/* Return gracefully */
+		return 0;
+
+	for_each_child_of_node(oldi_parent, child) {

Would for_each_available_child_of_node() make sense here so that k3-am62-main.dtsi would have both ports with status = "disabled" and the users will enable one or another?

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. <[email protected]>. 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. <[email protected]>.

---

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/[email protected]/
V2: https://lore.kernel.org/all/[email protected]/
V1: https://lore.kernel.org/all/[email protected]/

[0]: Dependency Patch:
("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/[email protected]/

[1]: AM62 OLDI Series - v7
https://lore.kernel.org/all/[email protected]/

[2]: AM62 DSS Series - v9
https://lore.kernel.org/all/[email protected]/

[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/[email protected]/

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,

Quoted 83 lines · Aradhya Bhatia

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.

Quoted 6 lines

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?

Quoted 63 lines

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)

Quoted 8 lines

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.

Hi,

Quoted 93 lines · Tomi Valkeinen

Hi,

Quoted 83 lines · Aradhya Bhatia

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.

Quoted 6 lines

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

Quoted 2 lines

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.

Hi,

Quoted 113 lines · Aradhya Bhatia

Hi,

Quoted 94 lines · Tomi Valkeinen

Hi,

Quoted 84 lines · Aradhya Bhatia

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.

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 7 lines

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"?

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

Thank you for the patches, Aradhya!

Quoted 2 lines · Aradhya Bhatia

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?

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! =)

[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/[email protected]/

b. ("drm/atomic-helper: Separate out bridge pre_enable/post_disable from enable/disable")
https://lore.kernel.org/all/[email protected]/

c. ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
https://lore.kernel.org/all/[email protected]/

[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/[email protected]/

[2]: Latest OLDI series (v6)
https://lore.kernel.org/all/[email protected]/

Quoted 5 lines

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! =)

Hi Aradhya!

Quoted 5 lines · Aradhya Bhatia

Quoted 5 lines

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

...

Quoted 6 lines

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.

Quoted 4 lines

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.