* [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller whose
AXI and AHB bus clocks share a single gate enable bit with the display
core clock, so the clock driver does not expose them separately. This
patch makes the axi and ahb clocks optional in the probe.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/vs_dc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
index 9729b693d360..fd1f5fe67a68 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->core_clk);
}
- dc->axi_clk = devm_clk_get_enabled(dev, "axi");
+ dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
if (IS_ERR(dc->axi_clk)) {
dev_err(dev, "can't get axi clock\n");
return PTR_ERR(dc->axi_clk);
}
- dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
+ dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
if (IS_ERR(dc->ahb_clk)) {
dev_err(dev, "can't get ahb clock\n");
return PTR_ERR(dc->ahb_clk);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
The DC8200 and DCUltraLite share a broadly similar register layout but
differ in how the bridge, CRTC, primary plane and IRQ paths are driven.
Introduce a vs_dc_funcs vtable so each variant can supply its own
implementation without scattering conditionals across multiple files.
Add a generation field to struct vs_chip_identity to distinguish variants.
Extract the DC8200-specific hardware ops into vs_dc8200.c and add unified
IRQ bit definitions so implementations can translate hardware-specific
bits to a common set. Update the shared code to dispatch through
dc->funcs.
No behaviour change for existing DC8200 platforms.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
drivers/gpu/drm/verisilicon/vs_dc.c | 6 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 32 +++++
drivers/gpu/drm/verisilicon/vs_dc8200.c | 115 ++++++++++++++++++
drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
.../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
11 files changed, 214 insertions(+), 54 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
index 426f4bcaa834..9d4cd16452fa 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
-verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o vs_hwdb.o \
+verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_drm.o vs_hwdb.o \
vs_plane.o vs_primary_plane.o vs_cursor_plane.o
obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c b/drivers/gpu/drm/verisilicon/vs_bridge.c
index dc7c85b07fe3..3fbc8d57f8a1 100644
--- a/drivers/gpu/drm/verisilicon/vs_bridge.c
+++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
@@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct vs_crtc *crtc,
VSDC_DISP_PANEL_CONFIG_DE_EN |
VSDC_DISP_PANEL_CONFIG_DAT_EN |
VSDC_DISP_PANEL_CONFIG_CLK_EN);
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
- VSDC_DISP_PANEL_CONFIG_RUNNING);
- regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_RUNNING(output));
-
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
- VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+
+ dc->funcs->panel_enable_ex(dc, output);
}
static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
@@ -228,14 +221,7 @@ static void vs_bridge_atomic_disable(struct drm_bridge *bridge,
struct vs_dc *dc = crtc->dc;
unsigned int output = crtc->id;
- regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
- VSDC_DISP_PANEL_START_RUNNING(output));
- regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
- VSDC_DISP_PANEL_CONFIG_RUNNING);
-
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
- VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+ dc->funcs->panel_disable_ex(dc, output);
}
static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
index 0b8a35d09cd2..1c4aac708669 100644
--- a/drivers/gpu/drm/verisilicon/vs_crtc.c
+++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
@@ -16,10 +16,33 @@
#include "vs_crtc_regs.h"
#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#include "vs_plane.h"
+static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
+ struct drm_atomic_commit *state)
+{
+ struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
+ struct vs_dc *dc = vcrtc->dc;
+ unsigned int output = vcrtc->id;
+
+ if (dc->funcs->crtc_begin)
+ dc->funcs->crtc_begin(dc, output);
+}
+
+static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_atomic_commit *state)
+{
+ struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
+ struct vs_dc *dc = vcrtc->dc;
+ unsigned int output = vcrtc->id;
+
+ if (dc->funcs->crtc_flush)
+ dc->funcs->crtc_flush(dc, output);
+
+ drm_crtc_vblank_atomic_flush(crtc, state);
+}
+
static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_commit *state)
{
@@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
drm_crtc_vblank_off(crtc);
clk_disable_unprepare(dc->pix_clk[output]);
+
+ if (dc->funcs->crtc_disable_ex)
+ dc->funcs->crtc_disable_ex(dc, output);
}
static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
drm_WARN_ON(&dc->drm_dev->base,
clk_prepare_enable(dc->pix_clk[output]));
+ if (dc->funcs->crtc_enable_ex)
+ dc->funcs->crtc_enable_ex(dc, output);
+
drm_crtc_vblank_on(crtc);
}
@@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
- .atomic_flush = drm_crtc_vblank_atomic_flush,
+ .atomic_begin = vs_crtc_atomic_begin,
+ .atomic_flush = vs_crtc_atomic_flush,
.atomic_enable = vs_crtc_atomic_enable,
.atomic_disable = vs_crtc_atomic_disable,
.mode_set_nofb = vs_crtc_mode_set_nofb,
@@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN, VSDC_TOP_IRQ_VSYNC(vcrtc->id));
+ dc->funcs->enable_vblank(dc, vcrtc->id);
return 0;
}
@@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
struct vs_dc *dc = vcrtc->dc;
- regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN, VSDC_TOP_IRQ_VSYNC(vcrtc->id));
+ dc->funcs->disable_vblank(dc, vcrtc->id);
}
static const struct drm_crtc_funcs vs_crtc_funcs = {
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
index dad9967bc10b..9729b693d360 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -8,9 +8,7 @@
#include <linux/of.h>
#include <linux/of_graph.h>
-#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#include "vs_hwdb.h"
@@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
struct vs_dc *dc = private;
u32 irqs;
- regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
+ irqs = dc->funcs->irq_ack(dc);
vs_drm_handle_irq(dc, irqs);
@@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device *pdev)
dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
dc->identity.revision, dc->identity.customer_id);
+ dc->funcs = &vs_dc8200_funcs;
+
if (port_count > dc->identity.display_count) {
dev_err(dev, "too many downstream ports than HW capability\n");
ret = -EINVAL;
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h b/drivers/gpu/drm/verisilicon/vs_dc.h
index ed1016f18758..825f5dd6bf17 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.h
+++ b/drivers/gpu/drm/verisilicon/vs_dc.h
@@ -14,6 +14,7 @@
#include <linux/reset.h>
#include <drm/drm_device.h>
+#include <drm/drm_plane.h>
#include "vs_hwdb.h"
@@ -22,6 +23,34 @@
struct vs_drm_dev;
struct vs_crtc;
+struct vs_dc;
+
+struct vs_dc_funcs {
+ /* Bridge: atomic_enable, atomic_disable */
+ void (*panel_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*panel_disable_ex)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: atomic_begin, atomic_flush */
+ void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
+ void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: atomic_enable, atomic_disable */
+ void (*crtc_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*crtc_disable_ex)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: enable_vblank, disable_vblank */
+ void (*enable_vblank)(struct vs_dc *dc, unsigned int output);
+ void (*disable_vblank)(struct vs_dc *dc, unsigned int output);
+
+ /* Primary plane: atomic_enable, atomic_disable, atomic_update */
+ void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned int output,
+ struct drm_plane_state *state);
+
+ /* IRQ acknowledge */
+ u32 (*irq_ack)(struct vs_dc *dc);
+};
struct vs_dc {
struct regmap *regs;
@@ -33,6 +62,9 @@ struct vs_dc {
struct vs_drm_dev *drm_dev;
struct vs_chip_identity identity;
+ const struct vs_dc_funcs *funcs;
};
+extern const struct vs_dc_funcs vs_dc8200_funcs;
+
#endif /* _VS_DC_H_ */
diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c b/drivers/gpu/drm/verisilicon/vs_dc8200.c
new file mode 100644
index 000000000000..17378f4ef96d
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
+ */
+
+#include <linux/regmap.h>
+
+#include "vs_bridge_regs.h"
+#include "vs_dc.h"
+#include "vs_dc_top_regs.h"
+#include "vs_drm.h"
+#include "vs_plane.h"
+#include "vs_primary_plane_regs.h"
+
+static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
+ VSDC_DISP_PANEL_CONFIG_RUNNING);
+ regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_RUNNING(output));
+
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
+ VSDC_DISP_PANEL_CONFIG_RUNNING);
+ regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
+ VSDC_DISP_PANEL_START_RUNNING(output));
+
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(output));
+}
+
+static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(output));
+}
+
+static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_FB_EN);
+ regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
+ VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
+
+ vs_dc8200_plane_commit(dc, output);
+}
+
+static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_FB_EN);
+
+ vs_dc8200_plane_commit(dc, output);
+}
+
+static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc, unsigned int output,
+ struct drm_plane_state *state)
+{
+ regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
+ VSDC_MAKE_PLANE_POS(state->crtc_x, state->crtc_y));
+ regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
+ VSDC_MAKE_PLANE_POS(state->crtc_x + state->crtc_w,
+ state->crtc_y + state->crtc_h));
+ regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
+ VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
+
+ vs_dc8200_plane_commit(dc, output);
+}
+
+static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
+{
+ u32 hw_irqs, unified = 0;
+ unsigned int i;
+
+ regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
+
+ for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
+ if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
+ unified |= VSDC_IRQ_VSYNC(i);
+ }
+
+ return unified;
+}
+
+const struct vs_dc_funcs vs_dc8200_funcs = {
+ .panel_enable_ex = vs_dc8200_panel_enable_ex,
+ .panel_disable_ex = vs_dc8200_panel_disable_ex,
+ .enable_vblank = vs_dc8200_enable_vblank,
+ .disable_vblank = vs_dc8200_disable_vblank,
+ .primary_plane_enable_ex = vs_dc8200_primary_plane_enable_ex,
+ .primary_plane_disable_ex = vs_dc8200_primary_plane_disable_ex,
+ .primary_plane_update_ex = vs_dc8200_primary_plane_update_ex,
+ .irq_ack = vs_dc8200_irq_ack,
+};
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
index fd259d53f49f..24e9d0b008f3 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.c
+++ b/drivers/gpu/drm/verisilicon/vs_drm.c
@@ -25,7 +25,6 @@
#include "vs_bridge.h"
#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#define DRIVER_NAME "verisilicon"
@@ -168,8 +167,8 @@ void vs_drm_handle_irq(struct vs_dc *dc, u32 irqs)
unsigned int i;
for (i = 0; i < dc->identity.display_count; i++) {
- if (irqs & VSDC_TOP_IRQ_VSYNC(i)) {
- irqs &= ~VSDC_TOP_IRQ_VSYNC(i);
+ if (irqs & VSDC_IRQ_VSYNC(i)) {
+ irqs &= ~VSDC_IRQ_VSYNC(i);
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
}
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.h b/drivers/gpu/drm/verisilicon/vs_drm.h
index 606338206a42..6a89c20879df 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.h
+++ b/drivers/gpu/drm/verisilicon/vs_drm.h
@@ -6,6 +6,7 @@
#ifndef _VS_DRM_H_
#define _VS_DRM_H_
+#include <linux/bits.h>
#include <linux/platform_device.h>
#include <linux/types.h>
@@ -13,6 +14,13 @@
struct vs_dc;
+/*
+ * DC variants use different interrupt registers with diverging bit
+ * assignments; each irq_ack() implementation must translate its
+ * hardware-specific bits into these definitions.
+ */
+#define VSDC_IRQ_VSYNC(n) BIT(n)
+
struct vs_drm_dev {
struct drm_device base;
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
index 2a0f7c59afa3..91524d16f778 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
@@ -94,6 +94,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = ~0U,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
@@ -103,6 +104,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5721,
.customer_id = 0x30B,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
@@ -112,6 +114,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = 0x310,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_with_yuv444,
@@ -121,6 +124,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = 0x311,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h b/drivers/gpu/drm/verisilicon/vs_hwdb.h
index 2065ecb73043..a15c8b565604 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
@@ -9,6 +9,11 @@
#include <linux/regmap.h>
#include <linux/types.h>
+enum vs_dc_generation {
+ VSDC_GEN_DC8000,
+ VSDC_GEN_DC8200,
+};
+
struct vs_formats {
const u32 *array;
unsigned int num;
@@ -19,6 +24,7 @@ struct vs_chip_identity {
u32 revision;
u32 customer_id;
+ enum vs_dc_generation generation;
u32 display_count;
/*
* The hardware only supports square cursor planes, so this field
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
index 1f2be41ae496..f992cb277f61 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
@@ -53,12 +53,6 @@ static int vs_primary_plane_atomic_check(struct drm_plane *plane,
return 0;
}
-static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int output)
-{
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_COMMIT);
-}
-
static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
struct drm_atomic_commit *atomic_state)
{
@@ -69,13 +63,8 @@ static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
unsigned int output = vcrtc->id;
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_FB_EN);
- regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
- VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_enable_ex)
+ dc->funcs->primary_plane_enable_ex(dc, output);
}
static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
@@ -88,10 +77,8 @@ static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
unsigned int output = vcrtc->id;
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_FB_EN);
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_disable_ex)
+ dc->funcs->primary_plane_disable_ex(dc, output);
}
static void vs_primary_plane_atomic_update(struct drm_plane *plane,
@@ -133,18 +120,11 @@ static void vs_primary_plane_atomic_update(struct drm_plane *plane,
regmap_write(dc->regs, VSDC_FB_STRIDE(output),
fb->pitches[0]);
- regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
- VSDC_MAKE_PLANE_POS(state->crtc_x, state->crtc_y));
- regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
- VSDC_MAKE_PLANE_POS(state->crtc_x + state->crtc_w,
- state->crtc_y + state->crtc_h));
regmap_write(dc->regs, VSDC_FB_SIZE(output),
VSDC_MAKE_PLANE_SIZE(state->crtc_w, state->crtc_h));
- regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
- VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_update_ex)
+ dc->funcs->primary_plane_update_ex(dc, output, state);
}
static const struct drm_plane_helper_funcs vs_primary_plane_helper_funcs = {
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] drm/verisilicon: add register-level macros for DC8000
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
Add register-level constants needed by the forthcoming DC8000 (DCUltraLite)
hardware ops:
VSDC_DISP_IRQ_VSYNC(n) in vs_crtc_regs.h: bit mask for per-output
VSYNC interrupt bits in DISP_IRQ_STA (0x147C) / DISP_IRQ_EN (0x1480),
which are the IRQ registers used by DCUltraLite in place of the DC8200
TOP_IRQ_ACK / TOP_IRQ_EN registers.
VSDC_FB_CONFIG_ENABLE (bit 0), VSDC_FB_CONFIG_VALID (bit 3) and
VSDC_FB_CONFIG_RESET (bit 4) in vs_primary_plane_regs.h: control bits
in the FB_CONFIG register used by DCUltraLite for framebuffer enable
and per-frame commit handshake.
No behaviour change for existing DC8200 platforms.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
index c7930e817635..d4da22b08cd5 100644
--- a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
+++ b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
@@ -54,6 +54,7 @@
#define VSDC_DISP_GAMMA_DATA(n) (0x1460 + 0x4 * (n))
#define VSDC_DISP_IRQ_STA 0x147C
+#define VSDC_DISP_IRQ_VSYNC(n) BIT(n)
#define VSDC_DISP_IRQ_EN 0x1480
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
index cbb125c46b39..67d4b00f294e 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
@@ -16,6 +16,9 @@
#define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
#define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
+#define VSDC_FB_CONFIG_ENABLE BIT(0)
+#define VSDC_FB_CONFIG_VALID BIT(3)
+#define VSDC_FB_CONFIG_RESET BIT(4)
#define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
#define VSDC_FB_CONFIG_ROT_MASK GENMASK(13, 11)
#define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
The verisilicon,dc binding was originally written for the T-Head TH1520
SoC carrying a DC8200, and hard-codes five clocks, three resets and two
output ports.
Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the binding.
The DCUltraLite uses only two clocks (core, pix0) and one reset (core),
with a single output port.
Use allOf/if blocks to express per-variant constraints rather than
hard-coding the DC8200 topology at the top level. Each compatible's
block constrains the clock and reset item counts; the nuvoton block
additionally overrides clock-names to the two names it actually uses.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 9dc35ab973f2..1e751f3c7ce8 100644
--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -17,6 +17,7 @@ properties:
items:
- enum:
- thead,th1520-dc8200
+ - nuvoton,ma35d1-dcu
- const: verisilicon,dc # DC IPs have discoverable ID/revision registers
reg:
@@ -77,6 +78,62 @@ required:
- clock-names
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: thead,th1520-dc8200
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
+ resets:
+ minItems: 3
+ maxItems: 3
+
+ reset-names:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nuvoton,ma35d1-dcu
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: pix0
+
+ resets:
+ minItems: 1
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: core
+
+ required:
+ - resets
+ - reset-names
+
additionalProperties: false
examples:
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
This series adds support for the Verisilicon DCUltraLite display
controller as integrated in the Nuvoton MA35D1 SoC.
The Verisilicon DC driver and its DT binding were originally written by
Icenowy Zheng <zhengxingda@iscas.ac.cn> for the T-Head TH1520 SoC, which
carries a DC8200 IP block. The present series builds on that foundation
with gratitude to Icenowy for the original work.
The DCUltraLite is a different variant in the DC IP family. While the two
IPs share a broadly similar register layout, a number of differences
prevent the existing driver from working on the MA35D1 without
modification:
- No CONFIG_EX commit path: the DC8200 staging registers
(FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
PANEL_CONFIG_EX) are absent. The DCUltraLite uses enable (bit 0) and
reset (bit 4) bits in FB_CONFIG for direct framebuffer updates, and
requires a per-frame VALID bit toggle (FB_CONFIG bit 3) to latch
configuration changes.
- No PANEL_START register: panel output begins when
PANEL_CONFIG.RUNNING is set; the DC8200 multi-display sync start
register at 0x1CCC does not exist.
- Different IRQ registers: DISP_IRQ_STA at 0x147C / DISP_IRQ_EN at
0x1480, versus the DC8200's TOP_IRQ_ACK at 0x0010 / TOP_IRQ_EN at
0x0014.
- Simpler clock topology: two clocks ("core" bus gate and "pix0" pixel
divider); no axi or ahb clocks required.
- Single display output: no per-output indexing beyond index 0 is
needed.
- Hardware-discoverable identity: the DCUltraLite exposes chip identity
registers whose model field reads 0x0 (revision 0x5560,
customer_id 0x305), allowing the existing vs_fill_chip_identity()
path to identify the variant purely through register reads.
Patch 1 generalises the verisilicon,dc DT binding to accommodate the
Nuvoton MA35D1 SoC-specific compatible and the variant's two-clock,
one-reset, single-port topology.
Patch 2 adds the register-level macros needed by the DC8000 ops.
Patches 3-5 introduce the driver changes in three logical steps: the
vs_dc_funcs hardware ops vtable with DC8200 ops extracted into
vs_dc8200.c; making axi/ahb clocks optional as a separate atomic change;
and the DC8000 ops in vs_dc8000.c. Patch 6 adds the DCUltraLite HWDB
entry that gates hardware recognition once all support is in place.
Patch 7 adds the Kconfig dependency on ARCH_MA35, placed last because it
is only meaningful after the HWDB entry is added.
All patches have been tested on Nuvoton MA35D1 hardware.
Changes from v4:
- [dt-bindings] Kept clock and reset item descriptions in the global
clocks:/resets: properties; per-compatible sections only constrain
minItems/maxItems and override clock-names items for nuvoton,ma35d1-dcu.
- [dt-bindings] Dropped redundant global minItems/maxItems on clocks:
and clock-names:.
- [dt-bindings] Dropped the extra-space typo fix in port@0 description
to keep the patch atomic; left for a separate patch later.
- [ops] Renamed crtc_enable/crtc_disable hooks to crtc_enable_ex/
crtc_disable_ex.
- [ops] Added unified IRQ bit definitions; each irq_ack() implementation
now translates hardware-specific bits before returning.
- [clocks] Split the axi/ahb optional-clock change into its own patch
for atomicity.
- [hwdb] Simplified the commit message for patch 6.
- [kconfig] Simplified the commit message for patch 7.
Joey Lu (7):
dt-bindings: display: verisilicon,dc: generalize for single-output
variants
drm/verisilicon: add register-level macros for DC8000
drm/verisilicon: introduce per-variant hardware ops table
drm/verisilicon: make axi and ahb clocks optional
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
drm/verisilicon: add DCUltraLite chip identity to HWDB
drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
drivers/gpu/drm/verisilicon/vs_dc.c | 13 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 33 +++++
drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++
drivers/gpu/drm/verisilicon/vs_dc8200.c | 115 ++++++++++++++++++
drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
drivers/gpu/drm/verisilicon/vs_hwdb.c | 14 +++
drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
.../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
.../drm/verisilicon/vs_primary_plane_regs.h | 3 +
16 files changed, 378 insertions(+), 57 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
--
2.43.0
^ permalink raw reply
* Re: [PATCH v8 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: sashiko-bot @ 2026-06-25 9:42 UTC (permalink / raw)
To: Neil Armstrong; +Cc: wsa+renesas, conor+dt, dri-devel, robh, devicetree
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-2-8570e692143e@linaro.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Asymmetric panel callbacks for DCS commands (display on/off) causes state mismatch and permanent blanking.
- [High] The panel initialization sequence sends the `set_display_on` command before the `exit_sleep_mode` command.
- [High] Missing device link between the panel and the secondary DSI host leads to Use-After-Free and Double-Free.
--
commit bd7c7e227b10119b2ca8cfde561c22808d05f4f2
Author: KancyJoe <kancy2333@outlook.com>
drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
This commit implements support for the Renesas 63419 based dual-DSI video
mode Display Panels used in the Ayaneo handheld gaming devices.
> diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c
[ ... ]
> +static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + /*
> + * Panel registers are loaded from DDIC Non Volatile Memory
> + *
> + * The DDIC expects this sequence to get out of sleep and enable display
> + */
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_on_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
[Severity: High]
Are these MIPI DCS commands sent in the correct order?
According to the standard, a display must exit sleep mode and wait for
internal initialization before processing the set_display_on command.
Sending set_display_on first might cause the sleeping DDIC to ignore it.
> + mipi_dsi_msleep(&dsi_ctx, 150);
> +
> + return dsi_ctx.accum_err;
> +}
[ ... ]
> +static int renesas_r63419_disable(struct drm_panel *panel)
> +{
> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_off_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_enter_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> +
> + return 0;
> +}
[ ... ]
> +static const struct drm_panel_funcs renesas_r63419_panel_funcs = {
> + .disable = renesas_r63419_disable,
> + .prepare = renesas_r63419_prepare,
> + .unprepare = renesas_r63419_unprepare,
[Severity: High]
Should there be an enable callback to match the disable callback?
If the display pipeline is disabled and re-enabled during DPMS transitions,
the bridge framework cycles disable and enable. Since the panel receives
set_display_off and enter_sleep_mode during disable, but the enable
callback is missing, won't the panel remain permanently asleep when waking
up?
> + .get_modes = renesas_r63419_get_modes,
> + .get_orientation = renesas_r63419_get_orientation,
> +};
[ ... ]
> +static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
> +{
[ ... ]
> + /* Register the second DSI device */
> + ctx->dsi[1] = devm_mipi_dsi_device_register_full(dev, dsi1_host, &info);
> + if (IS_ERR(ctx->dsi[1]))
> + return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
> + "Failed to register second DSI device\n");
[Severity: High]
Does the secondary DSI device registration require a device link to protect
its lifetime?
If the secondary host is unbound via sysfs, the DSI core unregisters all
child devices, freeing this pointer. Without a device link to force the
panel to unbind first, could devm teardown or subsequent panel accesses
lead to a use-after-free or double-free?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org?part=2
^ permalink raw reply
* Re: [PATCH] ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_id
From: Viresh Kumar @ 2026-06-25 9:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Viresh Kumar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, soc, devicetree, linux-kernel
In-Reply-To: <20260625091355.107054-2-krzysztof.kozlowski@oss.qualcomm.com>
On 25-06-26, 11:13, Krzysztof Kozlowski wrote:
> "usbh0_id" and "usbh1_id" properties were never documented and never
> used by Linux drivers, thus should be safe to drop to fix dtbs_check
> warnings like:
>
> st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected)
> st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected)
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm/boot/dts/st/spear13xx.dtsi | 4 ----
> 1 file changed, 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Akhil R @ 2026-06-25 9:38 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, linux-hwmon,
linux-i3c, robh, sashiko-reviews
In-Reply-To: <ajwamrU8ehBINzxq@lizhi-Precision-Tower-5810>
On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
...
...
>> [Severity: High]
>> Is it possible that sending the SETAASA broadcast before direct SETDASA
>> assignments breaks initialization for devices that natively support SETAASA
>> but are configured for SETDASA?
>>
>> According to the I3C specification, any device on the bus natively supporting
>> SETAASA will respond to this broadcast by adopting its static address as its
>> dynamic address.
>>
>> After this broadcast, the driver iterates through devices and attempts to
>> assign custom dynamic addresses via direct SETDASA commands:
>>
>> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
>> ...
>> ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
>> i3cdev->boardinfo->init_dyn_addr);
>> ...
>> }
>>
>> Since the target device already adopted its dynamic address during the
>> SETAASA broadcast, it is no longer in the unassigned state and will NACK
>> the subsequent SETDASA command.
>
> Look like correct, but I am not sure if target will NACK SETDASA. Or should
> use SETNEWDA for SETAASA method.
Yes, this looks valid for mixed device buses. I can move
i3c_master_setaasa_locked() after the SETDASA handling and before
i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
ignore the later SETAASA broadcast. Does that sound good to you?
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Enable cameras
From: Konrad Dybcio @ 2026-06-25 9:30 UTC (permalink / raw)
To: Hongyang Zhao, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rosh
In-Reply-To: <20260616-rubikpi-next-20260615-v1-1-3d96b89397ff@thundersoft.com>
On 6/16/26 9:29 AM, Hongyang Zhao wrote:
> Enable the two Raspberry Pi camera connectors on RubikPi 3 with
> IMX219 sensors. CAM1 is connected to CCI1 and CSIPHY1, while CAM2
> is connected to CCI0 and CSIPHY4.
>
> Add the shared 24 MHz camera oscillator, camera power enable
> regulators, CAMSS endpoints, CCI sensor nodes and privacy LED GPIOs.
>
> Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com>
> ---
[...]
> + vreg_cam1_pwr: regulator-camera1-pwr {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vreg_camera1_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 57 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-0 = <&cam1_pwr_en>;
> + pinctrl-names = "default";
> +
> + vin-supply = <&vreg_vcc3v3_output>;
> + };
> +
> + vreg_cam2_pwr: regulator-camera2-pwr {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vreg_camera2_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-0 = <&cam2_pwr_en>;
> + pinctrl-names = "default";
> +
> + vin-supply = <&vreg_vcc3v3_output>;
> + };
Are these supplies part of the baseboard?
[...]
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CAM1 is routed to CSI1 / CSIPHY1. */
I believe these comments are self-explanatory given the names of the labels
[...]
> + cam1_privacy_led_state: cam1-privacy-led-state {
> + pins = "gpio18";
> + function = "gpio";
> + drive-strength = <8>;
> + output-low;
Please drop the output-foo properties from TLMM pins, the GPIO
state will be controlled by the driver
Konrad
^ permalink raw reply
* [PATCH v8 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, KancyJoe
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org>
From: KancyJoe <kancy2333@outlook.com>
Implement support for the Renesas 63419 based dual-DSI video mode
Display Panels found in the Ayaneo gaming handled devices.
Signed-off-by: KancyJoe <kancy2333@outlook.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-renesas-r63419.c | 350 +++++++++++++++++++++++++++
3 files changed, 363 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index c0cc2bb4a3eb..2e84f6ce8190 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -826,6 +826,18 @@ config DRM_PANEL_RENESAS_R61307
This panel controller can be found in LG Optimus Vu P895 smartphone
in combination with LCD panel.
+config DRM_PANEL_RENESAS_R63419
+ tristate "Renesas R63419 dual-DSI video mode panels"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Ayaneo WT0600 and WT0630
+ 1440x2560 60Hz dual-DSI video mode display panels with Renesas
+ R63419 IC.
+
+ These panels are used in Ayaneo handheld gaming devices.
+
config DRM_PANEL_RENESAS_R69328
tristate "Renesas R69328 720x1280 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 6926ef28ab8d..17bd4f51098f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RENESAS_R61307) += panel-renesas-r61307.o
+obj-$(CONFIG_DRM_PANEL_RENESAS_R63419) += panel-renesas-r63419.o
obj-$(CONFIG_DRM_PANEL_RENESAS_R69328) += panel-renesas-r69328.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_AMS581VF01) += panel-samsung-ams581vf01.o
diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
new file mode 100644
index 000000000000..59ac323f5276
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Renesas R63419 based dual-DSI video mode panels
+ *
+ * Copyright (c) 2025, Kancy Joe <kancy2333@outlook.com>
+ * Copyright (C) 2026 Linaro Limited
+ * Author: Neil Armstrong <neil.armstrong@linaro.org>
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+
+#include <drm/drm_connector.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_probe_helper.h>
+
+struct renesas_r63419_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ const struct panel_desc *desc;
+
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data *vdd_supplies;
+ struct regulator_bulk_data *vcc_supplies;
+ enum drm_panel_orientation orientation;
+};
+
+/* VDDIO/VDD Supplies */
+static const struct regulator_bulk_data renesas_r63419_vdd_supplies[] = {
+ { .supply = "vddio" },
+ { .supply = "vdd" },
+};
+
+/* VSP/VSN/VCI Supplies */
+static const struct regulator_bulk_data renesas_r63419_vcc_supplies[] = {
+ { .supply = "vsp" },
+ { .supply = "vsn" },
+ { .supply = "vci" },
+};
+
+struct panel_desc {
+ const struct drm_display_mode *mode;
+ unsigned int lanes;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct mipi_dsi_device_info dsi_info;
+};
+
+static const struct drm_display_mode wt0600_mode = {
+ /* Dual dsi */
+ .clock = 2 * (720 + 100 + 8 + 40) * (2560 + 15 + 2 + 8) * 60 / 1000,
+ .hdisplay = 2 * 720,
+ .hsync_start = 2 * (720 + 100),
+ .hsync_end = 2 * (720 + 100 + 8),
+ .htotal = 2 * (720 + 100 + 8 + 40),
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 15,
+ .vsync_end = 2560 + 15 + 2,
+ .vtotal = 2560 + 15 + 2 + 8,
+ .type = DRM_MODE_TYPE_DRIVER,
+ .width_mm = 74,
+ .height_mm = 131,
+};
+
+static const struct drm_display_mode wt0630_mode = {
+ /* Dual dsi */
+ .clock = 2 * (720 + 100 + 8 + 40) * (2560 + 15 + 2 + 8) * 60 / 1000,
+ .hdisplay = 2 * 720,
+ .hsync_start = 2 * (720 + 100),
+ .hsync_end = 2 * (720 + 100 + 8),
+ .htotal = 2 * (720 + 100 + 8 + 40),
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 15,
+ .vsync_end = 2560 + 15 + 2,
+ .vtotal = 2560 + 15 + 2 + 8,
+ .type = DRM_MODE_TYPE_DRIVER,
+ .width_mm = 78,
+ .height_mm = 140,
+};
+
+static struct panel_desc wt0600_desc = {
+ .lanes = 4,
+ .mode = &wt0600_mode,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+};
+
+static struct panel_desc wt0630_desc = {
+ .lanes = 4,
+ .mode = &wt0630_mode, /* wt0600 only has different screen size */
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+};
+
+static inline struct renesas_r63419_panel *
+to_renesas_r63419_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct renesas_r63419_panel, panel);
+}
+
+static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
+{
+ struct mipi_dsi_multi_context dsi_ctx = { 0 };
+
+ /*
+ * Panel registers are loaded from DDIC Non Volatile Memory
+ *
+ * The DDIC expects this sequence to get out of sleep and enable display
+ */
+
+ mipi_dsi_dual(mipi_dsi_dcs_set_display_on_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 50);
+
+ mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 150);
+
+ return dsi_ctx.accum_err;
+}
+
+static int renesas_r63419_disable(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ struct mipi_dsi_multi_context dsi_ctx = { 0 };
+
+ mipi_dsi_dual(mipi_dsi_dcs_set_display_off_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 50);
+
+ mipi_dsi_dual(mipi_dsi_dcs_enter_sleep_mode_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 120);
+
+ return 0;
+}
+
+static int renesas_r63419_prepare(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+ if (ret < 0)
+ return ret;
+
+ usleep_range(1000, 2000);
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ ctx->vcc_supplies);
+ if (ret < 0) {
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+ return ret;
+ }
+
+ usleep_range(1000, 2000);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+
+ usleep_range(3000, 4000);
+
+ ret = renesas_r63419_on(ctx);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to initialize panel: %d\n", ret);
+
+ /* Power off sequence from the r63419 datasheet */
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ ctx->vcc_supplies);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+static int renesas_r63419_unprepare(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+
+ /* Power off sequence from the r63419 datasheet */
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies), ctx->vdd_supplies);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies), ctx->vcc_supplies);
+
+ return 0;
+}
+
+static int renesas_r63419_get_modes(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ const struct drm_display_mode *mode = ctx->desc->mode;
+
+ return drm_connector_helper_get_modes_fixed(connector, mode);
+}
+
+static enum drm_panel_orientation
+renesas_r63419_get_orientation(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+
+ return ctx->orientation;
+}
+
+static const struct drm_panel_funcs renesas_r63419_panel_funcs = {
+ .disable = renesas_r63419_disable,
+ .prepare = renesas_r63419_prepare,
+ .unprepare = renesas_r63419_unprepare,
+ .get_modes = renesas_r63419_get_modes,
+ .get_orientation = renesas_r63419_get_orientation,
+};
+
+static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_device_info info = { 0 };
+ struct device *dev = &dsi->dev;
+ struct renesas_r63419_panel *ctx;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_host *dsi1_host;
+ int ret, i;
+
+ ctx = devm_drm_panel_alloc(dev, struct renesas_r63419_panel, panel,
+ &renesas_r63419_panel_funcs, DRM_MODE_CONNECTOR_DSI);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+
+ ctx->desc = of_device_get_match_data(dev);
+ if (!ctx->desc)
+ return dev_err_probe(dev, -ENODEV,
+ "Failed to get panel description\n");
+
+ ret = devm_regulator_bulk_get_const(&dsi->dev,
+ ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ renesas_r63419_vdd_supplies, &ctx->vdd_supplies);
+ if (ret < 0)
+ return ret;
+
+ ret = devm_regulator_bulk_get_const(&dsi->dev,
+ ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ renesas_r63419_vcc_supplies, &ctx->vcc_supplies);
+ if (ret < 0)
+ return ret;
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
+ "Failed to get reset gpio\n");
+
+ /* Get second DSI host */
+ dsi1_node = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
+ if (!dsi1_node)
+ return dev_err_probe(dev, -ENODEV,
+ "Failed to get remote node for second DSI\n");
+
+ dsi1_host = of_find_mipi_dsi_host_by_node(dsi1_node);
+ of_node_put(dsi1_node);
+ if (!dsi1_host)
+ return dev_err_probe(dev, -EPROBE_DEFER,
+ "Failed to find second DSI host\n");
+
+ /* Copy current DSI info, do not provide OF node since no driver needs to be attached */
+ strscpy(info.type, dsi->name);
+ info.channel = dsi->channel;
+
+ /* Register the second DSI device */
+ ctx->dsi[1] = devm_mipi_dsi_device_register_full(dev, dsi1_host, &info);
+ if (IS_ERR(ctx->dsi[1]))
+ return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
+ "Failed to register second DSI device\n");
+
+ ctx->dsi[0] = dsi;
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ /* Get panel orientation */
+ ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
+ if (ret < 0 && ret != -ENODEV)
+ return dev_err_probe(dev, ret,
+ "Failed to get panel orientation\n");
+
+ ctx->panel.prepare_prev_first = true;
+
+ ret = drm_panel_of_backlight(&ctx->panel);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get backlight\n");
+
+ ret = devm_drm_panel_add(dev, &ctx->panel);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add panel\n");
+
+ /* Configure and attach both DSI devices */
+ for (i = 0; i < ARRAY_SIZE(ctx->dsi); i++) {
+ ctx->dsi[i]->lanes = ctx->desc->lanes;
+ ctx->dsi[i]->format = ctx->desc->format;
+ ctx->dsi[i]->mode_flags = ctx->desc->mode_flags;
+
+ ret = devm_mipi_dsi_attach(dev, ctx->dsi[i]);
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "Failed to attach DSI device %d\n", i);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id renesas_r63419_of_match[] = {
+ {
+ .compatible = "ayaneo,wt0600-2k",
+ .data = &wt0600_desc,
+ },
+ {
+ .compatible = "ayaneo,wt0630-2k",
+ .data = &wt0630_desc,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, renesas_r63419_of_match);
+
+static struct mipi_dsi_driver renesas_r63419_driver = {
+ .probe = renesas_r63419_probe,
+ .driver = {
+ .name = "panel-renesas-r63419",
+ .of_match_table = renesas_r63419_of_match,
+ },
+};
+module_mipi_dsi_driver(renesas_r63419_driver);
+
+MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
+MODULE_DESCRIPTION("DRM driver for Renesas R63419 based dual-DSI video mode panels");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v8 1/2] dt-bindings: display: panel: document the Renesas R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, Conor Dooley
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org>
Document the Renesas R63419 based dual-DSI video mode Display Panels found
in the Ayaneo gaming handled devices.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../bindings/display/panel/renesas,r63419.yaml | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml
new file mode 100644
index 000000000000..adfdd2c300a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/renesas,r63419.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R63419 based dual-DSI video mode Display Panel
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ The Renesas R63419 is a generic DDIC used to control dual-DSI LCD panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ayaneo,wt0600-2k
+ - ayaneo,wt0630-2k
+ - const: renesas,r63419
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+ vsp-supply: true
+ vsn-supply: true
+ vci-supply: true
+
+ backlight: true
+ reset-gpios: true
+ rotation: true
+ ports: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+ - vsp-supply
+ - vsn-supply
+ - vci-supply
+ - backlight
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "ayaneo,wt0600-2k", "renesas,r63419";
+ reg = <0>;
+
+ reset-gpios = <&gpio 176 GPIO_ACTIVE_LOW>;
+
+ vdd-supply = <&vdd_3v0_lcd>;
+ vddio-supply = <&vdd_1v8_io>;
+ vsn-supply = <&vdd_5v0_neg>;
+ vsp-supply = <&vdd_5v0_pos>;
+ vci-supply = <&vdd_3v0_vci>;
+
+ backlight = <&backlight>;
+
+ rotation = <90>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ panel_in0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel_in1: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v8 0/2] drm: panel: support the R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, Conor Dooley,
KancyJoe
Add support for the Renesas 63419 based dual-DSI video mode
Display Panels found in the Ayaneo gaming handled devices.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v8:
- Use mipi_dsi_dual instead of helper
- Revert to recommended prepare sequence from DDIC spec
- Disable VCC after gpio up
- Remove drm_connector_set_panel_orientation
- Use 2 params strscpy and make sure mipi_dsi_device_info is cleared
- Link to v7: https://patch.msgid.link/20260605-topic-sm8650-ayaneo-pocket-s2-r63419-v7-0-b84b6da84293@linaro.org
Changes in v7:
- Reverse "on" command order
- Rebase on drm-misc-next
- Link to v6: https://patch.msgid.link/20260522-topic-sm8650-ayaneo-pocket-s2-r63419-v6-0-16edddda9951@linaro.org
Changes in v6:
- Get new dt bindings review from Conor
- Properly init dsi_ctx
- Link to v5: https://patch.msgid.link/20260521-topic-sm8650-ayaneo-pocket-s2-r63419-v5-0-dd5700299390@linaro.org
Changes in v5:
- Import panel-common-dual.yaml in bindings
- Set reg as required
- fix bindings example typo
- Add helper to switch link in order to use single dsi_ctx to properly handle errors
- Disable vdd supplies if vcc supplied fail to enable
- Precise the power off sequence is recommended by the vendor spec
- Drop passing of node to second dsi to avoid re-probing the driver twice
- Link to v4: https://patch.msgid.link/20260519-topic-sm8650-ayaneo-pocket-s2-r63419-v4-0-b8929af5e951@linaro.org
Changes in v4:
- Moved height/width in the drm_mode, duplicated modes to use drm_connector_helper_get_modes_fixed
- Create dsi_info on the stack with proper OF node and name passed
- Switched to devm_drm_panel_add/devm_mipi_dsi_attach & dropped remove
- Link to v3: https://patch.msgid.link/20260504-topic-sm8650-ayaneo-pocket-s2-r63419-v3-0-9f61cf24aebf@linaro.org
Changes in v3:
- Added DDIC compatible as fallback
- Added rotation in bindings example
- Fixed bindings subject
- Added second MODULE_AUTHOR entry and re-ordered signed-off-by order
- Link to v2: https://patch.msgid.link/20260430-topic-sm8650-ayaneo-pocket-s2-r63419-v2-0-91ac10453d0c@linaro.org
Changes in v2:
- Add missing rotation property into bindings
- Fix commit message & subject typos
- Link to v1: https://patch.msgid.link/20260428-topic-sm8650-ayaneo-pocket-s2-r63419-v1-0-981eb5ab5a51@linaro.org
---
KancyJoe (1):
drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
Neil Armstrong (1):
dt-bindings: display: panel: document the Renesas R63419 based dual-DSI video mode Display Panels
.../bindings/display/panel/renesas,r63419.yaml | 98 ++++++
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-renesas-r63419.c | 350 +++++++++++++++++++++
4 files changed, 461 insertions(+)
---
base-commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7
change-id: 20260428-topic-sm8650-ayaneo-pocket-s2-r63419-e72467e2db0f
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: display: tegra: Add channel/syncpoint range properties
From: Mikko Perttunen @ 2026-06-25 9:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260625-poetic-heavy-vulture-7baabb@quoll>
On Thursday, June 25, 2026 5:36 PM Krzysztof Kozlowski wrote:
> On Mon, Jun 22, 2026 at 05:22:51PM +0900, Mikko Perttunen wrote:
> > Channels and syncpoints available may be limited when other system
>
> What are channels and syncpoints?
Very host1x-specific hardware resources. Somewhat close to GPU channels
and semaphores / fences if you're familiar with those.
>
> > components are using them. Add properties nvidia,channels and
> > nvidia,syncpoints to limit the range of usable channels and/or
> > syncpoints.
>
> Why isn't this deducible from the compatible?
When Host1x is partitioned, the hypervisor (or other software entity
with access to the non-vm host1x register regions) can configure which
channels and syncpoints are available to each partition arbitrarily.
How that partitioning was done is not discoverable through hardware
directly, so we need to pass that information through device tree.
>
> Also, nvidia,channels is too broad/generic. This is not ADC, right? And
> channels is a common term in IIO. And in few other cases.
It's not ADC. Yes, it's a common term in a lot of contexts. I can call
it nvidia,host1x-channels if you prefer but that seems a bit redundant
given the context.
>
> Best regards,
> Krzysztof
>
>
Thank you
Mikko
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: tegra: Make non-vm registers optional
From: Mikko Perttunen @ 2026-06-25 9:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260625-hospitable-antelope-of-diversity-f3456d@quoll>
On Thursday, June 25, 2026 5:34 PM Krzysztof Kozlowski wrote:
> On Mon, Jun 22, 2026 at 05:22:50PM +0900, Mikko Perttunen wrote:
> > Host1x can be used without accessing the hypervisor or common
> > registers. Adjust the bindings to make them optional.
>
> You still have these registers in the hardware, so it is not optional,
> not flexible. IOW, DTS represents the view of real hardware for the
> software, and that hardware still has this address space regardless if
> OS should use it or not.
>
> Otherwise you need to provide better background here.
>
> Best regards,
> Krzysztof
>
>
The intent is that the vm-only version is used in situations where the
other register regions are not available to software. Typically that
means running as a virtual machine, and the hypervisor owns the non-vm
register regions and doesn't pass them to the guest.
Since the guest runs under the hypervisor, its view of 'real hardware'
is what the hypervisor is exposing to it -- in this case with just the
"vm" register region.
I'll add further explanation along above lines to the commit message
if you're OK with it.
Thank you
Mikko
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-06-25 9:25 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <c90884fd-a354-45f3-bbfa-77c58d8d3b1b@oss.qualcomm.com>
On 6/18/2026 1:49 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
[...]
>> +
>> + if (pdc->version < PDC_VERSION_3_0)
>> + return;
>
> These version checks should be unnecessary now, given the function pointer
> is only assigned for hamoa
>
> Konrad
Yes, they are now unnecessary. I will remove in v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-06-25 9:24 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <e513bc4c-ddeb-43b3-aa05-59051136ba4e@oss.qualcomm.com>
On 6/18/2026 1:48 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
[...]
>> + type = IRQ_TYPE_LEVEL_HIGH;
>
>
> Please carry your comment from the previous revision:
>
> /*
> * PDC forwards GPIOs as level high to GIC in secondary
> * mode. Update the type and clear any previously latched
> * phantom interrupt at PDC.
> */
>
I will add back this comment in v4.
[...]
>> + if (pdc->mode == PDC_PASS_THROUGH_MODE || !pdc_pin_is_gpio(hwirq)) {
>> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
>> + &qcom_pdc_gic_chip,
>> + NULL);
>> + if (ret)
>> + return ret;
>>
>> - region = get_pin_region(hwirq);
>> - if (!region)
>> - return irq_domain_disconnect_hierarchy(domain->parent, virq);
>> + if (type & IRQ_TYPE_EDGE_BOTH)
>> + type = IRQ_TYPE_EDGE_RISING;
>>
>> - if (type & IRQ_TYPE_EDGE_BOTH)
>> - type = IRQ_TYPE_EDGE_RISING;
>> + if (type & IRQ_TYPE_LEVEL_MASK)
>> + type = IRQ_TYPE_LEVEL_HIGH;
>> + } else {
>> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
>> + &qcom_pdc_gic_secondary_chip,
>> + NULL);
>> + if (ret)
>> + return ret;
>>
>> - if (type & IRQ_TYPE_LEVEL_MASK)
>> + /* Secondary mode converts all interrupts to LEVEL HIGH type */
>> type = IRQ_TYPE_LEVEL_HIGH;
>> + }
>
> nit: (pdc->mode == PDC_SECONDARY_MODE && pdc_pin_is_gpio(hwirq))
> could be the primary case to better communicate intent
>
> Konrad
Made primary case as (pdc->mode == PDC_SECONDARY_MODE && pdc_pin_is_gpio(hwirq) in v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 4/8] irqchip/qcom-pdc: Differentiate between direct SPI and GPIO as SPI
From: Maulik Shah (mkshah) @ 2026-06-25 9:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <2978f55b-0b5c-4720-98ba-e14ef46b1169@oss.qualcomm.com>
On 6/18/2026 1:32 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> Before commit 4dc70713dc24 ("irqchip/qcom-pdc: Kill non-wakeup irqdomain")
>> there are separate domains for direct SPIs and GPIO used as SPIs. Separate
>> domains can be useful in case irqchip want to differentiate both of them.
>> Since commit unified both the domains there is no way to differentiate.
>>
>> In preparation to add the second level interrupt controller support where
>> GPIO interrupts get latched at PDC (but not direct SPIs) there is a need to
>> differentiate between SPIs and GPIOs as SPIs. Reverting above commit do not
>> seem a good option either which leads to waste of resources.
>>
>> PDC HW have the IRQ_PARAM register telling number of direct SPIs and number
>> of GPIOs as SPIs. Further PDC allocates direct SPIs at the beginning and
>> all GPIOs as SPIs are allocated at the end. This information can be used in
>> driver to differentiate them.
>>
>> Add the support to read this register and keep this information in
>> struct pdc_desc. Later change utilizes same.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>
> [...]
>
>> + irq_param = pdc_reg_read(pdc->regs->irq_param_reg, 0);
>> + pdc->num_spis = FIELD_GET(GENMASK(7, 0), irq_param);
>> + pdc->num_gpios = FIELD_GET(GENMASK(15, 8), irq_param);
>
> num_gpios is not used in this series, please either drop it or
> use it to limit the index in the following patches
>
> Konrad
I will remove unused num_gpios from v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 2/8] irqchip/qcom-pdc: Move all statics to struct pdc_desc
From: Maulik Shah (mkshah) @ 2026-06-25 9:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <8754de51-bfbe-42f2-84bf-36cc000afa3f@oss.qualcomm.com>
On 6/17/2026 6:56 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> There are multiple statics used. Move all to struct pdc_desc to better
>> align with versioning support. Document them.
>>
>> No functional impact.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>
> [...]
>
>> static void pdc_enable_intr(struct irq_data *d, bool on)
>> {
>> - unsigned long flags;
>> + guard(raw_spinlock)(&pdc->lock);
>
> tglx suggested to use guard(irq) around "the other callsite"..
> which I'm not sure where it'd be - maybe around __pdc_enable_intr()
> in pdc_setup_pin_mapping()?
>
> Otherwise this patch looks good to me
>
> Konrad
All callers will be from irqchip except pdc_setup_pin_mapping() which was
invoking lock-less because at that time irqchip is not setup and as such
can stay lock less.
Once the patch-3 of this series is applied pdc_setup_pin_mapping() too
will use the lock as it makes direct use of pdc->enable_intr() where the new lock
is kept (only for v2.7 version specific enable function).
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 1/8] irqchip/qcom-pdc: restructure version support
From: Maulik Shah (mkshah) @ 2026-06-25 9:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <0fcfe7c3-ff54-4a72-9529-8f55d77814ef@oss.qualcomm.com>
On 6/17/2026 6:42 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
>> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
>> as below on various SoCs.
>
> [...]
>
>> - ret = pdc_setup_pin_mapping(node);
>> + ret = pdc_setup_pin_mapping(dev, node);
>
> dev is enough, we can get the np in that function from dev->of_node
>
> otherwise:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
Sure, Will update in v4 for getting np from dev->of_node.
Thanks,
Maulik
^ permalink raw reply
* [PATCH 2/2] dt-bindings: usb: generic-ohci: Document clock-names in top-level
From: Krzysztof Kozlowski @ 2026-06-25 9:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-usb, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260625091744.109467-3-krzysztof.kozlowski@oss.qualcomm.com>
Convention is to always have properties defined in top-level part of the
binding and then customized (narrowed per variant) in "if:then:" blocks.
The clock-names were mentioned only in such "if:then:" block for
atmel,at91rm9200-ohci, thus add the top-level part and disallow usage of
clock-names for other devices. This has no practical impact as
clock-names are not used by other variants, except in
hisilicon/hi3798cv200.dtsi, but that SoC has it undocumented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/usb/generic-ohci.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index d42f448fa204..322808aaa283 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -83,6 +83,10 @@ properties:
- if a USB DRD channel: first clock should be host and second
one should be peripheral
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
power-domains:
maxItems: 1
@@ -182,6 +186,7 @@ allOf:
else:
properties:
+ clock-names: false
atmel,vbus-gpio: false
atmel,oc-gpio: false
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: usb: generic-ehci: Document clock-names in top-level
From: Krzysztof Kozlowski @ 2026-06-25 9:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-usb, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Convention is to always have properties defined in top-level part of the
binding and then customized (narrowed per variant) in "if:then:" blocks.
The clock-names were mentioned only in such "if:then:" block for
atmel,at91sam9g45-ehci, thus add the top-level part and disallow usage
of clock-names for other devices. This has no practical impact as
clock-names are not used by other variants, except in
hisilicon/hi3798cv200.dtsi, but that SoC has it undocumented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/usb/generic-ehci.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 55a5aa7d7a54..ae9fb70d0212 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -98,6 +98,10 @@ properties:
- if a USB DRD channel: first clock should be host and second
one should be peripheral
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
power-domains:
maxItems: 1
@@ -186,6 +190,9 @@ allOf:
required:
- clocks
- clock-names
+ else:
+ properties:
+ clock-names: false
unevaluatedProperties: false
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_id
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Viresh Kumar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, soc, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
"usbh0_id" and "usbh1_id" properties were never documented and never
used by Linux drivers, thus should be safe to drop to fix dtbs_check
warnings like:
st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected)
st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/boot/dts/st/spear13xx.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 0bb88f2d4ef5..cf98160ba268 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -178,7 +178,6 @@ usb@e4800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe4800000 0x1000>;
interrupts = <0 64 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -186,7 +185,6 @@ usb@e5800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe5800000 0x1000>;
interrupts = <0 66 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
@@ -194,7 +192,6 @@ usb@e4000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe4000000 0x1000>;
interrupts = <0 65 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -202,7 +199,6 @@ usb@e5000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe5000000 0x1000>;
interrupts = <0 67 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: hisilicon: hi3798cv200: Drop unused clock-names and reset-names
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Neither Linux drivers nor DT bindings ever described or used clock-names
and reset-names for this SoC. The binding allows clock-names only for
atmel,at91sam9g45-ehci and atmel,at91rm9200-ohci, but not for HiSilicon.
reset-names were never allowed.
Drop them from DTS to fix dtbs_check warnings:
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): False schema does not allow ['bus', 'clk12', 'clk48']
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): Unevaluated properties are not allowed ('reset-names' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 2f4ad5da5e33..e5010c9d4c39 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -633,9 +633,7 @@ ohci: usb@9880000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_12M_CLK>,
<&crg HISTB_USB2_48M_CLK>;
- clock-names = "bus", "clk12", "clk48";
resets = <&crg 0xb8 12>;
- reset-names = "bus";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
@@ -648,11 +646,9 @@ ehci: usb@9890000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_PHY_CLK>,
<&crg HISTB_USB2_UTMI_CLK>;
- clock-names = "bus", "phy", "utmi";
resets = <&crg 0xb8 12>,
<&crg 0xb8 16>,
<&crg 0xb8 13>;
- reset-names = "bus", "phy", "utmi";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/3] arm64: dts: tegra: CPU and cache node updates
From: Thierry Reding @ 2026-06-25 9:10 UTC (permalink / raw)
To: jonathanh, robh, krzk+dt, conor+dt, devicetree, linux-tegra,
linux-kernel, Sumit Gupta
Cc: bbasu
In-Reply-To: <20260121104536.3214101-1-sumitg@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
On Wed, 21 Jan 2026 16:15:33 +0530, Sumit Gupta wrote:
> - Fixes for Tegra234/264 device tree CPU compatible string.
> - Populate CPU and L2 cache nodes for Tegra264.
>
> Sumit Gupta (3):
> arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
> arm64: dts: tegra264: Fix CPU1 node unit-address
> arm64: dts: tegra264: Populate CPU and L2 cache nodes
>
> [...]
Applied, thanks!
[1/3] arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
commit: 2e1f4664c1be73065070d8b380a3c7440f98f6a4
[2/3] arm64: dts: tegra264: Fix CPU1 node unit-address
commit: c003ea35f934a9e6672ea02778f07f08cb6f13ad
[3/3] arm64: dts: tegra264: Populate CPU and L2 cache nodes
commit: 1199de78b2ca6439e83a565fe39eb4fed67d70b8
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-25 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <b9ca9e36-a851-4a98-a739-ca99dd534d6d@kernel.org>
Hi Krzysztof,
> > It's a Virtual UART. Internally, it's two FIFOs accessible via
> > 8250-compatible register sets on both ends.
>
> I do not know what is Virtual UART...
Yes the name of ASPEED is a bit weird, it means that it is not a real
UART. It is two 8250-compatible register sets, and the data path is
handled by two hardware FIFOs (one per direction).
> > There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
> > are bridged over the PCI bus.
> > So, from the host, you can access the 8250 register set on the PCI bus.
>
> You mean these appear (or are) as PCI devices?
Yes but not as a UART devices.
The two VUART are accessible under the same PCIe BMC device, at the
VUART addresses configured on the BMC. They are accessible on the BAR1
of the PCIe BMC device.
There is a 2 bit left shift between the addresses of the registers on
the BMC LPC bus and the addresses accessible over the PCI device.
0x3F8 on the BMC is accessible at BAR1 0xFE0 over the PCI device.
The PCIe BMC Device is one PCI device where you can access several
peripherals. It's not one PCI device per VUART.
For example, you can also enable the KCS channel 4 and it will be also
accessible via the BAR1 of the PCI BMC device. KCS is a protocol used
for IPMI.
Only these two peripherals can be accessed over the PCI BMC device and
they need to be enabled.
The host cannot access everything on the LPC bus of the BMC.
Best regards,
Grégoire
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox