Add support for AM62L DSS

The DSS controller on TI's AM62L SoC is an update from that on TI's AM625/AM65x/AM62A7 SoC. The AM62L DSS [1] only supports a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---
 .../bindings/display/ti/ti,am65x-dss.yaml     | 25 ++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

The DSS controller on TI's AM62L SoC is an update from that on TI's AM625/AM65x/AM62A7 SoC. The AM62L DSS [1] only supports a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---
  .../bindings/display/ti/ti,am65x-dss.yaml     | 25 ++++++++++++++++++-
  1 file changed, 24 insertions(+), 1 deletion(-)

Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +8 -1

index 55e3e490d0e6..ba93c6bb02e8 100644
@@ -12,18 +12,29 @@ maintainers:
    - Tomi Valkeinen <[email protected]>
 
  description: |
-  The AM625 and AM65x TI Keystone Display SubSystem with two output
+  The AM625 and AM65x TI Keystone Display SubSystem has two output
    ports and two video planes. In AM65x DSS, the first video port
    supports 1 OLDI TX and in AM625 DSS, the first video port output is
    internally routed to 2 OLDI TXes. The second video port supports DPI
    format. The first plane is full video plane with all features and the
    second is a "lite plane" without scaling support.
+  The AM62A7 display subsystem has a single output port supporting DPI format
+  although similar to AM625 and AM65x Socs, it has two video planes where first
+  is full video plane with all features and second is a video "lite" plane which
+  does not support scaling.
+  The AM62L display subsystem also has a single output port which supports DPI
+  format but it only supports single video "lite plane" which does not support
+  scaling. The output port is routed to SoC boundary via DPI interface and same

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

        - ti,am65x-dss
 
    reg:

@@ -91,6 +102,8 @@ 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.
+          For AM62L DSS, the DSS DPI output port node from video port 1
+          or DSI Tx controller node connected to video port 1.
 
        port@1:
          $ref: /schemas/graph.yaml#/properties/port

@@ -123,6 +136,16 @@ allOf:
          ports:
            properties:
              port@0: false
+  - if:
+      properties:
+        compatible:

Quoted 5 lines

    compatible:
      enum:
        - ti,am625-dss
        - ti,am62a7,dss
+      - ti,am62l,dss

s/ti,am62l,dss/ti,am62l-dss

There seems to be inconsistency in the usage of the compatible name in the conditional below.

Same is with the compatible "ti,am62a7,dss".
Can you fix that too?

With the above comments addressed,

Reviewed-by Jayesh Choudhary <[email protected]>

Enable display for AM62L DSS [1] which supports only a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---
  drivers/gpu/drm/tidss/tidss_dispc.c | 34 +++++++++++++++++++++++++++++
  drivers/gpu/drm/tidss/tidss_dispc.h |  2 ++
  drivers/gpu/drm/tidss/tidss_drv.c   |  1 +
  3 files changed, 37 insertions(+)

drivers/gpu/drm/tidss/tidss_dispc.c +29 -0

index cacb5f3d8085..cd322d60b825 100644
@@ -376,6 +376,35 @@ const struct dispc_features dispc_am62a7_feats = {
  	.vid_order = { 1, 0 },
  };
 
+const struct dispc_features dispc_am62l_feats = {
+	.max_pclk_khz = {
+		[DISPC_VP_DPI] = 165000,
+	},
+
+	.subrev = DISPC_AM62L,
+
+	.common = "common",
+	.common_regs = tidss_am65x_common_regs,
+
+	.num_vps = 1,
+	.vp_name = { "vp1" },
+	.ovr_name = { "ovr1" },
+	.vpclk_name =  { "vp1" },
+	.vp_bus_type = { DISPC_VP_DPI },
+
+	.vp_feat = { .color = {
+			.has_ctm = true,
+			.gamma_size = 256,
+			.gamma_type = TIDSS_GAMMA_8BIT,
+		},
+	},
+
+	.num_planes = 1,
+	.vid_name = { "vidl1" },
+	.vid_lite = { true },
+	.vid_order = { 0 },
+};
+
  static const u16 *dispc_common_regmap;
 
  struct dss_vp_data {

drivers/gpu/drm/tidss/tidss_dispc.c +4 -0

  		return dispc_k3_read_and_clear_irqstatus(dispc);

@@ -896,6 +926,7 @@ void dispc_set_irqenable(struct dispc_device *dispc, dispc_irq_t mask)
  		break;
  	case DISPC_AM625:
  	case DISPC_AM62A7:
+	case DISPC_AM62L:
  	case DISPC_AM65X:
  	case DISPC_J721E:
  		dispc_k3_set_irqenable(dispc, mask);

@@ -1388,6 +1419,7 @@ void dispc_ovr_set_plane(struct dispc_device *dispc, u32 hw_plane,
  		break;
  	case DISPC_AM625:
  	case DISPC_AM62A7:
+	case DISPC_AM62L:
  	case DISPC_AM65X:
  		dispc_am65x_ovr_set_plane(dispc, hw_plane, hw_videoport,
  					  x, y, layer);

@@ -2308,6 +2340,7 @@ static void dispc_plane_init(struct dispc_device *dispc)
  		break;
  	case DISPC_AM625:
  	case DISPC_AM62A7:
+	case DISPC_AM62L:
  	case DISPC_AM65X:
  	case DISPC_J721E:
  		dispc_k3_plane_init(dispc);

@@ -2416,6 +2449,7 @@ static void dispc_vp_write_gamma_table(struct dispc_device *dispc,
  		break;
  	case DISPC_AM625:
  	case DISPC_AM62A7:
+	case DISPC_AM62L:
  	case DISPC_AM65X:
  		dispc_am65x_vp_write_gamma_table(dispc, hw_videoport);
  		break;

drivers/gpu/drm/tidss/tidss_dispc.h +2 -0

index 086327d51a90..275de8d02b75 100644
@@ -62,6 +62,7 @@ enum dispc_dss_subrevision {
  	DISPC_K2G,
  	DISPC_AM625,
  	DISPC_AM62A7,
+	DISPC_AM62L,
  	DISPC_AM65X,
  	DISPC_J721E,
  };

@@ -91,6 +92,7 @@ struct dispc_features {
  extern const struct dispc_features dispc_k2g_feats;
  extern const struct dispc_features dispc_am625_feats;
  extern const struct dispc_features dispc_am62a7_feats;
+extern const struct dispc_features dispc_am62l_feats;
  extern const struct dispc_features dispc_am65x_feats;
  extern const struct dispc_features dispc_j721e_feats;
 

drivers/gpu/drm/tidss/tidss_drv.c +1 -0

index d4652e8cc28c..f2a4f659f574 100644
@@ -242,6 +242,7 @@ static const struct of_device_id tidss_of_table[] = {
  	{ .compatible = "ti,k2g-dss", .data = &dispc_k2g_feats, },
  	{ .compatible = "ti,am625-dss", .data = &dispc_am625_feats, },
  	{ .compatible = "ti,am62a7-dss", .data = &dispc_am62a7_feats, },
+	{ .compatible = "ti,am62l-dss", .data = &dispc_am62l_feats, },
  	{ .compatible = "ti,am65x-dss", .data = &dispc_am65x_feats, },
  	{ .compatible = "ti,j721e-dss", .data = &dispc_j721e_feats, },
  	{ }

Enable display for AM62L DSS [1] which supports only a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---
 drivers/gpu/drm/tidss/tidss_dispc.c | 34 +++++++++++++++++++++++++++++
 drivers/gpu/drm/tidss/tidss_dispc.h |  2 ++
 drivers/gpu/drm/tidss/tidss_drv.c   |  1 +
 3 files changed, 37 insertions(+)

drivers/gpu/drm/tidss/tidss_dispc.c +0 -0

index cacb5f3d8085..cd322d60b825 100644

drivers/gpu/drm/tidss/tidss_dispc.c +8 -0

+
+	.num_vps = 1,
+	.vp_name = { "vp1" },
+	.ovr_name = { "ovr1" },
+	.vpclk_name =  { "vp1" },
+	.vp_bus_type = { DISPC_VP_DPI },
+
+	.vp_feat = { .color = {

Hi Devarsh,

Thanks for the patches.

Quoted 13 lines

Enable display for AM62L DSS [1] which supports only a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---

Quoted 4 lines

+const struct dispc_features dispc_am62l_feats = { +    .max_pclk_khz = {
+            [DISPC_VP_DPI] = 165000,

The TRM mentions that the max the VP PLL can go is 150MHz, so maybe you might need to update this.

That said, as far as I understand, the IP itself can support 165 MHz, and I am wondering, what would we do if there comes out a new SoC that uses AM62L DSS as is, but just bumps up the PLL capacity to 165MHz.

It would be odd to have a ditto feats structure with just the frequency updated.

drivers/gpu/drm/tidss/tidss_dispc.c const struct dispc_features dispc_am62a7_feats = { · line 387

Quoted 7 lines

+    },

drivers/gpu/drm/tidss/tidss_dispc.c +5 -0

+
+    .subrev = DISPC_AM62L,
+
+    .common = "common",
+    .common_regs = tidss_am65x_common_regs,

Also, I don't think we should utilize this as is.

The AM62L common regions is different, and is, at best, a subset of the AM65x/AM62x common register space.

For example, registers VID_IRQ{STATUS, ENABLE}_0 have been dropped, along with VP_IRQ{STATUS, ENABLE}_1.

- Which brings to my next concern...

Quoted 8 lines

drivers/gpu/drm/tidss/tidss_dispc.c +8 -0

+
+    .num_vps = 1,
+    .vp_name = { "vp1" },
+    .ovr_name = { "ovr1" },
+    .vpclk_name =  { "vp1" },
+    .vp_bus_type = { DISPC_VP_DPI },
+
+    .vp_feat = { .color = {

drivers/gpu/drm/tidss/tidss_dispc.c const struct dispc_features dispc_am62a7_feats = { · line 405

Quoted 10 lines

drivers/gpu/drm/tidss/tidss_dispc.c +10 -0

+                    .has_ctm = true,
+                    .gamma_size = 256,
+                    .gamma_type = TIDSS_GAMMA_8BIT,
+            },
+    },
+
+    .num_planes = 1,
+    .vid_name = { "vidl1" },
+    .vid_lite = { true },
+    .vid_order = { 0 },

...

Usually, VID1 is the first video pipeline, while VIDL1 remains the second. Which is why vid1 occupies the index 0, and vidl1 occupies 1 - even from the hardware perspective.

While AM62L has only one video (lite) pipeline - vidl1, and there is no vid1, the hardware still treats vidl1 at index 1.

For example, the TRM has defined DISPC_VID_IRQ{STATUS, ENABLE}_1 (and not _0) in the common region.

So, the vid_order here should be 1, not 0.

Hi Aradhya,

Quoted 4 lines · Aradhya Bhatia

Hi Devarsh,

Thanks for the patches.

Thanks for the review.

Quoted 14 lines · Devarsh Thakkar

Quoted 13 lines

Enable display for AM62L DSS [1] which supports only a single display pipeline using a single overlay manager, single video port and a single video lite pipeline which does not support scaling.

The output of video port is routed to SoC boundary via DPI interface and the DPI signals from the video port are also routed to DSI Tx controller present within the SoC.

[1]: Section 11.7 (Display Subsystem and Peripherals)

Link https://www.ti.com/lit/pdf/sprujb4

Signed-off-by Devarsh Thakkar <[email protected]>

---

<snip>

Quoted 8 lines

Quoted 4 lines

+const struct dispc_features dispc_am62l_feats = { +    .max_pclk_khz = {
+            [DISPC_VP_DPI] = 165000,

The TRM mentions that the max the VP PLL can go is 150MHz, so maybe you might need to update this.

Quoted 6 lines

That said, as far as I understand, the IP itself can support 165 MHz, and I am wondering, what would we do if there comes out a new SoC that uses AM62L DSS as is, but just bumps up the PLL capacity to 165MHz.

It would be odd to have a ditto feats structure with just the frequency updated.

TRM mentions max VP PLL frequency as 165 Mhz and not 150 Mhz. Please refer Table 11-343. DSS Signals for MIPI DPI 2.0 or BT.656/BT.1120 section in section 11.7.1.2.1 DSS Parallel Interface of  AM62L TRM [1].

Quoted 10 lines

drivers/gpu/drm/tidss/tidss_dispc.c const struct dispc_features dispc_am62a7_feats = { · line 387

Quoted 7 lines

+    },

drivers/gpu/drm/tidss/tidss_dispc.c +5 -0

+
+    .subrev = DISPC_AM62L,
+
+    .common = "common",
+    .common_regs = tidss_am65x_common_regs,

Also, I don't think we should utilize this as is.

Quoted 8 lines

The AM62L common regions is different, and is, at best, a subset of the AM65x/AM62x common register space.

For example, registers VID_IRQ{STATUS, ENABLE}_0 have been dropped, along with VP_IRQ{STATUS, ENABLE}_1.

- Which brings to my next concern...

Thanks for pointing out, I probably missed this since the use-case still worked since VP interrupts were still enabled and those were sufficient to drive the display
but the VID underflow interrupts and VID specific bits were probably not enabled at-all due to above miss, so agreed
we should probably go ahead with a different reg space for AM62L due to aforementioned differences.

Quoted 7 lines

Thanks for pointing out, I probably missed this since the use-case still worked since VP interrupts were still enabled and those were sufficient to drive the display
but the VID underflow interrupts and VID specific bits were probably not enabled at-all due to above miss, so agreed
we should probably go ahead with a different reg space for AM62L due to aforementioned differences.

I think I disagree here. Afaiu, AM62L has plane at hw index 1 (VIDL1), but the plane at hw index 0 (VID1) is not instantiated in the hardware. But the registers are the same, i.e. AM62L's registers for VIDL1 match AM65x/AM62x registers, right?

If so, we just need to tell the driver the hw index, instead of creating new register offsets as done in v2.

Or am I missing something here? (I haven't looked at the HW manual yet).

Hi Tomi

Quoted 13 lines

Quoted 7 lines

Thanks for pointing out, I probably missed this since the use-case still worked since VP interrupts were still enabled and those were sufficient to drive the display
but the VID underflow interrupts and VID specific bits were probably not enabled at-all due to above miss, so agreed
we should probably go ahead with a different reg space for AM62L due to aforementioned differences.

I think I disagree here. Afaiu, AM62L has plane at hw index 1 (VIDL1), but the plane at hw index 0 (VID1) is not instantiated in the hardware. But the registers are the same, i.e. AM62L's registers for VIDL1 match AM65x/AM62x registers, right?

Quoted 5 lines

If so, we just need to tell the driver the hw index, instead of creating new register offsets as done in v2.

Or am I missing something here? (I haven't looked at the HW manual yet).

No that's not the only difference. For AM62L, the VID_IRQENABLE/STATUS registers start at +0x4 as compared to AM65x/AM62x/ :

AM62L:

         [DISPC_VID_IRQENABLE_OFF] =             0x48,

         [DISPC_VID_IRQSTATUS_OFF] =             0x5c,

AM62x/AM65x:

         [DISPC_VID_IRQENABLE_OFF] =             0x44,

         [DISPC_VID_IRQSTATUS_OFF] =             0x58,

This adds support for DSS subsystem present in TI's AM62L SoC which supports single display pipeline with DPI output which is also routed to DSI Tx controller within the SoC.

Devarsh Thakkar (2):
dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS drm/tidss: Add support for AM62L display subsystem

  .../bindings/display/ti/ti,am65x-dss.yaml     | 25 +++++++++++++-
  drivers/gpu/drm/tidss/tidss_dispc.c           | 34 +++++++++++++++++++
  drivers/gpu/drm/tidss/tidss_dispc.h           |  2 ++
  drivers/gpu/drm/tidss/tidss_drv.c             |  1 +
  4 files changed, 61 insertions(+), 1 deletion(-)