Skip to contentSkip to conversation

rockchip: Add Powkiddy RK2023

PATCH Applied Chris Morgan 6 participants 21 messages Oct 18, 2023 – Oct 27, 2023

Subsystems (6)
Device tree bindings DRM drivers DRM misc Common clk +2 more subsystems

v1 of 4 Applied Latest is v4 →

lore
Share & tools
lore

Chris Morgan

author
#0 lore raw

cover rockchip: Add Powkiddy RK2023

From: Chris Morgan <[email protected]>

Add support for the Powkiddy RK2023, which is extremely similar to existing devices from Anbernic.

Chris Morgan (5):
dt-bindings: display: panel: Update NewVision NV3051D compatibles drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support
clk: rockchip: rk3568: Add PLL rate for 115.2MHz
dt-bindings: arm: rockchip: Add Powkiddy RK2023
arm64: dts: rockchip: add Powkiddy RK2023

 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 .../display/panel/newvision,nv3051d.yaml      |   2 +-
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3566-powkiddy-rk2023.dts   | 161 ++++++++++++++++++
 drivers/clk/rockchip/clk-rk3568.c             |   1 +
 .../gpu/drm/panel/panel-newvision-nv3051d.c   |  56 ++++--
 6 files changed, 214 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
Signature · 1 line
2.34.1
author
#1 lore raw

PATCH 1/5 dt-bindings: display: panel: Update NewVision NV3051D compatibles

From: Chris Morgan <[email protected]>

Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rg353v-panel is exactly identical to the rg353p-panel and is not currently in use by any existing device tree. The rk2023-panel is similar to the rg353p-panel but has slightly different timings.

Signed-off-by Chris Morgan <[email protected]>
---
 .../devicetree/bindings/display/panel/newvision,nv3051d.yaml    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml +1 -1
index cce775a87f87..7a634fbc465e 100644
@@ -21,7 +21,7 @@ properties:
       - enum:
           - anbernic,rg351v-panel
           - anbernic,rg353p-panel
-          - anbernic,rg353v-panel
+          - powkiddy,rk2023-panel
       - const: newvision,nv3051d
 
   reg: true
Signature · 1 line
2.34.1
#2 lore raw

Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles

Quoted 8 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rg353v-panel is exactly identical to the rg353p-panel and is not currently in use by any existing device tree. The rk2023-panel is similar to the rg353p-panel but has slightly different timings.

This still does not explain me why do you want to remove old panel.

Best regards,
Krzysztof

#3 lore raw

Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles

Quoted 11 lines · Krzysztof Kozlowski
Quoted 8 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rg353v-panel is exactly identical to the rg353p-panel and is not currently in use by any existing device tree. The rk2023-panel is similar to the rg353p-panel but has slightly different timings.

This still does not explain me why do you want to remove old panel.

When I originally wrote the driver I only had one piece of hardware and I set the compatible string in the driver as newvision,nv3051d. Unfortunately since then I've found 2 more devices in use that are *just* different enough to require the driver to do things a bit differently. In the case of the anbernic,rg351v-panel I need to enable a new DSI flag; in the case of the powkiddy,rk2023-panel I need to decrease the vertical back porch and drop the higher frequency timings.

The best way to accomplish this was to change the strategy from having a single binding in the driver of newvision,nv3051d to a binding for each distinct hardware where the differences apply. Note that I've looked at querying the DSI panel ID, but for each device the value is identical (so it can't be used to differentiate the hardware sadly). So the driver now has 3 different compatible strings. I could in this case add a 4th compatible string of anbernic,rg353v-panel but it would be identical to anbernic,rg353p-panel. For the moment we are using anbernic,rg353p-panel everywhere (including the rg353v), so it makes sense to drop this unused value while we can, at least to me.

Let me know if you have any more questions, thank you. Chris

Quoted 6 lines

Best regards,
Krzysztof

maintainer
#4 lore raw

Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles

Quoted 22 lines · Chris Morgan
Quoted 11 lines · Krzysztof Kozlowski
Quoted 8 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rg353v-panel is exactly identical to the rg353p-panel and is not currently in use by any existing device tree. The rk2023-panel is similar to the rg353p-panel but has slightly different timings.

This still does not explain me why do you want to remove old panel.

When I originally wrote the driver I only had one piece of hardware and I set the compatible string in the driver as newvision,nv3051d. Unfortunately since then I've found 2 more devices in use that are *just* different enough to require the driver to do things a bit differently. In the case of the anbernic,rg351v-panel I need to enable a new DSI flag; in the case of the powkiddy,rk2023-panel I need to decrease the vertical back porch and drop the higher frequency timings.

Quoted 3 lines

The best way to accomplish this was to change the strategy from having a single binding in the driver of newvision,nv3051d to a binding for each distinct hardware where the differences apply.

Exactly why the DT maintainers annoyingly ask for specific compatible strings which may not be used immediately.

Quoted 8 lines

Note that I've
looked at querying the DSI panel ID, but for each device the value is identical (so it can't be used to differentiate the hardware sadly). So the driver now has 3 different compatible strings. I could in this case add a 4th compatible string of anbernic,rg353v-panel but it would be identical to anbernic,rg353p-panel. For the moment we are using anbernic,rg353p-panel everywhere (including the rg353v), so it makes sense to drop this unused value while we can, at least to me.

Your reasoning is the compatible string is unused, so remove it.

If there's some reasoning about how the 2 panels are the same hardware or the rg353v is never going to be used or show up at some point, then that would be a reason to remove.

You could also say the rg353v is just wrong because it should have a fallback compatible to rg353p and rather than fix it, just remove it for now since there are no known users of it.

Rob

#5 lore raw

Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles

Quoted 23 lines · Rob Herring
Quoted 22 lines · Chris Morgan
Quoted 11 lines · Krzysztof Kozlowski
Quoted 8 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rg353v-panel is exactly identical to the rg353p-panel and is not currently in use by any existing device tree. The rk2023-panel is similar to the rg353p-panel but has slightly different timings.

This still does not explain me why do you want to remove old panel.

When I originally wrote the driver I only had one piece of hardware and I set the compatible string in the driver as newvision,nv3051d. Unfortunately since then I've found 2 more devices in use that are *just* different enough to require the driver to do things a bit differently. In the case of the anbernic,rg351v-panel I need to enable a new DSI flag; in the case of the powkiddy,rk2023-panel I need to decrease the vertical back porch and drop the higher frequency timings.

Quoted 6 lines
Quoted 3 lines

The best way to accomplish this was to change the strategy from having a single binding in the driver of newvision,nv3051d to a binding for each distinct hardware where the differences apply.

Exactly why the DT maintainers annoyingly ask for specific compatible strings which may not be used immediately.

You're not wrong. Sorry for making this difficult. I should have done it this way from the start.

Quoted 10 lines
Quoted 9 lines

Note that I've
looked at querying the DSI panel ID, but for each device the value is identical (so it can't be used to differentiate the hardware sadly). So the driver now has 3 different compatible strings. I could in this case add a 4th compatible string of anbernic,rg353v-panel but it would be identical to anbernic,rg353p-panel. For the moment we are using anbernic,rg353p-panel everywhere (including the rg353v), so it makes sense to drop this unused value while we can, at least to me.

Quoted 5 lines

Your reasoning is the compatible string is unused, so remove it.

If there's some reasoning about how the 2 panels are the same hardware or the rg353v is never going to be used or show up at some point, then that would be a reason to remove.

The compatible string of 353v-panel is unused, and the hardware is identical to the 353p-panel (so only one string is necessary). Sorry if that wasn't clear.

Panel 1 - The original anbernic,rg353p-panel which is also anbernic,rg353v-panel.

Panel 2 - anbernic,rg351v-panel. This is almost identical to Panel 1 except it requires an additional flag.

Panel 3 - powkiddy,rk2023-panel. This is almost identical to Panel 1 except it requires a change to the VBP timing parameter and isn't tolerant of speeds much higher than 60hz.

The issue I had is I originally wrote the driver checking for the newvision,nv3051d compatible string which worked fine when there was only 1 panel type. When I added support for the 351v-panel I *should* have changed how the compatible string was handled, but instead I simply added a check in the probe function to look for the secondary string of "anbernic,rg351v-panel". When the 3rd panel type of "powkiddy,rk2023-panel" was needed I took this time to correct the driver and do it the right way by checking for the specific compatibles.

Thank you, and sorry for the headaches this caused you. Chris

Quoted 6 lines

You could also say the rg353v is just wrong because it should have a fallback compatible to rg353p and rather than fix it, just remove it for now since there are no known users of it.

Rob

author
#6 lore raw

PATCH 2/5 drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support

In reply to Chris Morgan

From: Chris Morgan <[email protected]>

Refactor the driver to add support for the powkiddy,rk2023-panel panel. This panel is extremely similar to the rg353p-panel but requires a smaller vertical back porch and isn't as tolerant of higher speeds.

Tested on my RG351V, RG353P, RG353V, and RK2023.

Signed-off-by Chris Morgan <[email protected]>
---
 .../gpu/drm/panel/panel-newvision-nv3051d.c   | 56 +++++++++++++++----
 1 file changed, 45 insertions(+), 11 deletions(-)
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +45 -11
index 79de6c886292..d24c51503d68 100644
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
 	unsigned int num_modes;
 	u16 width_mm, height_mm;
 	u32 bus_flags;
+	u32 mode_flags;
 };
 
 struct panel_nv3051d {

@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
 
 	dsi->lanes = 4;
 	dsi->format = MIPI_DSI_FMT_RGB888;
-	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
-			  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
-	/*
-	 * The panel in the RG351V is identical to the 353P, except it
-	 * requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-	 */
-	if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
-		dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+	dsi->mode_flags = ctx->panel_info->mode_flags;
 
 	drm_panel_init(&ctx->panel, &dsi->dev, &panel_nv3051d_funcs,
 		       DRM_MODE_CONNECTOR_DSI);

@@ -481,18 +474,59 @@ static const struct drm_display_mode nv3051d_rgxx3_modes[] = {
 	},
 };
 
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+	{
+		.hdisplay       = 640,
+		.hsync_start    = 640 + 40,
+		.hsync_end      = 640 + 40 + 2,
+		.htotal         = 640 + 40 + 2 + 80,
+		.vdisplay       = 480,
+		.vsync_start    = 480 + 18,
+		.vsync_end      = 480 + 18 + 2,
+		.vtotal         = 480 + 18 + 2 + 4,
+		.clock          = 24150,
+		.flags          = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+	},
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
 	.display_modes = nv3051d_rgxx3_modes,
 	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
 	.width_mm = 70,
 	.height_mm = 57,
 	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+		      MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+	.display_modes = nv3051d_rgxx3_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+	.width_mm = 70,
+	.height_mm = 57,
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+	.display_modes = nv3051d_rk2023_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+	.width_mm = 70,
+	.height_mm = 57,
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
 };
 
 static const struct of_device_id newvision_nv3051d_of_match[] = {
-	{ .compatible = "newvision,nv3051d", .data = &nv3051d_rgxx3_info },
+	{ .compatible = "anbernic,rg351v-panel", .data = &nv3051d_rg351v_info },
+	{ .compatible = "anbernic,rg353p-panel", .data = &nv3051d_rg353p_info },
+	{ .compatible = "powkiddy,rk2023-panel", .data = &nv3051d_rk2023_info },
 	{ /* sentinel */ }
 };
+
 MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
 
 static struct mipi_dsi_driver newvision_nv3051d_driver = {
Signature · 1 line
2.34.1
#7 lore raw

Re: [PATCH 2/5] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support

Quoted 10 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Refactor the driver to add support for the powkiddy,rk2023-panel panel. This panel is extremely similar to the rg353p-panel but requires a smaller vertical back porch and isn't as tolerant of higher speeds.

Tested on my RG351V, RG353P, RG353V, and RK2023.

Signed-off-by Chris Morgan <[email protected]>

Hi Chris,

Thanks for the patch. Just have a minor question below.

Quoted 59 lines
---
  .../gpu/drm/panel/panel-newvision-nv3051d.c   | 56 +++++++++++++++----
  1 file changed, 45 insertions(+), 11 deletions(-)
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +18 -10
index 79de6c886292..d24c51503d68 100644
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
  	unsigned int num_modes;
  	u16 width_mm, height_mm;
  	u32 bus_flags;
+	u32 mode_flags;
  };
 
  struct panel_nv3051d {

@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
 
  	dsi->lanes = 4;
  	dsi->format = MIPI_DSI_FMT_RGB888;
-	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
-			  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
-	/*
-	 * The panel in the RG351V is identical to the 353P, except it
-	 * requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-	 */
-	if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
-		dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+	dsi->mode_flags = ctx->panel_info->mode_flags;
 
  	drm_panel_init(&ctx->panel, &dsi->dev, &panel_nv3051d_funcs,
  		       DRM_MODE_CONNECTOR_DSI);

@@ -481,18 +474,59 @@ static const struct drm_display_mode nv3051d_rgxx3_modes[] = {
  	},
  };
 
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+	{
+		.hdisplay       = 640,
+		.hsync_start    = 640 + 40,
+		.hsync_end      = 640 + 40 + 2,
+		.htotal         = 640 + 40 + 2 + 80,
+		.vdisplay       = 480,
+		.vsync_start    = 480 + 18,
+		.vsync_end      = 480 + 18 + 2,
+		.vtotal         = 480 + 18 + 2 + 4,
+		.clock          = 24150,
+		.flags          = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+	},
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
  	.display_modes = nv3051d_rgxx3_modes,
  	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
  	.width_mm = 70,
  	.height_mm = 57,
  	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 507

Quoted 10 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +10 -0
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+		      MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+	.display_modes = nv3051d_rgxx3_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+	.width_mm = 70,
+	.height_mm = 57,

Will all the panels for this driver be 70x57? If so, would it be better to set display_info.[width_mm|height_mm] directly?

Quoted 13 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +13 -0
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+	.display_modes = nv3051d_rk2023_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+	.width_mm = 70,
+	.height_mm = 57,
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 529

Quoted 10 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +4 -1
  };
 
  static const struct of_device_id newvision_nv3051d_of_match[] = {
-	{ .compatible = "newvision,nv3051d", .data = &nv3051d_rgxx3_info },
+	{ .compatible = "anbernic,rg351v-panel", .data = &nv3051d_rg351v_info },
+	{ .compatible = "anbernic,rg353p-panel", .data = &nv3051d_rg353p_info },
+	{ .compatible = "powkiddy,rk2023-panel", .data = &nv3051d_rk2023_info },
  	{ /* sentinel */ }
  };
+

I think you can drop this stray newline.

Thanks,

Jessica Zhang

Quoted 6 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +0 -0
  MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
 
  static struct mipi_dsi_driver newvision_nv3051d_driver = {
Signature · 1 line
2.34.1
#8 lore raw

Re: [PATCH 2/5] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support

Quoted 78 lines · Jessica Zhang
Quoted 10 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Refactor the driver to add support for the powkiddy,rk2023-panel panel. This panel is extremely similar to the rg353p-panel but requires a smaller vertical back porch and isn't as tolerant of higher speeds.

Tested on my RG351V, RG353P, RG353V, and RK2023.

Signed-off-by Chris Morgan <[email protected]>

Hi Chris,

Thanks for the patch. Just have a minor question below.

Quoted 60 lines
---
  .../gpu/drm/panel/panel-newvision-nv3051d.c   | 56 +++++++++++++++----
  1 file changed, 45 insertions(+), 11 deletions(-)
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +23 -10
index 79de6c886292..d24c51503d68 100644
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
  	unsigned int num_modes;
  	u16 width_mm, height_mm;
  	u32 bus_flags;
+	u32 mode_flags;
  };
  struct panel_nv3051d {

@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
  	dsi->lanes = 4;
  	dsi->format = MIPI_DSI_FMT_RGB888;
-	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
-			  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
-	/*
-	 * The panel in the RG351V is identical to the 353P, except it
-	 * requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-	 */
-	if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
-		dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+	dsi->mode_flags = ctx->panel_info->mode_flags;
  	drm_panel_init(&ctx->panel, &dsi->dev, &panel_nv3051d_funcs,
  		       DRM_MODE_CONNECTOR_DSI);

@@ -481,18 +474,59 @@ static const struct drm_display_mode nv3051d_rgxx3_modes[] = {
  	},
  };
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+	{
+		.hdisplay       = 640,
+		.hsync_start    = 640 + 40,
+		.hsync_end      = 640 + 40 + 2,
+		.htotal         = 640 + 40 + 2 + 80,
+		.vdisplay       = 480,
+		.vsync_start    = 480 + 18,
+		.vsync_end      = 480 + 18 + 2,
+		.vtotal         = 480 + 18 + 2 + 4,
+		.clock          = 24150,
+		.flags          = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+	},
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
  	.display_modes = nv3051d_rgxx3_modes,
  	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
  	.width_mm = 70,
  	.height_mm = 57,
  	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+		      MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
Quoted 8 lines

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 507

Quoted 5 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +5 -0
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+	.display_modes = nv3051d_rgxx3_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+	.width_mm = 70,
+	.height_mm = 57,

Will all the panels for this driver be 70x57? If so, would it be better to set display_info.[width_mm|height_mm] directly?

They are all so far the same size, but I can't guarantee that going forward. To my knowledge this is the last of the nv3051d devices I'll be working on in the foreseeable future though, and so far they're all identical in size.

Quoted 15 lines
Quoted 15 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +13 -0
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+	.display_modes = nv3051d_rk2023_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+	.width_mm = 70,
+	.height_mm = 57,
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
  };
Quoted 8 lines

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 529

Quoted 8 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +4 -1
  static const struct of_device_id newvision_nv3051d_of_match[] = {
-	{ .compatible = "newvision,nv3051d", .data = &nv3051d_rgxx3_info },
+	{ .compatible = "anbernic,rg351v-panel", .data = &nv3051d_rg351v_info },
+	{ .compatible = "anbernic,rg353p-panel", .data = &nv3051d_rg353p_info },
+	{ .compatible = "powkiddy,rk2023-panel", .data = &nv3051d_rk2023_info },
  	{ /* sentinel */ }
  };
+

Sorry, will fix that in a V2. Thank you.

Quoted 12 lines

I think you can drop this stray newline.

Thanks,

Jessica Zhang

Quoted 5 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +0 -0
  MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
  static struct mipi_dsi_driver newvision_nv3051d_driver = {
Signature · 1 line
2.34.1
#9 lore raw

Re: [PATCH 2/5] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support

Quoted 88 lines · Chris Morgan
Quoted 78 lines · Jessica Zhang
Quoted 10 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Refactor the driver to add support for the powkiddy,rk2023-panel panel. This panel is extremely similar to the rg353p-panel but requires a smaller vertical back porch and isn't as tolerant of higher speeds.

Tested on my RG351V, RG353P, RG353V, and RK2023.

Signed-off-by Chris Morgan <[email protected]>

Hi Chris,

Thanks for the patch. Just have a minor question below.

Quoted 60 lines
---
   .../gpu/drm/panel/panel-newvision-nv3051d.c   | 56 +++++++++++++++----
   1 file changed, 45 insertions(+), 11 deletions(-)
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +23 -10
index 79de6c886292..d24c51503d68 100644
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
   	unsigned int num_modes;
   	u16 width_mm, height_mm;
   	u32 bus_flags;
+	u32 mode_flags;
   };
   struct panel_nv3051d {

@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
   	dsi->lanes = 4;
   	dsi->format = MIPI_DSI_FMT_RGB888;
-	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
-			  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
-	/*
-	 * The panel in the RG351V is identical to the 353P, except it
-	 * requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-	 */
-	if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
-		dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+	dsi->mode_flags = ctx->panel_info->mode_flags;
   	drm_panel_init(&ctx->panel, &dsi->dev, &panel_nv3051d_funcs,
   		       DRM_MODE_CONNECTOR_DSI);

@@ -481,18 +474,59 @@ static const struct drm_display_mode nv3051d_rgxx3_modes[] = {
   	},
   };
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+	{
+		.hdisplay       = 640,
+		.hsync_start    = 640 + 40,
+		.hsync_end      = 640 + 40 + 2,
+		.htotal         = 640 + 40 + 2 + 80,
+		.vdisplay       = 480,
+		.vsync_start    = 480 + 18,
+		.vsync_end      = 480 + 18 + 2,
+		.vtotal         = 480 + 18 + 2 + 4,
+		.clock          = 24150,
+		.flags          = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+	},
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
   	.display_modes = nv3051d_rgxx3_modes,
   	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
   	.width_mm = 70,
   	.height_mm = 57,
   	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+		      MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
Quoted 8 lines

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 507

Quoted 5 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +5 -0
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+	.display_modes = nv3051d_rgxx3_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+	.width_mm = 70,
+	.height_mm = 57,

Will all the panels for this driver be 70x57? If so, would it be better to set display_info.[width_mm|height_mm] directly?

Quoted 3 lines

They are all so far the same size, but I can't guarantee that going forward. To my knowledge this is the last of the nv3051d devices I'll be working on in the foreseeable future though, and so far they're all identical in size.

Got it, if it's not guaranteed might be better to leave it as it then. Thanks for clarifying.

BR,

Jessica Zhang

Quoted 39 lines
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +13 -0
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+	.display_modes = nv3051d_rk2023_modes,
+	.num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+	.width_mm = 70,
+	.height_mm = 57,
+	.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		      MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
   };
Quoted 8 lines

drivers/gpu/drm/panel/panel-newvision-nv3051d.c static const struct drm_display_mode nv3051d_rgxx3_modes[] = { · line 529

Quoted 8 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +4 -1
   static const struct of_device_id newvision_nv3051d_of_match[] = {
-	{ .compatible = "newvision,nv3051d", .data = &nv3051d_rgxx3_info },
+	{ .compatible = "anbernic,rg351v-panel", .data = &nv3051d_rg351v_info },
+	{ .compatible = "anbernic,rg353p-panel", .data = &nv3051d_rg353p_info },
+	{ .compatible = "powkiddy,rk2023-panel", .data = &nv3051d_rk2023_info },
   	{ /* sentinel */ }
   };
+

Sorry, will fix that in a V2. Thank you.

Quoted 12 lines

I think you can drop this stray newline.

Thanks,

Jessica Zhang

Quoted 5 lines
drivers/gpu/drm/panel/panel-newvision-nv3051d.c +0 -0
   MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
   static struct mipi_dsi_driver newvision_nv3051d_driver = {
Signature · 1 line
2.34.1
author
#10 lore raw

PATCH 3/5 clk: rockchip: rk3568: Add PLL rate for 115.2MHz

In reply to Chris Morgan

From: Chris Morgan <[email protected]>

Add support for a PLL rate of 115.2MHz so that the Powkiddy RK2023 panel can run at a requested 60hz (59.99, close enough).

I have confirmed this rate fits with all the constraints listed in the TRM for the VPLL (as an integer PLL) in Part 1 "Chapter 2 Clock & Reset Unit (CRU)."

Signed-off-by Chris Morgan <[email protected]>
---
 drivers/clk/rockchip/clk-rk3568.c | 1 +
 1 file changed, 1 insertion(+)
drivers/clk/rockchip/clk-rk3568.c +1 -0
index db713e1526cd..bfbcbb744327 100644
@@ -79,6 +79,7 @@ static struct rockchip_pll_rate_table rk3568_pll_rates[] = {
 	RK3036_PLL_RATE(148500000, 1, 99, 4, 4, 1, 0),
 	RK3036_PLL_RATE(135000000, 2, 45, 4, 1, 1, 0),
 	RK3036_PLL_RATE(119000000, 3, 119, 4, 2, 1, 0),
+	RK3036_PLL_RATE(115200000, 1, 24, 5, 1, 1, 0),
 	RK3036_PLL_RATE(108000000, 2, 45, 5, 1, 1, 0),
 	RK3036_PLL_RATE(101000000, 1, 101, 6, 4, 1, 0),
 	RK3036_PLL_RATE(100000000, 1, 150, 6, 6, 1, 0),
Signature · 1 line
2.34.1
author
#11 lore raw

PATCH 4/5 dt-bindings: arm: rockchip: Add Powkiddy RK2023

In reply to Chris Morgan

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +5 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
 
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023
+          - const: rockchip,rk3566
+
       - description: Radxa Compute Module 3(CM3)
         items:
           - enum:
Signature · 1 line
2.34.1
Acked-by on v1 4/5
#12 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Quoted 15 lines · Chris Morgan

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 6 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
 
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Acked-by Krzysztof Kozlowski <[email protected]>

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 680

Quoted 1 line
Documentation/devicetree/bindings/arm/rockchip.yaml +1 -0
+          - const: rockchip,rk3566

Best regards,
Krzysztof

maintainer
#13 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Am Donnerstag, 19. Oktober 2023, 11:21:47 CEST schrieb Krzysztof Kozlowski:

Quoted 19 lines · Chris Morgan
Quoted 18 lines

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Keeping similar devices together is perfectly fine. Like we do for example with the Rock PI 4A/4A+/B/B+/C family directly below.

The powkiddy,rk2023 really looks like very similar to the rgb30, so could do something similar.

The variant I don't like is having one big enum for _all_ boards using the same soc.

Heiko

Quoted 10 lines
Acked-by Krzysztof Kozlowski <[email protected]>

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 680

Quoted 1 line
Documentation/devicetree/bindings/arm/rockchip.yaml +1 -0
+          - const: rockchip,rk3566

Best regards,
Krzysztof

#14 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

In reply to Krzysztof Kozlowski
Quoted 19 lines · Krzysztof Kozlowski
Quoted 18 lines · Chris Morgan

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree.

Also I have one more Powkiddy device to send probably in the next week or two, then I'll be breaking for a while from new devices. :-)

Thank you,
Chris

Quoted 10 lines
Acked-by Krzysztof Kozlowski <[email protected]>

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 680

Quoted 1 line
Documentation/devicetree/bindings/arm/rockchip.yaml +1 -0
+          - const: rockchip,rk3566

Best regards,
Krzysztof

maintainer
#15 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Hey Chris,

Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan:

Quoted 27 lines · Krzysztof Kozlowski
Quoted 19 lines · Chris Morgan
Quoted 18 lines

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Quoted 4 lines

For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree.

In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has different devicetrees but is part of the same family of device designs.

So similar Powkiddy RK3568 based gaming handhelds also sound like a nice family name in the description ;-) .

Heiko

#16 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Quoted 35 lines · Heiko Stübner

Hey Chris,

Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan:

Quoted 27 lines · Krzysztof Kozlowski
Quoted 19 lines · Chris Morgan
Quoted 18 lines

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Quoted 4 lines

For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree.

Quoted 5 lines

In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has different devicetrees but is part of the same family of device designs.

So similar Powkiddy RK3568 based gaming handhelds also sound like a nice family name in the description ;-) .

Gotcha, I can do that. Would you like for me to go back and do the same for the Anbernic devices as well? I can do it as part of a seperate patch series.

Thank you.

Quoted 5 lines

Heiko

maintainer
#17 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Hi Chris,

Am Freitag, 20. Oktober 2023, 17:03:08 CEST schrieb Chris Morgan:

Quoted 39 lines · Heiko Stübner
Quoted 38 lines

Hey Chris,

Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan:

Quoted 27 lines · Krzysztof Kozlowski
Quoted 19 lines · Chris Morgan
Quoted 18 lines

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Quoted 4 lines

For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree.

In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has different devicetrees but is part of the same family of device designs.

Quoted 6 lines
Quoted 2 lines

So similar Powkiddy RK3568 based gaming handhelds also sound like a nice family name in the description ;-) .

Gotcha, I can do that. Would you like for me to go back and do the same for the Anbernic devices as well? I can do it as part of a seperate patch series.

that doing that for the Anberic devices would be really nice too, so yes please :-) .

Thanks
Heiko

#18 lore raw

Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023

Quoted 49 lines · Heiko Stübner

Hi Chris,

Am Freitag, 20. Oktober 2023, 17:03:08 CEST schrieb Chris Morgan:

Quoted 39 lines · Heiko Stübner
Quoted 38 lines

Hey Chris,

Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan:

Quoted 27 lines · Krzysztof Kozlowski
Quoted 19 lines · Chris Morgan
Quoted 18 lines

From: Chris Morgan <[email protected]>

The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC.

Signed-off-by Chris Morgan <[email protected]>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0
index a349bf4da6bc..a6612185a7ff 100644
@@ -674,6 +674,11 @@ properties:
           - const: powkiddy,rgb30
           - const: rockchip,rk3566
Quoted 6 lines

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 679

Quoted 3 lines
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -0
+      - description: Powkiddy RK2023
+        items:
+          - const: powkiddy,rk2023

This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko.

Quoted 4 lines

For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree.

In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has different devicetrees but is part of the same family of device designs.

Quoted 6 lines
Quoted 2 lines

So similar Powkiddy RK3568 based gaming handhelds also sound like a nice family name in the description ;-) .

Gotcha, I can do that. Would you like for me to go back and do the same for the Anbernic devices as well? I can do it as part of a seperate patch series.

Quoted 7 lines

that doing that for the Anberic devices would be really nice too, so yes please :-) .

Thanks
Heiko

Did you want me to resubmit the series or just push the changes on top of this one? I'll get them both queued up.

Thank you.

author
#19 lore raw

PATCH 5/5 arm64: dts: rockchip: add Powkiddy RK2023

In reply to Chris Morgan

From: Chris Morgan <[email protected]>

Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld gaming device with a 3.5 inch screen powered by the Rockchip RK3566 SoC. The device is almost identical to the Anbernic RG353P except it lacks eMMC, a function button, a touch screen, no UART headers on the board, and the panel has slightly different timings.

Signed-off-by Chris Morgan <[email protected]>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3566-powkiddy-rk2023.dts   | 161 ++++++++++++++++++
 2 files changed, 162 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
arch/arm64/boot/dts/rockchip/Makefile +1 -0
index 3f01b429a3aa..9ef64cfb8392 100644
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-radxa-cm3-io.dtb
arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts new file +161 -0

161 lines not on this page · raw message

Signature · 1 line
2.34.1
maintainer Applied
#20 lore raw

Re: (subset) [PATCH 0/5] rockchip: Add Powkiddy RK2023

In reply to Chris Morgan
Quoted 5 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Add support for the Powkiddy RK2023, which is extremely similar to existing devices from Anbernic.

Quoted 8 lines

Chris Morgan (5):
dt-bindings: display: panel: Update NewVision NV3051D compatibles drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support
clk: rockchip: rk3568: Add PLL rate for 115.2MHz
dt-bindings: arm: rockchip: Add Powkiddy RK2023
arm64: dts: rockchip: add Powkiddy RK2023

[...]

Applied, thanks!

[3/5] clk: rockchip: rk3568: Add PLL rate for 115.2MHz

      commit: ccf59682a0287b81015dc1939203fac70b818c6b

I've gone forward and grabbed the PLL rate already, so it can go together with the other rate addition from the fixes series.

Best regards,

Signature · 1 line
Heiko Stuebner <[email protected]>