* [PATCH v2 1/2] dt-bindings: display: panel: Add compatibles for Zhunyi Z40046
From: Luca Leonardo Scorcia @ 2026-04-17 10:46 UTC (permalink / raw)
To: dri-devel
Cc: Luca Leonardo Scorcia, Jagan Teki, Neil Armstrong, Jessica Zhang,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
devicetree, linux-kernel
In-Reply-To: <20260417104740.259689-1-l.scorcia@gmail.com>
The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
x04g, apparently in two different variants.
The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
JD9365DA-H3, it just uses a different initialization sequence.
Since this is the first supported device from this vendor, document its
name to the vendor-prefixes.yaml file as well.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 2 ++
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
index e39efb44ed42..158388a284d9 100644
--- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
+++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
@@ -24,6 +24,8 @@ properties:
- radxa,display-10hd-ad001
- radxa,display-8hd-ad002
- taiguanck,xti05101-01a
+ - zhunyikeji,z40046-ctc
+ - zhunyikeji,z40046-boe
- const: jadard,jd9365da-h3
reg:
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6339988e3805..debaec59e9a0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1923,6 +1923,8 @@ patternProperties:
description: Zealz
"^zeitec,.*":
description: ZEITEC Semiconductor Co., LTD.
+ "^zhunyikeji,.*":
+ description: Shenzhen Zhunyi Technology Co., Ltd.
"^zidoo,.*":
description: Shenzhen Zidoo Technology Co., Ltd.
"^zii,.*":
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] drm/panel: jd9365da: Support for Zhunyi Z40046 panels
From: Luca Leonardo Scorcia @ 2026-04-17 10:46 UTC (permalink / raw)
To: dri-devel
Cc: Luca Leonardo Scorcia, Jagan Teki, Neil Armstrong, Jessica Zhang,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
devicetree, linux-kernel
In-Reply-To: <20260417104740.259689-1-l.scorcia@gmail.com>
The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
x04g, apparently in two different variants.
The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
JD9365DA-H3, it just uses different initialization sequences.
The two initialization sequences for the panel have been extracted from
Android original firmware for the Xiaomi Smart Clock.
Variant -ctc uses a CTC LCD panel and has been tested on device.
Variant -boe uses a BOE LCD panel and has not been tested.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../gpu/drm/panel/panel-jadard-jd9365da-h3.c | 313 ++++++++++++++++++
1 file changed, 313 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
index c33c611e03c0..7da064567248 100644
--- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
+++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
@@ -46,11 +46,22 @@ struct jadard {
struct gpio_desc *reset;
};
+#define JD9161Z_DCS_SWITCH_PAGE 0xde
+
+#define jd9161z_switch_page(dsi_ctx, page) \
+ mipi_dsi_dcs_write_seq_multi(dsi_ctx, JD9161Z_DCS_SWITCH_PAGE, (page))
+
#define JD9365DA_DCS_SWITCH_PAGE 0xe0
#define jd9365da_switch_page(dsi_ctx, page) \
mipi_dsi_dcs_write_seq_multi(dsi_ctx, JD9365DA_DCS_SWITCH_PAGE, (page))
+static void jd9161z_enable_standard_cmds(struct mipi_dsi_multi_context *dsi_ctx)
+{
+ // Enable access to DCS and internal commands
+ mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xdf, 0x91, 0x62, 0xf3);
+}
+
static void jadard_enable_standard_cmds(struct mipi_dsi_multi_context *dsi_ctx)
{
mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xe1, 0x93);
@@ -1606,6 +1617,300 @@ static const struct jadard_panel_desc taiguan_xti05101_01a_desc = {
.enter_sleep_to_reset_down_delay_ms = 100,
};
+// Sequence retrieved from Xiaomi Mi Smart Clock x04g kernel in boot.bin
+static int zhunyi_z40046_init_cmds_ctc(struct jadard *jadard_data)
+{
+ struct mipi_dsi_multi_context dsi_ctx = { .dsi = jadard_data->dsi };
+
+ // Init configuration sequence
+ jd9161z_switch_page(&dsi_ctx, 0x00);
+ jd9161z_enable_standard_cmds(&dsi_ctx);
+
+ // GAMMA_SET (pos/neg voltage of gamma power)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xb7,
+ 0x10, 0x04, 0x86, 0x00, 0x1b, 0x35);
+
+ // DCDC_SEL (power mode and charge pump settings)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xbb,
+ 0x69, 0x0b, 0x30, 0xb2, 0xb2, 0xc0, 0xe0, 0x20,
+ 0xf0, 0x50, 0x60);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // VDDD_CTRL (control logic voltage setting)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xbc,
+ 0x73, 0x14);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // SETRGBCYC (display waveform cycle of RGB mode)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc3,
+ 0x74, 0x04, 0x08, 0x0e, 0x00, 0x0e, 0x0c, 0x08,
+ 0x0e, 0x00, 0x0e, 0x82, 0x0a, 0x82);
+
+ // SET_TCON (timing control setting)
+ // param[0][5:4] + param[1]: number of panel lines / 2
+ // 400 = 01 1001 0000 -> 0x10, 0x90
+ // param[2]: scan line time width
+ // param[3]: vfp: 14
+ // param[4]: vs + vbp - 1: 11
+ // param[5]: hbp: 4
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc4,
+ 0x10, 0x90, 0x92, 0x0e, 0x0b, 0x04);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // SET_R_GAMMA (set red gamma output voltage)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc8,
+ 0x7e, 0x76, 0x68, 0x57, 0x4c, 0x39, 0x3a, 0x23,
+ 0x3d, 0x3d, 0x40, 0x61, 0x54, 0x64, 0x5d, 0x62,
+ 0x5a, 0x50, 0x32, 0x7e, 0x76, 0x68, 0x57, 0x4c,
+ 0x39, 0x3a, 0x23, 0x3d, 0x3d, 0x40, 0x61, 0x54,
+ 0x64, 0x5d, 0x62, 0x5a, 0x50, 0x32);
+
+ // SET_GIP_L (CGOUTx_L signal mapping, gs_panel = 0)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd0,
+ 0x1f, 0x0a, 0x08, 0x06, 0x04, 0x1f, 0x00, 0x1f,
+ 0x17, 0x1f, 0x18, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SET_GIP_R (CGOUTx_R signal mapping, gs_panel = 0)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd1,
+ 0x1f, 0x0b, 0x09, 0x07, 0x05, 0x1f, 0x01, 0x1f,
+ 0x17, 0x1f, 0x18, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SETGIP1 (GIP signal timing 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd4,
+ 0x10, 0x00, 0x00, 0x03, 0x60, 0x05, 0x10, 0x00,
+ 0x02, 0x06, 0x68, 0x00, 0x6c, 0x00, 0x00, 0x00,
+ 0x00, 0x06, 0x78, 0x71, 0x07, 0x06, 0x68, 0x0c,
+ 0x25, 0x00, 0x63, 0x03, 0x00);
+
+ // SETGIP2 (GIP signal timing 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd5,
+ 0x20, 0x10, 0x8c, 0x18, 0x00, 0x80, 0x00, 0x08,
+ 0x00, 0x00, 0x06, 0x60, 0x00, 0x81, 0x70, 0x02,
+ 0x30, 0x01, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00,
+ 0x03, 0x60, 0x83, 0x90, 0x00, 0x00, 0x03, 0x4f,
+ 0x03, 0x00, 0x1f, 0x3f, 0x00, 0x00, 0x00, 0x00);
+
+ jd9161z_switch_page(&dsi_ctx, 0x04);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // Unknown command
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xb0,
+ 0x24, 0x01);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ jd9161z_switch_page(&dsi_ctx, 0x02);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // SETRGBCYC2 (RGB IF source switch control timing)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc1,
+ 0x71);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ // Unknown command
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc2,
+ 0x00, 0x18, 0x08, 0x1e, 0x25, 0x7c, 0xc7);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ jd9161z_switch_page(&dsi_ctx, 0x00);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ mipi_dsi_dcs_set_tear_on_multi(&dsi_ctx, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+
+ mipi_dsi_msleep(&dsi_ctx, 1);
+
+ mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
+
+ mipi_dsi_msleep(&dsi_ctx, 120);
+
+ mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
+
+ mipi_dsi_msleep(&dsi_ctx, 5);
+
+ return dsi_ctx.accum_err;
+};
+
+static const struct jadard_panel_desc zhunyi_z40046_ctc_desc = {
+ .mode = {
+ .clock = (480 + 20 + 20 + 20) * (800 + 14 + 4 + 8) * 60 / 1000,
+
+ .hdisplay = 480,
+ .hsync_start = 480 + 20,
+ .hsync_end = 480 + 20 + 20,
+ .htotal = 480 + 20 + 20 + 20,
+
+ .vdisplay = 800,
+ .vsync_start = 800 + 14,
+ .vsync_end = 800 + 14 + 4,
+ .vtotal = 800 + 14 + 4 + 8,
+
+ .width_mm = 52,
+ .height_mm = 86,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ },
+ .lanes = 2,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .lp11_before_reset = true,
+ .reset_before_power_off_vcioo = true,
+ .vcioo_to_lp11_delay_ms = 5,
+ .lp11_to_reset_delay_ms = 10,
+ .backlight_off_to_display_off_delay_ms = 100,
+ .display_off_to_enter_sleep_delay_ms = 50,
+ .enter_sleep_to_reset_down_delay_ms = 100,
+ .init = zhunyi_z40046_init_cmds_ctc,
+};
+
+// Sequence retrieved from Xiaomi Mi Smart Clock x04g kernel in boot.bin
+static int zhunyi_z40046_init_cmds_boe(struct jadard *jadard_data)
+{
+ struct mipi_dsi_multi_context dsi_ctx = { .dsi = jadard_data->dsi };
+
+ // Init configuration sequence
+ jd9161z_switch_page(&dsi_ctx, 0x00);
+ jd9161z_enable_standard_cmds(&dsi_ctx);
+
+ // GAMMA_SET (pos/neg voltage of gamma power)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xb7,
+ 0x10, 0x08, 0x42, 0x00, 0x56, 0x42);
+
+ // DCDC_SEL (power mode and charge pump settings)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xbb,
+ 0x52, 0x0f, 0xb2, 0xb2, 0xb2, 0xc0, 0xd0, 0x50,
+ 0xf0, 0x40, 0x50);
+
+ // VDDD_CTRL (control logic voltage setting)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xbc,
+ 0x73, 0x14);
+
+ // SETRGBCYC (display waveform cycle of RGB mode)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc3,
+ 0x04, 0x07, 0x0b, 0x17, 0x00, 0x17, 0x04, 0x17,
+ 0x17, 0x00, 0x17, 0x82, 0x0b, 0x82);
+
+ // SET_TCON (timing control setting)
+ // param[0][5:4] + param[1]: number of panel lines / 2
+ // 400 = 01 1001 0000 -> 0x10, 0x90
+ // param[2]: scan line time width
+ // param[3]: vfp: 14
+ // param[4]: vs + vbp - 1: 11
+ // param[5]: hbp: 6
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc4,
+ 0x10, 0x90, 0x92, 0x0e, 0x06);
+
+ // SET_R_GAMMA (set red gamma output voltage)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc8,
+ 0x7f, 0x78, 0x69, 0x56, 0x47, 0x33, 0x34, 0x1e,
+ 0x3b, 0x3e, 0x43, 0x67, 0x5d, 0x6f, 0x68, 0x70,
+ 0x6a, 0x61, 0x3c, 0x7f, 0x78, 0x69, 0x56, 0x47,
+ 0x33, 0x34, 0x1e, 0x3b, 0x3e, 0x43, 0x67, 0x5d,
+ 0x6f, 0x68, 0x70, 0x6a, 0x61, 0x3c);
+
+ // SET_GIP_L (CGOUTx_L signal mapping, gs_panel = 0)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd0,
+ 0x1f, 0x1e, 0x07, 0x05, 0x01, 0x1f, 0x1f, 0x1f,
+ 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SET_GIP_R (CGOUTx_R signal mapping, gs_panel = 0)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd1,
+ 0x1f, 0x1e, 0x06, 0x04, 0x00, 0x1f, 0x1f, 0x1f,
+ 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SET_GIP_L_GS (CGOUTx_L signal mapping, gs_panel = 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd2,
+ 0x1f, 0x1f, 0x04, 0x06, 0x00, 0x1e, 0x1f, 0x1f,
+ 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SET_GIP_R_GS (CGOUTx_R signal mapping, gs_panel = 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd3,
+ 0x1f, 0x1f, 0x05, 0x07, 0x01, 0x1e, 0x1f, 0x1f,
+ 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f);
+
+ // SETGIP1 (GIP signal timing 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd4,
+ 0x30, 0x00, 0x00, 0x00, 0x00, 0x01, 0x10, 0x00,
+ 0x03, 0x03, 0x68, 0x03, 0x40, 0x05, 0x00, 0x00,
+ 0x00, 0xcc, 0x2d, 0x31, 0x02, 0x03, 0x68, 0x0c,
+ 0x25, 0x00, 0x63, 0x03, 0x00);
+
+ // SETGIP2 (GIP signal timing 1)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xd5,
+ 0x30, 0x08, 0x80, 0x18, 0x00, 0x00, 0x00, 0x18,
+ 0x00, 0x00, 0x06, 0x60, 0x00, 0x07, 0x50, 0x00,
+ 0x33, 0xc0, 0x00, 0x60, 0xc0, 0x00, 0x00, 0x00,
+ 0x03, 0x60, 0x06, 0x10, 0x00, 0x00, 0x0f, 0x4f,
+ 0x00, 0x10, 0x1f, 0x3f);
+
+ jd9161z_switch_page(&dsi_ctx, 0x02);
+
+ // SETRGBCYC2 (RGB IF source switch control timing)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc1,
+ 0x60);
+
+ // Unknown command
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xc2,
+ 0x00, 0x18, 0x08, 0x1e, 0x25, 0x7c, 0xc7);
+
+ jd9161z_switch_page(&dsi_ctx, 0x00);
+
+ // GAS_CTRL (GAS function control)
+ mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0xbe,
+ 0x4e);
+
+ mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
+
+ mipi_dsi_msleep(&dsi_ctx, 120);
+
+ mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
+
+ mipi_dsi_msleep(&dsi_ctx, 10);
+
+ return dsi_ctx.accum_err;
+};
+
+static const struct jadard_panel_desc zhunyi_z40046_boe_desc = {
+ .mode = {
+ .clock = (480 + 20 + 20 + 20) * (800 + 14 + 4 + 8) * 60 / 1000,
+
+ .hdisplay = 480,
+ .hsync_start = 480 + 20,
+ .hsync_end = 480 + 20 + 20,
+ .htotal = 480 + 20 + 20 + 20,
+
+ .vdisplay = 800,
+ .vsync_start = 800 + 14,
+ .vsync_end = 800 + 14 + 4,
+ .vtotal = 800 + 14 + 4 + 8,
+
+ .width_mm = 52,
+ .height_mm = 86,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ },
+ .lanes = 2,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .lp11_before_reset = true,
+ .reset_before_power_off_vcioo = true,
+ .vcioo_to_lp11_delay_ms = 5,
+ .lp11_to_reset_delay_ms = 10,
+ .backlight_off_to_display_off_delay_ms = 100,
+ .display_off_to_enter_sleep_delay_ms = 50,
+ .enter_sleep_to_reset_down_delay_ms = 100,
+ .init = zhunyi_z40046_init_cmds_boe,
+};
+
static int jadard_dsi_probe(struct mipi_dsi_device *dsi)
{
struct device *dev = &dsi->dev;
@@ -1707,6 +2012,14 @@ static const struct of_device_id jadard_of_match[] = {
.compatible = "taiguanck,xti05101-01a",
.data = &taiguan_xti05101_01a_desc
},
+ {
+ .compatible = "zhunyikeji,z40046-ctc",
+ .data = &zhunyi_z40046_ctc_desc
+ },
+ {
+ .compatible = "zhunyikeji,z40046-boe",
+ .data = &zhunyi_z40046_boe_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, jadard_of_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-17 10:50 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <aeH373a_xmr6fnAy@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 6889 bytes --]
Hello Andrea,
On Fri, Apr 17, 2026 at 11:05:51AM +0200, Andrea della Porta wrote:
> On 15:48 Thu 16 Apr , Uwe Kleine-König wrote:
> > one thing I forgot to ask: Is there a public reference manual covering
> > the hardware. If yes, please add a link at the top of the driver.
>
> Sort of, it's already reported in this driver top comment (Datasheet: tag).
> The PWM controller is part of the RP1 chipset and you can find its description
> under the PWM section. This is not a full-fledged datasheet but the registers
> for the controller are somewhow documented.
Ah, then I missed something different than I thought :-)
> > On Thu, Apr 16, 2026 at 12:30:43PM +0200, Andrea della Porta wrote:
> > > On 19:31 Fri 10 Apr , Uwe Kleine-König wrote:
> > > > I assume there is a glitch if I update two channels and the old
> > > > configuration of the first channel ends while I'm in the middle of
> > > > configuring the second?
> > >
> > > The configuration registers are per-channel but the update flag is global.
> > > I don't have details of the hw insights, my best guess is that anything that
> > > you set in the registers before updating the flag will take effect, so there
> > > should be no glitches.
> >
> > Would be great if you could test that. (Something along the lines of:
> > configure a very short period and wait a bit to be sure the short
> > configuration is active. Configure something with a long period and wait
> > shortly to be sure that the long period started, then change the duty,
> > toggle the update bit and modify a 2nd channel without toggling update
> > again. Then check the output of the 2nd channel after the first
> > channel's period ended.
>
> I stand corrected here: after some more investigation it seems that only the
> enable/disable (plus osme other not currently used registers) depends on the
> global update flag, while the period and duty per-channel registers are
> independtly updatable while they are latched on the end of (specific channel)
> period strobe.
> I'd say that this should avoid any cross-channel glitches since they are managed
> independently. Unfortunately I'm not able to test this with my current (and
> rather old) equipment, this would require at least an external trigger channel.
> Regarding the setup of a new value exactly during the strobe: I think this is
> quite hard to achieve.
To sum up: period and duty_cycle changes might result in glitches unless
the channel is disabled. This is ok, please just document it.
The purpose of the update flag then is only to start several channels in
sync? What happens if sync is asserted while a disabled channel didn't
complete the last period yet?
Maybe it's worth to test the following procedure for updating duty and
period:
disable channel
configure duty
configure period
enable
set update flag
Assumint disable is delayed until the end of the currently running
period, the effect of this procedure might be that no glitch happens if
the update flag is asserted before the currently running period ends and
the anormality is reduced to a longer inactive state if the updates are
not that lucky (in contrast to more severe glitches).
If you can configure a short and a long period that is distinguishable
"manually" with an LED I think this should be testable even without
further equipment.
> > > > > + if (ticks > U32_MAX)
> > > > > + ticks = U32_MAX;
> > > > > + wfhw->period_ticks = ticks;
> > > >
> > > > What happens if wf->period_length_ns > 0 but ticks == 0?
> > >
> > > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > > in this case.
> >
> > Sounds good. Are you able to verify that there is no +1 missing in the
> > calculation, e.g. using 1 as register value really gives you a period of
> > 1 tick and not 2?
>
> You are right. The scope reveals there's always one extra (low signal) tick at the
> end of each period.
So the hardware cannot do 100% relative duty, right? Please document
that.
> Let's say that teh user want 10 tick period, we have to use
> 9 instead to account for the extra tick at the end, so that the complete period
> contains that extra tick?
I would describe that a bit differently, but in general: yes.
The more straight forward description is that setting
RP1_PWM_RANGE(pwm->hwpwm) := x
results in a period of x + 1 ticks.
> This also means that if we ask for 100% duty cycle, the output waveform will
> have the high part of the signal lasting one tick less than expected.a I guess
> this is the accepted compromise.
I assume you considered something like:
RP1_PWM_RANGE(pwm->hwpwm) := 17
RP1_PWM_DUTY(pwm->hwpwm) := 18
to get a 100% relative duty?
If this doesn't work that means that this has to be formalized in the
callbacks. That is the fromhw function has to always report
duty_length_ns less than period_length_ns.
> OTOH, the minimum tick period would be 2 tick, less than that will otherwise
> degenerate in a disabled channel.
It's expected that in general for a period_length of 1 tick you can only
have 0% and 100% relative duty. IIUC for this hardware you cannot do the
100% case so there is only a single valid duty_length for period_length
= 1 tick.
I think it would be more complicated to consistently filter out
period_length = 1 tick in the driver than to just accept the conceptual
limitations. (Otherwise: What would you report in the fromhw callback if
period_length = 1 tick is configured in wfhw? Would you refuse to commit
that wfhw to hardware in .write_waveform()? The pwm core handles that
just fine and consumers have all the means to detect and prevent that if
they care enough.)
> > > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> > >
> > > Since this driver now exports a syscon, it's only builtin (=Y) so
> > > it cannot be unloaded.
> > > I've also avoided the .remove callback via .suppress_bind_attrs.
> >
> > Oh no, please work cleanly here and make the driver unbindable. This
> > yields better code quality and also helps during development and
> > debugging.
>
> I wish to, but the issue here is that this driver exports a syscon via
> of_syscon_register_regmap() which I think doesn't have the unregister
> counterpart. So the consumer will break in case we can unbind/unload
> the module and the syscon will leak.
> If you have any alternative I'll be glad to discuss.
My (not so well articulated) point is: Please be stringent about clock
handling to not bank up technical dept more than necessary and such that
the driver can be made unbindable if and when syscons grow
that feature. Optionally wail at the syscon guys :-)
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 0/2] Enable dual OV5640 cameras on i.MX8MQ EVK board
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
This series adds dual-camera support for the i.MX8MQ EVK board.
Patch 1 fixes the MIPI CSI clock configuration in the i.MX8MQ device tree.
The previous configuration violated a timing constraint defined in the
i.MX8MQ Reference Manual:
"The frequency of clk must be exactly equal to or greater than the RX
byte clock coming from the RX DPHY."
This mismatch could lead to unstable operation, observed as intermittent
capture failures. The updated clock ratios align with those used in NXP��s
downstream BSP and were verified to resolve the issue.
Patch 2 enables full MIPI CSI support and dual OV5640 camera operation on
the i.MX8MQ EVK. This includes enabling both CSI controllers and their
corresponding MIPI CSI-2 host interfaces, as well as adding two OV5640
sensor nodes on I2C1 and I2C2.
Note:
This series depends on patch [1] currently under review, as well as commit
6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly release reset").
[1] https://lore.kernel.org/imx/20260417080851.489303-1-robby.cai@nxp.com/
Robby Cai (2):
arm64: dts: imx8mq: Correct MIPI CSI clocks
arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 +-
2 files changed, 151 insertions(+), 2 deletions(-)
--
2.37.1
^ permalink raw reply
* [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
CSI capture may intermittently fail due to mismatched clock rates. The
previous configuration violated the timing requirement stated in the
i.MX8MQ Reference Manual:
"The frequency of clk must be exactly equal to or greater than the RX
byte clock coming from the RX DPHY."
Update the clock configuration to ensure that the CSI core clock rate is
equal to or greater than the incoming DPHY byte clock. The updated clock
ratios are consistent with those used in NXP's downstream BSP.
Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
Cc: stable@vger.kernel.org
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6a25e219832c..165716d08e64 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
<&clk IMX8MQ_CLK_CSI1_PHY_REF>,
<&clk IMX8MQ_CLK_CSI1_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
@@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
<&clk IMX8MQ_CLK_CSI2_PHY_REF>,
<&clk IMX8MQ_CLK_CSI2_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
--
2.37.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-04-17 11:02 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
Enable CSI1/CSI2 bridges and the MIPI-CSI host interfaces, and add
two OV5640 MIPI camera sensor nodes on I2C1 and I2C2.
The resulting camera pipelines are as follows:
- OV5640 on I2C2 -> MIPI CSI1 -> CSI1
- OV5640 on I2C1 -> MIPI CSI2 -> CSI2
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
Tested with following commands:
On CSI1:
media-ctl -d 0 -l "'ov5640 1-003c':0 -> 'imx8mq-mipi-csi2 30a70000.csi':0 [1]"
media-ctl -d 0 -V "'ov5640 1-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'imx8mq-mipi-csi2 30a70000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
On CSI2:
media-ctl -d 1 -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 30b60000.csi':0 [1]"
media-ctl -d 1 -V "'ov5640 0-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'imx8mq-mipi-csi2 30b60000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 1 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
1 file changed, 149 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index d48f901487d4..8bdfbfebfcc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include <dt-bindings/media/video-interfaces.h>
+
#include "imx8mq.dtsi"
/ {
@@ -50,6 +52,20 @@ reg_usdhc2_vmmc: regulator-vsd-3v3 {
enable-active-high;
};
+ reg_1v5: regulator-1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ reg_2v8: regulator-2v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_2V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
buck2_reg: regulator-buck2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_buck2>;
@@ -172,6 +188,14 @@ &A53_3 {
cpu-supply = <&buck2_reg>;
};
+&csi1 {
+ status = "okay";
+};
+
+&csi2 {
+ status = "okay";
+};
+
&ddrc {
operating-points-v2 = <&ddrc_opp_table>;
status = "okay";
@@ -330,12 +354,101 @@ vgen6_reg: vgen6 {
};
};
};
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera2_pwdn>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera2_ep: endpoint {
+ remote-endpoint = <&mipi_csi2_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera1_pwdn>, <&pinctrl_camera_rst>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera1_ep: endpoint {
+ remote-endpoint = <&mipi_csi1_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
};
&lcdif {
status = "okay";
};
+&mipi_csi1 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi1_in_ep: endpoint {
+ remote-endpoint = <&camera1_ep>;
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ };
+ };
+ };
+};
+
+&mipi_csi2 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in_ep: endpoint {
+ remote-endpoint = <&camera2_ep>;
+ data-lanes = <1 2>;
+ bus-type = <4>;
+ };
+ };
+ };
+};
+
&mipi_dsi {
#address-cells = <1>;
#size-cells = <0>;
@@ -532,12 +645,41 @@ &wdog1 {
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MCLK for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x59
+ >;
+ };
+
pinctrl_buck2: vddarmgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x19
>;
};
+ pinctrl_camera1_pwdn: camera1pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19
+ >;
+ };
+
+ pinctrl_camera2_pwdn: camera2pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19
+ >;
+ };
+
+ pinctrl_camera_rst: camerarstgrp {
+ fsl,pins = <
+ /* Reset PIN for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x19
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
@@ -565,6 +707,13 @@ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
pinctrl_ir: irgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x4f
--
2.37.1
^ permalink raw reply related
* [PATCH v2] ASoC: dt-bindings: cdns: Convert xtfpga I2S to dt-schema
From: Chaitanya Sabnis @ 2026-04-17 11:04 UTC (permalink / raw)
To: Max Filippov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, devicetree, linux-kernel, Chaitanya Sabnis
Convert the xtfpga I2S controller plain-text binding
documentation to standard dt-schema (YAML).
The hardware requires exactly one memory region, one interrupt line,
and one phandle to the master clock. Verified these constraints against
the driver source in sound/soc/xtensa/xtfpga-i2s.c.
Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
---
.../bindings/sound/cdns,xtfpga-i2s.txt | 18 -------
.../bindings/sound/cdns,xtfpga-i2s.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
deleted file mode 100644
index 860fc0da39c0..000000000000
--- a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Bindings for I2S controller built into xtfpga Xtensa bitstreams.
-
-Required properties:
-- compatible: shall be "cdns,xtfpga-i2s".
-- reg: memory region (address and length) with device registers.
-- interrupts: interrupt for the device.
-- clocks: phandle to the clk used as master clock. I2S bus clock
- is derived from it.
-
-Examples:
-
- i2s0: xtfpga-i2s@d080000 {
- #sound-dai-cells = <0>;
- compatible = "cdns,xtfpga-i2s";
- reg = <0x0d080000 0x40>;
- interrupts = <2 1>;
- clocks = <&cdce706 4>;
- };
diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
new file mode 100644
index 000000000000..9617acef3f0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cdns,xtfpga-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2S controller built into xtfpga Xtensa bitstreams
+
+maintainers:
+ - Max Filippov <jcmvbkbc@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: cdns,xtfpga-i2s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: phandle to the clk used as master clock. I2S bus clock is derived from it.
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2s@d080000 {
+ compatible = "cdns,xtfpga-i2s";
+ reg = <0x0d080000 0x40>;
+ interrupts = <2 1>;
+ clocks = <&cdce706 4>;
+ #sound-dai-cells = <0>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Konrad Dybcio @ 2026-04-17 11:06 UTC (permalink / raw)
To: Harshal Dev, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, johannes.goede
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <b8f781b0-f7ba-407e-8603-ca504535a894@oss.qualcomm.com>
On 4/17/26 11:22 AM, Harshal Dev wrote:
> Hi,
>
> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>> SM8x50 platforms.
>>>
>>> Describe the crypto engine and its BAM.
>>>
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>> 1 file changed, 26 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> index f23cf81ddb77..e8c796f2c572 100644
>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>> status = "disabled";
>>> };
>>>
>>> + cryptobam: dma-controller@1dc4000 {
>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>> + #dma-cells = <1>;
>>> + iommus = <&apps_smmu 0x480 0x0>,
>>> + <&apps_smmu 0x481 0x0>;
>>
>> It seems like these aren't the right SIDs on this platform.. Have you
>> tested this patch on hw?
>
> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
> (I hope I don't need to pad them?)
No, you don't
>
> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>
> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>
> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
> SIDs and wait for a Tested-by from him.
Thanks
I think you should be able to get some life out of the crypto engine
via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
mentioned reports a failure on Hamoa)
Konrad
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: interrupt-controller: Add support for secure donated SGIs
From: Sudeep Holla @ 2026-04-17 11:07 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Marc Zyngier, Sudeep Holla,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAL_JsqLdSi2x-KibY7WXTEot8Bj=54XeE1VACtLTujxn0VTxRw@mail.gmail.com>
On Thu, Apr 16, 2026 at 09:02:27AM -0500, Rob Herring wrote:
> On Thu, Apr 16, 2026 at 8:09 AM Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >
> > On Thu, Apr 16, 2026 at 07:11:46AM -0500, Rob Herring wrote:
> > > On Sun, Apr 12, 2026 at 06:04:37PM +0100, Sudeep Holla wrote:
> > > > In GICv3, SGI security is defined by interrupt grouping and configuration
> > > > rather than by SGI number alone. Linux conventionally reserves SGIs 0-7
> > > > for non-secure internal kernel IPIs, while higher SGIs is assumed to be
> > > > owned/stolen by the Secure world unless explicitly made available.
> > > >
> > > > Document secure donated SGI interrupt specifiers for the GICv3 binding.
> > > > It describes "arm,secure-donated-ns-sgi-ranges" for SGIs donated by the
> > > > secure world to non-secure software. It excludes SGIs 0-7, which are
> > > > already used by the kernel for internal IPI purposes.
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > > > ---
> > > > .../bindings/interrupt-controller/arm,gic-v3.yaml | 27 +++++++++++++++++++++-
> > > > include/dt-bindings/interrupt-controller/arm-gic.h | 1 +
> > > > 2 files changed, 27 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > index bfd30aae682b..664727d071c9 100644
> > > > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > @@ -45,17 +45,24 @@ description: |
> > > >
> > > > The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > > > interrupts, 2 for interrupts in the Extended SPI range, 3 for the
> > > > - Extended PPI range. Other values are reserved for future use.
> > > > + Extended PPI range, and 4 for SGI interrupts. Other values are
> > > > + reserved for future use.
> > > >
> > > > The 2nd cell contains the interrupt number for the interrupt type.
> > > > SPI interrupts are in the range [0-987]. PPI interrupts are in the
> > > > range [0-15]. Extended SPI interrupts are in the range [0-1023].
> > > > Extended PPI interrupts are in the range [0-127].
> > > >
> > > > + SGI interrupts are in the range [8-15] which overlaps with the SGIs
> > > > + assigned to/reserved for the secure world but donated to the non
> > > > + secure world to use. Refer "arm,secure-donated-ns-sgi-ranges" for
> > > > + more details.
> > > > +
> > > > The 3rd cell is the flags, encoded as follows:
> > > > bits[3:0] trigger type and level flags.
> > > > 1 = edge triggered
> > > > 4 = level triggered
> > > > + SGIs are edge triggered and must be described as such.
> > > >
> > > > The 4th cell is a phandle to a node describing a set of CPUs this
> > > > interrupt is affine to. The interrupt must be a PPI, and the node
> > > > @@ -136,6 +143,24 @@ description: |
> > > > - $ref: /schemas/types.yaml#/definitions/uint32
> > > > - $ref: /schemas/types.yaml#/definitions/uint64
> > > >
> > > > + arm,secure-donated-ns-sgi-ranges:
> > > > + description:
> > > > + A list of pairs <sgi span>, where "sgi" is the first SGI INTID of a
> > > > + range donated by the secure side to non-secure software, and "span" is
> > > > + the size of that range. Multiple ranges can be provided.
> > > > +
> > > > + SGIs described by interrupt specifiers with type 4 (SGI) must fall
> > > > + within one of these ranges. SGIs(0-7) reserved by non-secure world
> > > > + for internal IPIs must not be listed here. "sgi" must be in the
> > > > + range [8-15], "span" must be in the range [1-8], and the range must
> > > > + not extend past SGI 15.
> > > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > > > + items:
> > >
> > > As a matrix, you need:
> > >
> > > items:
> > > items:
> > > - ...
> > > - ...
> > >
> > > However, given this is at most 8 entries, I would just do an array:
> > >
> > > minItems: 1
> > > maxItems: 8
> > > uniqueItems: true
> > > items:
> > > minimum: 8
> > > maximum: 15
> > >
> >
> > Makes sense.
> >
> > > Unless we need more flexibility in GICv5?
> > >
> >
> > IIUC, there are not SGIs in GICv5 and we may need to use one software PPI
> > as a replacement for SGIs. LPIs are used for IPIs.
> >
> > I am assuming Marc will soon post his opinion/rejection on this series 😉
> > based on some offline discussion we had with respect to how it fits with
> > GICv5.
> >
> > > Is there an example we can stick this property into so it gets tested?
> > >
> >
> > Not sure if [1] serves as an example or you are looking for something else.
>
> In the binding example, but don't add a whole new example for it.
>
> Did [1] pass validation? If it did, it shouldn't have and I need to
> investigate. If you didn't run it, then that would be the reason I
> want it in the binding example.
>
By validation, do you mean `dtbs_check` ? If so, yes I didn't see any
warnings. But it is likely that I might have missed some flags as I was
doing `dtbs_check` and `dt_bindings_check` after very long time. I will
check again. But the commands did produce warnings in other files.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Frank Li @ 2026-04-17 11:22 UTC (permalink / raw)
To: Robby Cai
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260417110200.753678-2-robby.cai@nxp.com>
On Fri, Apr 17, 2026 at 07:01:59PM +0800, Robby Cai wrote:
> CSI capture may intermittently fail due to mismatched clock rates. The
> previous configuration violated the timing requirement stated in the
> i.MX8MQ Reference Manual:
>
> "The frequency of clk must be exactly equal to or greater than the RX
> byte clock coming from the RX DPHY."
>
> Update the clock configuration to ensure that the CSI core clock rate is
> equal to or greater than the incoming DPHY byte clock.
You reduce clock, how to make sure it >= ?
> The updated clock
> ratios are consistent with those used in NXP's downstream BSP.
"downstream BSP" is not solidate reference for clock rate, it'd better
refer to date sheet, dose datasheet require such frequecy
Frank
>
> Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
> Cc: stable@vger.kernel.org
> Signed-off-by: Robby Cai <robby.cai@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6a25e219832c..165716d08e64 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
> <&clk IMX8MQ_CLK_CSI1_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> @@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
> <&clk IMX8MQ_CLK_CSI2_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI2_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-17 11:32 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-5-a19c0dd8c9f6@collabora.com>
Hi Cristian,
the comments below apply sort of to all patches in that series.
Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> The board exposes the GPIO4_C6 line to control the voltage bias on the
> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>
> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> property and drop the line from the vcc_5v0_hdmi regulator to allow
> adjusting the bias when transitioning between TMDS and FRL operating
> modes.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> index 749f0a54b478..93ae37699366 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> @@ -140,10 +140,7 @@ regulator-state-mem {
>
> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
> compatible = "regulator-fixed";
> - enable-active-high;
> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_con_en>;
> + regulator-always-on;
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> regulator-name = "vcc_5v0_hdmi";
I think this regulator was sort of a complete hack, to set that
gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
is completely functionless now, the whole thing could be removed?
> @@ -231,6 +228,8 @@ &gpu {
> };
>
> &hdmi {
> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
this should be sorted the other way around I think.
Also please provide a pinctrl-names property too. If for whatever reason
the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
board DTs are staying in the "old" compatible mode until they are adapted.
> status = "okay";
> };
>
> @@ -655,7 +654,7 @@ &pcie0 {
>
> &pinctrl {
> hdmi {
> - hdmi_con_en: hdmi-con-en {
> + hdmi_frl_en: hdmi-frl-en {
pinctrl names should ideally match the naming in schematics, for example
the "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to
go from DT to schematics and back.
> rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
>
>
Heiko
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-17 11:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
Hi Cristan,
Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
[...]
> Cristian Ciocaltea (40):
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
sense, because these patches really are mostly identical :-)
Heiko
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-firefly-itx-3588j
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-h96-max-v58
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-jaguar
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-mnt-reform2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-nanopc-t6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-max
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-plus
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-ultra
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-roc-rt
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-tiger
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-coolpi-4b
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
>
> .../boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
> .../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
> .../boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
> .../boot/dts/rockchip/rk3588-firefly-itx-3588j.dts | 9 +++++++++
> .../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts | 15 ++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 16 ++++++++++++++++
> .../arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-roc-rt.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts | 8 +++-----
> .../arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
> arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
> .../boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
> 41 files changed, 392 insertions(+), 35 deletions(-)
> ---
> base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
> change-id: 20260417-dts-rk-frl-enable-gpios-ce9930dbf5ca
>
>
^ permalink raw reply
* [PATCH v1 0/5] media: lm3560: convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
Add missing HWEN input pin and IN supply. Fix v4l2 subdev registration.
Remove platform data and switch to OF device tree bindings.
Svyatoslav Ryhel (5):
media: lm3560: Add HWEN pin support
media: lm3560: Add IN supply support
media: lm3560: Fix v4l2 subdev registration
media: lm3560: convert to use OF bindings
dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
.../devicetree/bindings/leds/ti,lm3560.yaml | 134 +++++++++++++++++
drivers/media/i2c/lm3560.c | 139 ++++++++++++++----
include/media/i2c/lm3560.h | 15 --
3 files changed, 243 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/5] media: lm3560: Add HWEN pin support
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
Add HWEN - logic high hardware enable input found in LM3560 to ensure its
proper operation.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/lm3560.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index f4cc844f4e3c..e6af61415821 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/slab.h>
#include <linux/mutex.h>
@@ -45,6 +46,7 @@ enum led_enable {
* @dev: pointer to &struct device
* @pdata: platform data
* @regmap: reg. map for i2c
+ * @hwen_gpio: line connected to hwen pin
* @lock: muxtex for serial access.
* @led_mode: V4L2 LED mode
* @ctrls_led: V4L2 controls
@@ -54,6 +56,7 @@ struct lm3560_flash {
struct device *dev;
struct lm3560_platform_data *pdata;
struct regmap *regmap;
+ struct gpio_desc *hwen_gpio;
struct mutex lock;
enum v4l2_flash_led_mode led_mode;
@@ -425,6 +428,12 @@ static int lm3560_probe(struct i2c_client *client)
flash->dev = &client->dev;
mutex_init(&flash->lock);
+ flash->hwen_gpio = devm_gpiod_get_optional(&client->dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(flash->hwen_gpio))
+ return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
+ "failed to get hwen gpio\n");
+
rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
if (rval < 0)
return rval;
@@ -452,6 +461,8 @@ static void lm3560_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(&flash->ctrls_led[i]);
media_entity_cleanup(&flash->subdev_led[i].entity);
}
+
+ gpiod_set_value_cansleep(flash->hwen_gpio, 0);
}
static const struct i2c_device_id lm3560_id_table[] = {
--
2.51.0
^ permalink raw reply related
* [PATCH v1 2/5] media: lm3560: Add IN supply support
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
Add IN supply (2.5V - 5.5V) found in LM3560 to ensure its proper work.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/lm3560.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index e6af61415821..a2674af6c9fb 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -16,6 +16,7 @@
#include <linux/slab.h>
#include <linux/mutex.h>
#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
#include <linux/videodev2.h>
#include <media/i2c/lm3560.h>
#include <media/v4l2-ctrls.h>
@@ -434,6 +435,11 @@ static int lm3560_probe(struct i2c_client *client)
return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
"failed to get hwen gpio\n");
+ rval = devm_regulator_get_enable(&client->dev, "vin");
+ if (rval)
+ return dev_err_probe(&client->dev, rval,
+ "failed to enable regulator\n");
+
rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
if (rval < 0)
return rval;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 3/5] media: lm3560: Fix v4l2 subdev registration
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
The existing driver does not call media subdev registration, making it
invisible to the media framework. Since the LM3560 supports two
independent LEDs, register each LED as a separate media entity.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/lm3560.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index a2674af6c9fb..bee1681a1603 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -368,10 +368,16 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
goto err_out;
flash->subdev_led[led_no].entity.function = MEDIA_ENT_F_FLASH;
+ rval = v4l2_async_register_subdev(&flash->subdev_led[led_no]);
+ if (rval < 0)
+ goto err_out;
+
return rval;
err_out:
v4l2_ctrl_handler_free(&flash->ctrls_led[led_no]);
+ media_entity_cleanup(&flash->subdev_led[led_no].entity);
+
return rval;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v1 4/5] media: lm3560: convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
Since there are no users of this driver via platform data, remove platform
data and switch to using device tree bindings.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/lm3560.c | 118 +++++++++++++++++++++++++++----------
include/media/i2c/lm3560.h | 15 -----
2 files changed, 87 insertions(+), 46 deletions(-)
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index bee1681a1603..dab2da87331d 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -14,7 +14,9 @@
#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/slab.h>
+#include <linux/mod_devicetable.h>
#include <linux/mutex.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/videodev2.h>
@@ -45,17 +47,19 @@ enum led_enable {
* struct lm3560_flash
*
* @dev: pointer to &struct device
- * @pdata: platform data
* @regmap: reg. map for i2c
* @hwen_gpio: line connected to hwen pin
* @lock: muxtex for serial access.
* @led_mode: V4L2 LED mode
* @ctrls_led: V4L2 controls
* @subdev_led: V4L2 subdev
+ * @peak: peak current
+ * @max_flash_timeout: flash timeout
+ * @max_flash_brt: flash mode led brightness
+ * @max_torch_brt: torch mode led brightness
*/
struct lm3560_flash {
struct device *dev;
- struct lm3560_platform_data *pdata;
struct regmap *regmap;
struct gpio_desc *hwen_gpio;
struct mutex lock;
@@ -63,6 +67,12 @@ struct lm3560_flash {
enum v4l2_flash_led_mode led_mode;
struct v4l2_ctrl_handler ctrls_led[LM3560_LED_MAX];
struct v4l2_subdev subdev_led[LM3560_LED_MAX];
+
+ enum lm3560_peak_current peak;
+ u32 max_flash_timeout;
+
+ u32 max_flash_brt[LM3560_LED_MAX];
+ u32 max_torch_brt[LM3560_LED_MAX];
};
#define to_lm3560_flash(_ctrl, _no) \
@@ -283,8 +293,8 @@ static int lm3560_init_controls(struct lm3560_flash *flash,
enum lm3560_led_id led_no)
{
struct v4l2_ctrl *fault;
- u32 max_flash_brt = flash->pdata->max_flash_brt[led_no];
- u32 max_torch_brt = flash->pdata->max_torch_brt[led_no];
+ u32 max_flash_brt = flash->max_flash_brt[led_no];
+ u32 max_torch_brt = flash->max_torch_brt[led_no];
struct v4l2_ctrl_handler *hdl = &flash->ctrls_led[led_no];
const struct v4l2_ctrl_ops *ops = &lm3560_led_ctrl_ops[led_no];
@@ -309,9 +319,9 @@ static int lm3560_init_controls(struct lm3560_flash *flash,
/* flash strobe timeout */
v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FLASH_TIMEOUT,
LM3560_FLASH_TOUT_MIN,
- flash->pdata->max_flash_timeout,
+ flash->max_flash_timeout,
LM3560_FLASH_TOUT_STEP,
- flash->pdata->max_flash_timeout);
+ flash->max_flash_timeout);
/* flash brt */
v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FLASH_INTENSITY,
@@ -351,15 +361,17 @@ static const struct regmap_config lm3560_regmap = {
};
static int lm3560_subdev_init(struct lm3560_flash *flash,
- enum lm3560_led_id led_no, char *led_name)
+ enum lm3560_led_id led_no,
+ struct fwnode_handle *fwnode)
{
struct i2c_client *client = to_i2c_client(flash->dev);
int rval;
v4l2_i2c_subdev_init(&flash->subdev_led[led_no], client, &lm3560_ops);
flash->subdev_led[led_no].flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- strscpy(flash->subdev_led[led_no].name, led_name,
- sizeof(flash->subdev_led[led_no].name));
+ snprintf(flash->subdev_led[led_no].name,
+ sizeof(flash->subdev_led[led_no].name),
+ "lm3560-led%d", led_no);
rval = lm3560_init_controls(flash, led_no);
if (rval)
goto err_out;
@@ -367,6 +379,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
if (rval < 0)
goto err_out;
flash->subdev_led[led_no].entity.function = MEDIA_ENT_F_FLASH;
+ flash->subdev_led[led_no].fwnode = fwnode;
rval = v4l2_async_register_subdev(&flash->subdev_led[led_no]);
if (rval < 0)
@@ -388,7 +401,7 @@ static int lm3560_init_device(struct lm3560_flash *flash)
/* set peak current */
rval = regmap_update_bits(flash->regmap,
- REG_FLASH_TOUT, 0x60, flash->pdata->peak);
+ REG_FLASH_TOUT, 0x60, flash->peak);
if (rval < 0)
return rval;
/* output disable */
@@ -401,10 +414,64 @@ static int lm3560_init_device(struct lm3560_flash *flash)
return rval;
}
+static int lm3560_of_probe(struct lm3560_flash *flash)
+{
+ struct fwnode_handle *node;
+ u32 peak_ua;
+ int rval, reg;
+
+ flash->peak = LM3560_PEAK_3600mA;
+ rval = device_property_read_u32(flash->dev,
+ "ti,peak-current-microamp", &peak_ua);
+ if (!rval) {
+ switch (peak_ua) {
+ case 16000000:
+ flash->peak = LM3560_PEAK_1600mA;
+ break;
+ case 23000000:
+ flash->peak = LM3560_PEAK_2300mA;
+ break;
+ case 30000000:
+ flash->peak = LM3560_PEAK_3000mA;
+ break;
+ case 36000000:
+ flash->peak = LM3560_PEAK_3600mA;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ flash->max_flash_timeout = LM3560_FLASH_TOUT_MAX;
+ device_property_read_u32(flash->dev, "ti,max-flash-timeout-ms",
+ &flash->max_flash_timeout);
+
+ device_for_each_child_node(flash->dev, node) {
+ fwnode_property_read_u32(node, "reg", ®);
+
+ if (reg == LM3560_LED0 || reg == LM3560_LED1) {
+ flash->max_flash_brt[reg] = LM3560_FLASH_BRT_MAX;
+ fwnode_property_read_u32(node, "ti,max-flash-current-microamp",
+ &flash->max_flash_brt[reg]);
+
+ flash->max_torch_brt[reg] = LM3560_TORCH_BRT_MAX;
+ fwnode_property_read_u32(node, "ti,max-torch-current-microamp",
+ &flash->max_torch_brt[reg]);
+
+ rval = lm3560_subdev_init(flash, reg, node);
+ if (rval < 0)
+ return dev_err_probe(flash->dev, rval,
+ "failed to register led%d\n",
+ reg);
+ }
+ }
+
+ return 0;
+}
+
static int lm3560_probe(struct i2c_client *client)
{
struct lm3560_flash *flash;
- struct lm3560_platform_data *pdata = dev_get_platdata(&client->dev);
int rval;
flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
@@ -417,21 +484,6 @@ static int lm3560_probe(struct i2c_client *client)
return rval;
}
- /* if there is no platform data, use chip default value */
- if (pdata == NULL) {
- pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
- if (pdata == NULL)
- return -ENODEV;
- pdata->peak = LM3560_PEAK_3600mA;
- pdata->max_flash_timeout = LM3560_FLASH_TOUT_MAX;
- /* led 1 */
- pdata->max_flash_brt[LM3560_LED0] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED0] = LM3560_TORCH_BRT_MAX;
- /* led 2 */
- pdata->max_flash_brt[LM3560_LED1] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED1] = LM3560_TORCH_BRT_MAX;
- }
- flash->pdata = pdata;
flash->dev = &client->dev;
mutex_init(&flash->lock);
@@ -446,11 +498,7 @@ static int lm3560_probe(struct i2c_client *client)
return dev_err_probe(&client->dev, rval,
"failed to enable regulator\n");
- rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
- if (rval < 0)
- return rval;
-
- rval = lm3560_subdev_init(flash, LM3560_LED1, "lm3560-led1");
+ rval = lm3560_of_probe(flash);
if (rval < 0)
return rval;
@@ -477,6 +525,13 @@ static void lm3560_remove(struct i2c_client *client)
gpiod_set_value_cansleep(flash->hwen_gpio, 0);
}
+static const struct of_device_id lm3560_of_match[] = {
+ { .compatible = "ti,lm3559" },
+ { .compatible = "ti,lm3560" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lm3560_of_match);
+
static const struct i2c_device_id lm3560_id_table[] = {
{ LM3559_NAME },
{ LM3560_NAME },
@@ -489,6 +544,7 @@ static struct i2c_driver lm3560_i2c_driver = {
.driver = {
.name = LM3560_NAME,
.pm = NULL,
+ .of_match_table = lm3560_of_match,
},
.probe = lm3560_probe,
.remove = lm3560_remove,
diff --git a/include/media/i2c/lm3560.h b/include/media/i2c/lm3560.h
index 770d8c72c94a..b56c1ff8fd49 100644
--- a/include/media/i2c/lm3560.h
+++ b/include/media/i2c/lm3560.h
@@ -66,19 +66,4 @@ enum lm3560_peak_current {
LM3560_PEAK_3600mA = 0x60
};
-/* struct lm3560_platform_data
- *
- * @peak : peak current
- * @max_flash_timeout: flash timeout
- * @max_flash_brt: flash mode led brightness
- * @max_torch_brt: torch mode led brightness
- */
-struct lm3560_platform_data {
- enum lm3560_peak_current peak;
-
- u32 max_flash_timeout;
- u32 max_flash_brt[LM3560_LED_MAX];
- u32 max_torch_brt[LM3560_LED_MAX];
-};
-
#endif /* __LM3560_H__ */
--
2.51.0
^ permalink raw reply related
* [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
LEDs.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/leds/ti,lm3560.yaml | 134 ++++++++++++++++++
1 file changed, 134 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
new file mode 100644
index 000000000000..460ea1fbc1e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3560 Synchronous Boost Flash Driver
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
+ 1000-mA constant current drivers for high-current white LEDs. The dual high-
+ side current sources allow for grounded cathode LED operation and can be
+ tied together for providing flash currents at up to 2 A through a single LED.
+ An adaptive regulation method ensures the current for each LED remains in
+ regulation and maximizes efficiency.
+
+properties:
+ compatible:
+ enum:
+ - ti,lm3559
+ - ti,lm3560
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ enable-gpios:
+ description: GPIO connected to the HWEN pin.
+ maxItems: 1
+
+ vin-supply:
+ description: Supply connected to the IN line.
+
+ ti,peak-current-microamp:
+ description:
+ The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
+ When the current limit is reached, the LM3560 stops switching for the
+ remainder of the switching cycle.
+ enum: [16000000, 23000000, 30000000, 36000000]
+ default: 36000000
+
+ ti,max-flash-timeout-ms:
+ description:
+ Maximum flash timeout in ms with step 32ms.
+ minimum: 32
+ maximum: 1024
+ default: 1024
+
+patternProperties:
+ '^led@[01]$':
+ description: LED control bank nodes.
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: Control bank selection (0 = bank A, 1 = bank B).
+ maximum: 1
+
+ ti,max-flash-current-microamp:
+ description:
+ Maximum flash current in uA with step 62500uA.
+ minimum: 62500
+ maximum: 1000000
+ default: 1000000
+
+ ti,max-torch-current-microamp:
+ description:
+ Maximum flash current in uA with step 31250uA.
+ minimum: 31250
+ maximum: 250000
+ default: 250000
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@53 {
+ compatible = "ti,lm3560";
+ reg = <0x53>;
+
+ enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vdd_3v3_sys>;
+
+ ti,peak-current-microamp = <16000000>;
+ ti,max-flash-timeout-ms = <1024>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+
+ label = "white::flash";
+ linux,default-trigger = "flash";
+
+ ti,max-flash-current-microamp = <562500>;
+ ti,max-torch-current-microamp = <156250>;
+ };
+
+ led@1 {
+ reg = <1>;
+
+ label = "yellow::flash";
+ linux,default-trigger = "flash";
+
+ ti,max-flash-current-microamp = <562500>;
+ ti,max-torch-current-microamp = <156250>;
+ };
+ };
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/4] add ufs support for Exynosautov920 SoC
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <CGME20260417115813epcas5p40234b872c221ce28981b17e42ca48139@epcas5p4.samsung.com>
This series adds ufs driver support for ExynosAutov920,
ExynosAutov920 has the UFSHCI 3.1 compliant UFS controller.
ExynosAutov920 has a different mask of UFS sharability from ExynosAutov9,
so this series provide flexible parameter for the mask.
With this series applied, UFS is functional and basic I/O operations are
known to be working.
Changes since v1:
* collected Acked-by on patch 2/4
* This Acked-by from Krzysztof was long back, for now kept it
* rebased on linux-next
* fixed few self review comments
* split dtsi patch into two, separated out syscon node patch
Link v1:
https://lore.kernel.org/linux-samsung-soc/20250702013316.2837427-1-sowon.na@samsung.com/
Alim Akhtar (1):
arm64: dts: exynosautov920: Add syscon hsi2 node
Sowon Na (3):
dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
scsi: ufs: exynos: add support for ExynosAutov920 SoC
arm64: dts: exynosautov920: enable support for ufs controller
.../bindings/ufs/samsung,exynos-ufs.yaml | 1 +
.../boot/dts/exynos/exynosautov920-sadk.dts | 8 ++
.../arm64/boot/dts/exynos/exynosautov920.dtsi | 27 +++++
drivers/ufs/host/ufs-exynos.c | 110 ++++++++++++++++++
4 files changed, 146 insertions(+)
base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/4] arm64: dts: exynosautov920: Add syscon hsi2 node
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
Syscon HSI2 block has system configuration settings for
HSI IPs, like ufs, usb etc. Add a syscon_hsi2 node entry
so that related HSI controller can make use of the same.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynosautov920.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
index 0bf7c4cb9846..0eb853770732 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -1426,6 +1426,12 @@ cmu_hsi2: clock-controller@16b00000 {
"ethernet";
};
+ syscon_hsi2: syscon@16c00000 {
+ compatible = "samsung,exynosautov920-hsi2-sysreg",
+ "syscon";
+ reg = <0x16c00000 0x800>;
+ };
+
pinctrl_hsi2: pinctrl@16c10000 {
compatible = "samsung,exynosautov920-pinctrl";
reg = <0x16c10000 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Krzysztof Kozlowski, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add samsung,exynosautov920-ufs compatible for ExynosAutov920 SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
index a7eb7ad85a94..710ce493f3b6 100644
--- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -19,6 +19,7 @@ properties:
- samsung,exynos7-ufs
- samsung,exynosautov9-ufs
- samsung,exynosautov9-ufs-vh
+ - samsung,exynosautov920-ufs
- tesla,fsd-ufs
reg:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] scsi: ufs: exynos: add support for ExynosAutov920 SoC
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add a dedicated compatible and drv_data with associated hooks for
ExynosAutov920 SoC.
ExynosAutov920 has a different mask of UFS sharability
from ExynosAutov9, so add related changes for the same.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
[Alim: fixed unintended changes, other fixes]
---
drivers/ufs/host/ufs-exynos.c | 110 ++++++++++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
index 77a6c8e44485..b2f65c465525 100644
--- a/drivers/ufs/host/ufs-exynos.c
+++ b/drivers/ufs/host/ufs-exynos.c
@@ -97,6 +97,10 @@
#define UFS_EXYNOSAUTO_RD_SHARABLE BIT(1)
#define UFS_EXYNOSAUTO_SHARABLE (UFS_EXYNOSAUTO_WR_SHARABLE | \
UFS_EXYNOSAUTO_RD_SHARABLE)
+#define UFS_EXYNOSAUTOV920_WR_SHARABLE BIT(3)
+#define UFS_EXYNOSAUTOV920_RD_SHARABLE BIT(2)
+#define UFS_EXYNOSAUTOV920_SHARABLE (UFS_EXYNOSAUTOV920_WR_SHARABLE |\
+ UFS_EXYNOSAUTOV920_RD_SHARABLE)
#define UFS_GS101_WR_SHARABLE BIT(1)
#define UFS_GS101_RD_SHARABLE BIT(0)
#define UFS_GS101_SHARABLE (UFS_GS101_WR_SHARABLE | \
@@ -417,6 +421,95 @@ static int exynos7_ufs_post_pwr_change(struct exynos_ufs *ufs,
return 0;
}
+static int exynosautov920_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ int i;
+ u32 tx_line_reset_period, rx_line_reset_period;
+
+ rx_line_reset_period = (RX_LINE_RESET_TIME * ufs->mclk_rate)
+ / NSEC_PER_MSEC;
+ tx_line_reset_period = (TX_LINE_RESET_TIME * ufs->mclk_rate)
+ / NSEC_PER_MSEC;
+
+ unipro_writel(ufs, 0x5f, 0x44);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x200), 0x40);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x202), 0x02);
+
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_CLK_PRD, i),
+ DIV_ROUND_UP(NSEC_PER_SEC, ufs->mclk_rate));
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_CLK_PRD_EN, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE2, i),
+ (rx_line_reset_period >> 16) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE1, i),
+ (rx_line_reset_period >> 8) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE0, i),
+ (rx_line_reset_period) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x2f, i), 0x69);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x84, i), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x25, i), 0xf6);
+ }
+
+ for_each_ufs_tx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_CLK_PRD, i),
+ DIV_ROUND_UP(NSEC_PER_SEC, ufs->mclk_rate));
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_CLK_PRD_EN, i),
+ 0x02);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE2, i),
+ (tx_line_reset_period >> 16) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE1, i),
+ (tx_line_reset_period >> 8) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE0, i),
+ (tx_line_reset_period) & 0xFF);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x04, i), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x7f, i), 0x0);
+ }
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x200), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_LOCAL_TX_LCC_ENABLE), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0xa011), 0x8000);
+
+ return 0;
+}
+
+static int exynosautov920_ufs_post_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x9529), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x15a4), 0x3e8);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x9529), 0x0);
+
+ return 0;
+}
+
+static int exynosautov920_ufs_pre_pwr_change(struct exynos_ufs *ufs,
+ struct ufs_pa_layer_attr *pwr)
+{
+ struct ufs_hba *hba = ufs->hba;
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x15d4), 0x1);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_FC0PROTTIMEOUTVAL), 8064);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_TC0REPLAYTIMEOUTVAL), 28224);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_AFC0REQTIMEOUTVAL), 20160);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA0), 12000);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA1), 32000);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA2), 16000);
+
+ unipro_writel(ufs, 8064, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER0);
+ unipro_writel(ufs, 28224, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER1);
+ unipro_writel(ufs, 20160, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER2);
+ unipro_writel(ufs, 12000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER0);
+ unipro_writel(ufs, 32000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER1);
+ unipro_writel(ufs, 16000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER2);
+
+ return 0;
+}
+
/*
* exynos_ufs_auto_ctrl_hcc - HCI core clock control by h/w
* Control should be disabled in the below cases
@@ -2201,6 +2294,21 @@ static const struct exynos_ufs_drv_data gs101_ufs_drvs = {
.suspend = gs101_ufs_suspend,
};
+static const struct exynos_ufs_drv_data exynosautov920_ufs_drvs = {
+ .uic_attr = &exynos7_uic_attr,
+ .quirks = UFSHCD_QUIRK_SKIP_DEF_UNIPRO_TIMEOUT_SETTING,
+ .opts = EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL |
+ EXYNOS_UFS_OPT_SKIP_CONFIG_PHY_ATTR |
+ EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX |
+ EXYNOS_UFS_OPT_TIMER_TICK_SELECT,
+ .iocc_mask = UFS_EXYNOSAUTOV920_SHARABLE,
+ .drv_init = exynosauto_ufs_drv_init,
+ .post_hce_enable = exynosauto_ufs_post_hce_enable,
+ .pre_link = exynosautov920_ufs_pre_link,
+ .post_link = exynosautov920_ufs_post_link,
+ .pre_pwr_change = exynosautov920_ufs_pre_pwr_change,
+};
+
static const struct of_device_id exynos_ufs_of_match[] = {
{ .compatible = "google,gs101-ufs",
.data = &gs101_ufs_drvs },
@@ -2210,6 +2318,8 @@ static const struct of_device_id exynos_ufs_of_match[] = {
.data = &exynosauto_ufs_drvs },
{ .compatible = "samsung,exynosautov9-ufs-vh",
.data = &exynosauto_ufs_vh_drvs },
+ { .compatible = "samsung,exynosautov920-ufs",
+ .data = &exynosautov920_ufs_drvs },
{ .compatible = "tesla,fsd-ufs",
.data = &fsd_ufs_drvs },
{},
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: exynosautov920: enable support for ufs controller
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add ufs node for ExynosAutov920 SoC. Also enable ufs_phy and
ufs controller nodes.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
.../boot/dts/exynos/exynosautov920-sadk.dts | 8 +++++++
.../arm64/boot/dts/exynos/exynosautov920.dtsi | 21 +++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
index a397f068ed53..5873720c213e 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
+++ b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
@@ -83,6 +83,14 @@ &usi_0 {
status = "okay";
};
+&ufs_0 {
+ status = "okay";
+};
+
+&ufs_0_phy {
+ status = "okay";
+};
+
&xtcxo {
clock-frequency = <38400000>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
index 0eb853770732..f1f5efcdb91e 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -1444,6 +1444,27 @@ pinctrl_hsi2ufs: pinctrl@16d20000 {
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
};
+ ufs_0: ufs@16e00000 {
+ compatible = "samsung,exynosautov920-ufs";
+ reg = <0x16e00000 0x100>,
+ <0x16e01100 0x400>,
+ <0x16e80000 0x8000>,
+ <0x16d08000 0x800>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = <GIC_SPI 613 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu_hsi2 CLK_MOUT_HSI2_UFS_EMBD_USER>,
+ <&cmu_hsi2 CLK_MOUT_HSI2_NOC_UFS_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ freq-table-hz = <0 0>, <0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
+ phys = <&ufs_0_phy>;
+ phy-names = "ufs-phy";
+ samsung,sysreg = <&syscon_hsi2 0x710>;
+ dma-coherent;
+ status = "disabled";
+ };
+
ufs_0_phy: phy@16e04000 {
compatible = "samsung,exynosautov920-ufs-phy";
reg = <0x16e04000 0x4000>;
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
From: Alim Akhtar @ 2026-04-17 12:02 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, 'Krzysztof Kozlowski'
In-Reply-To: <20260417121452.827054-3-alim.akhtar@samsung.com>
> -----Original Message-----
> From: Alim Akhtar <alim.akhtar@samsung.com>
> Sent: Friday, April 17, 2026 5:45 PM
> To: avri.altman@wdc.com; bvanassche@acm.org; robh@kernel.org;
> martin.petersen@oracle.com; krzk+dt@kernel.org
> Cc: sowon.na@samsung.com; peter.griffin@linaro.org; linux-
> scsi@vger.kernel.org; devicetree@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; linux-kernel@vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org>; Alim Akhtar <alim.akhtar@samsung.com>
> Subject: [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920
> compatible string
>
> From: Sowon Na <sowon.na@samsung.com>
>
> Add samsung,exynosautov920-ufs compatible for ExynosAutov920 SoC.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Just noticed that this email is no longer valid, In case there is a re-spin, will correct this.
Sorry for the noise.
^ permalink raw reply
* Re: [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Sakari Ailus @ 2026-04-17 12:13 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-6-clamor95@gmail.com>
Hi Svyatoslav,
Thanks for the set.
This patch should be the first one in the set, or at least before those
using the bindings defined here.
On Fri, Apr 17, 2026 at 02:42:26PM +0300, Svyatoslav Ryhel wrote:
> Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
> LEDs.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/leds/ti,lm3560.yaml | 134 ++++++++++++++++++
> 1 file changed, 134 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> new file mode 100644
> index 000000000000..460ea1fbc1e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> @@ -0,0 +1,134 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI LM3560 Synchronous Boost Flash Driver
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
> + 1000-mA constant current drivers for high-current white LEDs. The dual high-
> + side current sources allow for grounded cathode LED operation and can be
> + tied together for providing flash currents at up to 2 A through a single LED.
> + An adaptive regulation method ensures the current for each LED remains in
> + regulation and maximizes efficiency.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,lm3559
> + - ti,lm3560
> +
> + reg:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + enable-gpios:
> + description: GPIO connected to the HWEN pin.
> + maxItems: 1
> +
> + vin-supply:
> + description: Supply connected to the IN line.
> +
> + ti,peak-current-microamp:
> + description:
> + The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
> + When the current limit is reached, the LM3560 stops switching for the
> + remainder of the switching cycle.
> + enum: [16000000, 23000000, 30000000, 36000000]
> + default: 36000000
> +
> + ti,max-flash-timeout-ms:
> + description:
> + Maximum flash timeout in ms with step 32ms.
> + minimum: 32
> + maximum: 1024
> + default: 1024
> +
> +patternProperties:
> + '^led@[01]$':
> + description: LED control bank nodes.
> + $ref: /schemas/leds/common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Control bank selection (0 = bank A, 1 = bank B).
> + maximum: 1
> +
> + ti,max-flash-current-microamp:
> + description:
> + Maximum flash current in uA with step 62500uA.
> + minimum: 62500
> + maximum: 1000000
> + default: 1000000
> +
> + ti,max-torch-current-microamp:
Don't the LED flash bindings already have standardised properties for
these?
> + description:
> + Maximum flash current in uA with step 31250uA.
> + minimum: 31250
> + maximum: 250000
> + default: 250000
> +
> + required:
> + - reg
I'd say the max current properties are required as well, same for the
timeouts. Or make the lowest the default. The lowest values are very seldom
used in practice though.
> +
> +required:
> + - compatible
> + - reg
> + - '#address-cells'
> + - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@53 {
> + compatible = "ti,lm3560";
> + reg = <0x53>;
> +
> + enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vdd_3v3_sys>;
> +
> + ti,peak-current-microamp = <16000000>;
> + ti,max-flash-timeout-ms = <1024>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> +
> + label = "white::flash";
> + linux,default-trigger = "flash";
> +
> + ti,max-flash-current-microamp = <562500>;
> + ti,max-torch-current-microamp = <156250>;
> + };
> +
> + led@1 {
> + reg = <1>;
> +
> + label = "yellow::flash";
> + linux,default-trigger = "flash";
> +
> + ti,max-flash-current-microamp = <562500>;
> + ti,max-torch-current-microamp = <156250>;
> + };
> + };
> + };
--
Kind regards,
Sakari Ailus
^ 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