* 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
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Mukesh Savaliya @ 2026-06-25 9:06 UTC (permalink / raw)
To: Konrad Dybcio, Pengyu Luo, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, linux-arm-msm, linux-spi, devicetree,
linux-kernel
In-Reply-To: <3451facc-4a2e-43bf-ba13-944488bce437@oss.qualcomm.com>
Hi Konrad, sorry for late response.
On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>
>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>> also support GSI mode, which is highly preferred for certain
>>>> peripherals like SPI touchscreens to improve performance.
>>>>
>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>> the controller into GSI mode during initialization.
>>>
>>> Ideally, this should be decided by the SPI controller based on the
>>> requirements. Another option would be to prefer GSI for all transfers if
>>> it is available, ignoring the FIFO even if it is not disabled.
>>>
>>
>> I have read reviews. Can we check if the compatible
>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>> presented, then we enable GSI mode.
>
>
> This hunk is very odd:
>
> /*
> * in case of failure to get gpi dma channel, we can still do the
> * FIFO mode, so fallthrough
> */
> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>
> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
> you have any insights?
>
GSI mode is preferable but if for some reason it fails, we try to
continue with the FIFO mode. Just fallback mechanism.
> Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-25 8:56 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <a13fb65c-726b-4c99-b741-29040c4564d0@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:
[...]
> > > However, I believe it is acceptable to allocate an ATID for the itNoC device
> > > and the issue can be fixed with this way.
> >
> > I think so.
>
> Hi Suzuki/Leo
>
> Which solution do you prefer to address the issue?
I will leave this to Suzuki.
> The interconnect traceNoC platform driver is intended for the itnoc device,
> implying that no TPDM devices are connected to it. So, if I modify it to
> allocate an ATID, I think it would be better to rename the “itnoc” node
> accordingly? Or it's ok to leave it as-is?
>
> BTW, the traceNoC device definitely is an AMBA device with CID/PID
> registers.
Just to share a bit thoughts on the driver's design.
I think it would be better to keep the probe function generic. The AMBA
probe should not be specific to TraceNoC, and the platform probe should
not be only dedicated to the interconnect TraceNoC. The probe function
should simply handle a device that appears on either the AMBA bus or the
platform bus.
So the question is: if allocat an ATID for all traceNoC devices, do you
still need to distinguish TraceNoC types? If no, then the code can be
unified.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Konrad Dybcio @ 2026-06-25 8:47 UTC (permalink / raw)
To: Bibek Kumar Patro, Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <aaf4daee-4886-4214-a761-80545d2565ee@oss.qualcomm.com>
On 6/19/26 12:54 PM, Bibek Kumar Patro wrote:
>
>
> On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
>> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
>>>> On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>>>>>
>>>>>
>>>>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>>>>> On some SoCs the SMMU registers require an active interconnect
>>>>>>> bandwidth vote to be accessible. While other clients typically
>>>>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>>>>> vote, causing intermittent register access failures.
>>>>>>>
>>>>>>> Add support for an optional interconnect path to the arm-smmu
>>>>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>>>>> is acquired from DT if present and ignored otherwise.
>>>>>>>
>>>>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>>>>> during probe and runtime resume, and released during runtime
>>>>>>> suspend and on error paths.
>>>>>>>
>>>>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>>>>> expected to have an active vote whenever the adreno_smmu block is
>>>>>>> powered on. In most common use cases, this requirement is implicitly
>>>>>>> satisfied because other GPU-related clients (for example, the GMU
>>>>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>>>>
>>>>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>>>>> vote is missing, it can lead to the observed failures. Because of the
>>>>>>> precise ordering involved, this scenario is difficult to reproduce
>>>>>>> consistently.
>>>>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>>>>
>>>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> @@ -53,6 +53,11 @@
>>>>>>> #define MSI_IOVA_BASE 0x8000000
>>>>>>> #define MSI_IOVA_LENGTH 0x100000
>>>>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>>>>
>>>>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>>>>
>>>>>
>>>>> Ideally, any non-zero value would be enough to keep the path active.
>>>>
>>>> This is true for Qualcomm devices. However, you are adding this to a
>>>> generic code.
>>>>
>>>>> Here 1 Would be enough to keep the path active, but might be too small to
>>>>> reliably keep the bus active.
>>>>> Other is UINT_MAX, which will reliably keep the bus active but might cause a
>>>>> power penalty.
>>>>>
>>>>> #define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
>>>>>
>>>>> seems to be suitable here to reliably keep the bus active by BCM
>>>>> for both Qualcomm and non-Qualcomm platforms (with some power penalty).
>>>>>
>>>>> LMK, if you feel otherwise.
>>>>
>>>> Shift it to the qcom instance or provide platform-specific values? (My
>>>> preference would be towards the first solution).
>>>>
>>>
>>>
>>> To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
>>>
>>> Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
>>
>> (you used decimal 1000)
>>
>
> It's my bad, i meant 1000 only
> (I'll check on the icc_bw calculation to get clarity on the values)
>
>>> can evaluate if this could be moved to a Qualcomm-specific
>>> implementation.
>>
>> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
>> the QC driver
>>
>
> Just curious, wouldn't this apply for all the arm-smmu users in addition to Qualcomm devices as i mentioned here [1].
> Vendor hook would make it Qualcomm specific.
You're proposing to use a Qualcomm-specific bandwidth value so that
fits
Konrad
>
> [1]: https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@oss.qualcomm.com/
>
> Thanks & regards,
> Bibek
>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH v4 13/13] arm64: dts: qcom: shikra: Add support for DISPCC/GPUCC nodes
From: Konrad Dybcio @ 2026-06-25 8:44 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Loic Poulain, Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260604-shikra-dispcc-gpucc-v4-13-8204f1029311@oss.qualcomm.com>
On 6/4/26 7:26 AM, Imran Shaik wrote:
> Add support for Display clock controller and GPU clock controller nodes
> on Qualcomm Shikra SoCs.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 41 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..1ccb0f1419aaa34d32f3c3eaabdb8727a497b501 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -3,6 +3,8 @@
> * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> +#include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
> +#include <dt-bindings/clock/qcom,qcm2290-gpucc.h>
> #include <dt-bindings/clock/qcom,rpmcc.h>
> #include <dt-bindings/clock/qcom,shikra-gcc.h>
> #include <dt-bindings/interconnect/qcom,icc.h>
> @@ -640,6 +642,45 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> };
> };
>
> + gpucc: clock-controller@5990000 {
> + compatible = "qcom,shikra-gpucc";
> + reg = <0x0 0x05990000 0x0 0x9000>;
> + clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
> + <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
> + power-domains = <&rpmpd RPMPD_VDDCX>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + dispcc: clock-controller@5f00000 {
> + compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
> + reg = <0x0 0x05f00000 0x0 0x20000>;
> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&rpmcc RPM_SMD_XO_A_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
> + <0>,
> + <0>,
> + <0>,
> + <0>,
> + <&sleep_clk>;
> + clock-names = "bi_tcxo",
> + "bi_tcxo_ao",
Is the AO clock going to be any useful? Taniya recently dropped it
from some other submission after assessing it wasn't
> + "gcc_disp_gpll0_clk_src",
> + "gcc_disp_gpll0_div_clk_src",
> + "dsi0_phy_pll_out_byteclk",
> + "dsi0_phy_pll_out_dsiclk",
> + "dsi1_phy_pll_out_byteclk",
> + "dsi1_phy_pll_out_dsiclk",
> + "sleep_clk";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
DISP_CC also needs to source power from somewhere!
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO
From: Krzysztof Kozlowski @ 2026-06-25 8:44 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Raffaele Tranquillini, Yassine Oudjana
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260625-topic-ti_drv2604_dtwarn-v1-1-76e91fcafbe8@oss.qualcomm.com>
On 25/06/2026 10:42, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Update the 'enable-gpio' property name to 'enable-gpios' to conform to
> the bindings for the TI DRV2604 haptics module. While at it, use the
> GPIO_ACTIVE_HIGH define instead of the raw literal.
>
> Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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