* Re: [PATCH v4 3/6] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-17 10:26 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <38d07e3b3c841d380c987800d8ef85065be94e79.camel@iscas.ac.cn>
On 6/15/2026 4:37 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:50 +0800，Joey Lu写道：
>> The DC8200 and DCUltraLite share a broadly similar register layout
>> but
>> differ in how the bridge, CRTC, primary plane and IRQ paths are
>> driven.
>> Introduce a vs_dc_funcs vtable so each variant can supply its own
>> implementation without scattering conditionals across multiple files.
>>
>> Add enum vs_dc_generation (VSDC_GEN_DC8000 / VSDC_GEN_DC8200) to
>> vs_hwdb.h and a generation field to struct vs_chip_identity.
>> Annotate
>> all four existing DC8200 HWDB entries with VSDC_GEN_DC8200.
>>
>> Extract the DC8200-specific hardware ops into a new vs_dc8200.c:
>> panel_enable_ex / panel_disable_ex - PANEL_CONFIG/START + CONFIG_EX
>> commit
>> enable_vblank / disable_vblank - TOP_IRQ_EN VSYNC bit
>> primary_plane_enable_ex / disable_ex / update_ex - FB_CONFIG_EX
>> path
>> irq_ack - reads TOP_IRQ_ACK
>>
>> Update vs_bridge.c, vs_crtc.c, vs_primary_plane.c and vs_dc.c to
>> dispatch through dc->funcs instead of directly touching registers.
>> vs_crtc.c gains atomic_begin and atomic_flush hooks to allow variants
>> to gate per-frame commit cycles.
>>
>> No behaviour change for existing DC8200 platforms.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/Makefile | 2 +-
>> drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +---
>> drivers/gpu/drm/verisilicon/vs_crtc.c | 38 ++++++-
>> drivers/gpu/drm/verisilicon/vs_dc.c | 6 +-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 32 ++++++
>> drivers/gpu/drm/verisilicon/vs_dc8200.c | 107
>> ++++++++++++++++++
>> drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
>> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
>> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +-----
>> 9 files changed, 196 insertions(+), 51 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 426f4bcaa834..9d4cd16452fa 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o
>> vs_hwdb.o \
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o \
>> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> index 7a93049368db..6ff2ac745b15 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> @@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct
>> vs_crtc *crtc,
>> VSDC_DISP_PANEL_CONFIG_DE_EN |
>> VSDC_DISP_PANEL_CONFIG_DAT_EN |
>> VSDC_DISP_PANEL_CONFIG_CLK_EN);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +
>> + dc->funcs->panel_enable_ex(dc, output);
>> }
>>
>> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
>> @@ -228,14 +221,7 @@ static void vs_bridge_atomic_disable(struct
>> drm_bridge *bridge,
>> struct vs_dc *dc = crtc->dc;
>> unsigned int output = crtc->id;
>>
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> + dc->funcs->panel_disable_ex(dc, output);
>> }
>>
>> static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> index 0b8a35d09cd2..679d6541ba1b 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> @@ -16,10 +16,33 @@
>> #include "vs_crtc_regs.h"
>> #include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_plane.h"
>>
>> +static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_begin)
>> + dc->funcs->crtc_begin(dc, output);
>> +}
>> +
>> +static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_flush)
>> + dc->funcs->crtc_flush(dc, output);
>> +
>> + drm_crtc_vblank_atomic_flush(crtc, state);
>> +}
>> +
>> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
>> struct drm_atomic_commit *state)
>> {
>> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc
>> *crtc,
>> drm_crtc_vblank_off(crtc);
>>
>> clk_disable_unprepare(dc->pix_clk[output]);
>> +
>> + if (dc->funcs->crtc_disable)
>> + dc->funcs->crtc_disable(dc, output);
> Should this be `crtc_disable_ex` ? Because the clock-related operation
> is shared.
I will rename `crtc_disable` to `crtc_disable_ex` and `crtc_enable` to
`crtc_enable_ex` in v5 to make clear these hooks extend the shared clock
operations rather than replace them.
>> }
>>
>> static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
>> @@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> drm_WARN_ON(&dc->drm_dev->base,
>> clk_prepare_enable(dc->pix_clk[output]));
>>
>> + if (dc->funcs->crtc_enable)
>> + dc->funcs->crtc_enable(dc, output);
> Ditto for appending `_ex` .
Addressed above.
>> +
>> drm_crtc_vblank_on(crtc);
>> }
>>
>> @@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc
>> *crtc,
>> }
>>
>> static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
>> - .atomic_flush = drm_crtc_vblank_atomic_flush,
>> + .atomic_begin = vs_crtc_atomic_begin,
>> + .atomic_flush = vs_crtc_atomic_flush,
>> .atomic_enable = vs_crtc_atomic_enable,
>> .atomic_disable = vs_crtc_atomic_disable,
>> .mode_set_nofb = vs_crtc_mode_set_nofb,
>> @@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc
>> *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->enable_vblank(dc, vcrtc->id);
>>
>> return 0;
>> }
>> @@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct
>> drm_crtc *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->disable_vblank(dc, vcrtc->id);
>> }
>>
>> static const struct drm_crtc_funcs vs_crtc_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index dad9967bc10b..9729b693d360 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -8,9 +8,7 @@
>> #include <linux/of.h>
>> #include <linux/of_graph.h>
>>
>> -#include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_hwdb.h"
>>
>> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
>> *private)
>> struct vs_dc *dc = private;
>> u32 irqs;
>>
>> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + irqs = dc->funcs->irq_ack(dc);
> The definition of bits in 0x0010 seems to be different to ones in
> 0x147C, although the first 2 bits are the same. (e.g. `BIT(2)` is
> "cursor interrupt" in DC8000 0x147C but "secure reset done" in DC8200
> 0x0010).
>
> Should some kind of translation be done in `irq_ack` ? (and add a
> unified interrupt definition that aims to be the translation target).
>
> Thanks,
> Icenowy
>
>>
>> vs_drm_handle_irq(dc, irqs);
>>
>> @@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> + dc->funcs = &vs_dc8200_funcs;
>> +
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> ret = -EINVAL;
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index ed1016f18758..544e1a37065b 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -14,6 +14,7 @@
>> #include <linux/reset.h>
>>
>> #include <drm/drm_device.h>
>> +#include <drm/drm_plane.h>
>>
>> #include "vs_hwdb.h"
>>
>> @@ -22,6 +23,34 @@
>>
>> struct vs_drm_dev;
>> struct vs_crtc;
>> +struct vs_dc;
>> +
>> +struct vs_dc_funcs {
>> + /* Bridge: atomic_enable, atomic_disable */
>> + void (*panel_enable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*panel_disable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* CRTC: atomic_begin, atomic_flush */
>> + void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: atomic_enable, atomic_disable */
>> + void (*crtc_enable)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_disable)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: enable_vblank, disable_vblank */
>> + void (*enable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*disable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* Primary plane: atomic_enable, atomic_disable,
>> atomic_update */
>> + void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned
>> int output,
>> + struct drm_plane_state
>> *state);
>> +
>> + /* IRQ acknowledge */
>> + u32 (*irq_ack)(struct vs_dc *dc);
>> +};
>>
>> struct vs_dc {
>> struct regmap *regs;
>> @@ -33,6 +62,9 @@ struct vs_dc {
>>
>> struct vs_drm_dev *drm_dev;
>> struct vs_chip_identity identity;
>> + const struct vs_dc_funcs *funcs;
>> };
>>
>> +extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> new file mode 100644
>> index 000000000000..800df9279e9b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> @@ -0,0 +1,107 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_bridge_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_dc_top_regs.h"
>> +#include "vs_plane.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> + regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc,
>> unsigned int output,
>> + struct drm_plane_state
>> *state)
>> +{
>> + regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>> crtc_y));
>> + regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>> crtc_w,
>> + state->crtc_y + state-
>>> crtc_h));
>> + regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>> + VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
>> +{
>> + u32 irqs;
>> +
>> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + return irqs;
>> +}
>> +
>> +const struct vs_dc_funcs vs_dc8200_funcs = {
>> + .panel_enable_ex = vs_dc8200_panel_enable_ex,
>> + .panel_disable_ex =
>> vs_dc8200_panel_disable_ex,
>> + .enable_vblank = vs_dc8200_enable_vblank,
>> + .disable_vblank =
>> vs_dc8200_disable_vblank,
>> + .primary_plane_enable_ex =
>> vs_dc8200_primary_plane_enable_ex,
>> + .primary_plane_disable_ex =
>> vs_dc8200_primary_plane_disable_ex,
>> + .primary_plane_update_ex =
>> vs_dc8200_primary_plane_update_ex,
>> + .irq_ack = vs_dc8200_irq_ack,
>> +};
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> index 2a0f7c59afa3..91524d16f778 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> @@ -94,6 +94,7 @@ static struct vs_chip_identity vs_chip_identities[]
>> = {
>> .revision = 0x5720,
>> .customer_id = ~0U,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> @@ -103,6 +104,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5721,
>> .customer_id = 0x30B,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> @@ -112,6 +114,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5720,
>> .customer_id = 0x310,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_with_yuv444,
>> @@ -121,6 +124,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5720,
>> .customer_id = 0x311,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> index 2065ecb73043..a15c8b565604 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> @@ -9,6 +9,11 @@
>> #include <linux/regmap.h>
>> #include <linux/types.h>
>>
>> +enum vs_dc_generation {
>> + VSDC_GEN_DC8000,
>> + VSDC_GEN_DC8200,
>> +};
>> +
>> struct vs_formats {
>> const u32 *array;
>> unsigned int num;
>> @@ -19,6 +24,7 @@ struct vs_chip_identity {
>> u32 revision;
>> u32 customer_id;
>>
>> + enum vs_dc_generation generation;
>> u32 display_count;
>> /*
>> * The hardware only supports square cursor planes, so this
>> field
>> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> index 1f2be41ae496..f992cb277f61 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> @@ -53,12 +53,6 @@ static int vs_primary_plane_atomic_check(struct
>> drm_plane *plane,
>> return 0;
>> }
>>
>> -static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int
>> output)
>> -{
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_COMMIT);
>> -}
>> -
>> static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
>> struct drm_atomic_commit
>> *atomic_state)
>> {
>> @@ -69,13 +63,8 @@ static void vs_primary_plane_atomic_enable(struct
>> drm_plane *plane,
>> unsigned int output = vcrtc->id;
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_FB_EN);
>> - regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>> - VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_enable_ex)
>> + dc->funcs->primary_plane_enable_ex(dc, output);
>> }
>>
>> static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
>> @@ -88,10 +77,8 @@ static void vs_primary_plane_atomic_disable(struct
>> drm_plane *plane,
>> unsigned int output = vcrtc->id;
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_FB_EN);
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_disable_ex)
>> + dc->funcs->primary_plane_disable_ex(dc, output);
>> }
>>
>> static void vs_primary_plane_atomic_update(struct drm_plane *plane,
>> @@ -133,18 +120,11 @@ static void
>> vs_primary_plane_atomic_update(struct drm_plane *plane,
>> regmap_write(dc->regs, VSDC_FB_STRIDE(output),
>> fb->pitches[0]);
>>
>> - regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>> - VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>> crtc_y));
>> - regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>> - VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>> crtc_w,
>> - state->crtc_y + state-
>>> crtc_h));
>> regmap_write(dc->regs, VSDC_FB_SIZE(output),
>> VSDC_MAKE_PLANE_SIZE(state->crtc_w, state-
>>> crtc_h));
>>
>> - regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>> - VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_update_ex)
>> + dc->funcs->primary_plane_update_ex(dc, output,
>> state);
>> }
>>
>> static const struct drm_plane_helper_funcs
>> vs_primary_plane_helper_funcs = {
^ permalink raw reply
* Re: [PATCH v4 1/6] dt-bindings: display: verisilicon, dc: generalize for single-output variants
From: Joey Lu @ 2026-06-17 10:25 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <3683c5c617324f5835529617325745ef48fa1943.camel@iscas.ac.cn>
On 6/15/2026 4:19 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:49 +0800，Joey Lu写道：
>> The existing schema hard-codes the five-clock/three-reset/dual-port
>> topology of the DC8200 IP block, preventing reuse for single-output
>> variants such as the Verisilicon DCUltraLite used in the Nuvoton
>> MA35D1
>> SoC.
>>
>> Rework the schema so that variant-specific constraints are expressed
>> via
>> allOf/if blocks:
>>
>> - Add nuvoton,ma35d1-dcu to the SoC-specific compatible enum. The
>> generic verisilicon,dc fallback remains the driver-binding string.
>> - Move clock and reset items descriptions into the per-variant
>> allOf/if
>> blocks; keep only minItems/maxItems at the top level so the base
>> schema
>> accepts all variants.
>> - Restore full items lists for clock-names and reset-names at the top
>> level with minItems so the names are validated against the
>> descriptions.
>> - Keep ports in the global required list and keep
>> additionalProperties: false.
>> - Add an allOf/if block for thead,th1520-dc8200: five-clock (core,
>> axi,
>> ahb, pix0, pix1), three-reset (core, axi, ahb), required resets.
>> - Add an allOf/if block for nuvoton,ma35d1-dcu: two-clock (core,
>> pix0),
>> one-reset (core), required resets.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> .../bindings/display/verisilicon,dc.yaml | 80
>> +++++++++++++++++--
>> 1 file changed, 73 insertions(+), 7 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> index 9dc35ab973f2..0c41286b8223 100644
>> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> @@ -17,6 +17,7 @@ properties:
>> items:
>> - enum:
>> - thead,th1520-dc8200
>> + - nuvoton,ma35d1-dcu
>> - const: verisilicon,dc # DC IPs have discoverable ID/revision
>> registers
>>
>> reg:
>> @@ -26,14 +27,12 @@ properties:
>> maxItems: 1
>>
>> clocks:
>> - items:
>> - - description: DC Core clock
>> - - description: DMA AXI bus clock
>> - - description: Configuration AHB bus clock
>> - - description: Pixel clock of output 0
>> - - description: Pixel clock of output 1
> Clock descriptions should still be in the global part instead of the
> per-compatible part.
>
> In the per-compatible part, clock-names should be constraint for SoCs.
I will move the `items:` clock descriptions back into the global
`clocks:` property, covering all five possible clocks. In the
per-compatible sections I will remove the description items and only
constrain `clocks: minItems/maxItems` and `clock-names:
minItems/maxItems`; for nuvoton,ma35d1-dcu I will additionally override
`clock-names: items:` to the two names actually used (core, pix0).
>> + minItems: 2
>> + maxItems: 5
>>
>> clock-names:
>> + minItems: 2
>> + maxItems: 5
>> items:
>> - const: core
>> - const: axi
>> @@ -42,12 +41,16 @@ properties:
>> - const: pix1
>>
>> resets:
>> + minItems: 1
>> + maxItems: 3
>> items:
>> - description: DC Core reset
>> - description: DMA AXI bus reset
>> - description: Configuration AHB bus reset
>>
>> reset-names:
>> + minItems: 1
>> + maxItems: 3
>> items:
>> - const: core
>> - const: axi
>> @@ -59,7 +62,7 @@ properties:
>> properties:
>> port@0:
>> $ref: /schemas/graph.yaml#/properties/port
>> - description: The first output channel , endpoint 0 should be
>> + description: The first output channel, endpoint 0 should be
> If you really want to fix this, please make it a separated patch
> instead of doing it here, for commit atomicity.
>
> Thanks,
> Icenowy
I’ll drop this change and keep it as is
>> used for DPI format output and endpoint 1 should be used
>> for DP format output.
>>
>> @@ -77,6 +80,69 @@ required:
>> - clock-names
>> - ports
>>
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: thead,th1520-dc8200
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 5
>> + maxItems: 5
>> + items:
>> + - description: DC Core clock
>> + - description: DMA AXI bus clock
>> + - description: Configuration AHB bus clock
>> + - description: Pixel clock of output 0
>> + - description: Pixel clock of output 1
>> +
>> + clock-names:
>> + minItems: 5
>> + maxItems: 5
>> +
>> + resets:
>> + minItems: 3
>> + maxItems: 3
>> +
>> + reset-names:
>> + minItems: 3
>> + maxItems: 3
>> +
>> + required:
>> + - resets
>> + - reset-names
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: nuvoton,ma35d1-dcu
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 2
>> + maxItems: 2
>> + items:
>> + - description: DC Core clock
>> + - description: Pixel clock of output 0
>> +
>> + clock-names:
>> + minItems: 2
>> + maxItems: 2
>> +
>> + resets:
>> + minItems: 1
>> + maxItems: 1
>> +
>> + reset-names:
>> + maxItems: 1
>> +
>> + required:
>> + - resets
>> + - reset-names
>> +
>> additionalProperties: false
>>
>> examples:
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
From: Konrad Dybcio @ 2026-06-17 10:23 UTC (permalink / raw)
To: Mukesh Ojha, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260617080147.1657632-1-mukesh.ojha@oss.qualcomm.com>
On 6/17/26 10:01 AM, Mukesh Ojha wrote:
> Document the Qualcomm Hawi SoC binding and the boards which use it.
'Add the binding' or 'document the SoC/board', specifically not
'document the binding'
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..bf6bdded81d6 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -371,6 +371,11 @@ properties:
> - qcom,ipq9650-rdp488
> - const: qcom,ipq9650
>
> + - items:
> + - enum:
> + - qcom,hawi-mtp
> + - const: qcom,hawi
'h'awi should go before 'i'pq
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: monaco-arduino-monza: Remove duplicate includes
From: Konrad Dybcio @ 2026-06-17 10:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
monaco-arduino-monza.dts includes monaco-monza-som.dtsi, which aleady
includes monaco.dtsi and monaco-pmics.dtsi. Remove the duplicates.
The resulting DTB file is identical.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
index 379b796f261f..f475e2078451 100644
--- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
@@ -9,8 +9,6 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
-#include "monaco.dtsi"
-#include "monaco-pmics.dtsi"
#include "monaco-monza-som.dtsi"
/ {
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260617-topic-monza_includes-e53e7e508f1d
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 2/2] clk: renesas: r9a09g077: Add RTC clocks
From: Geert Uytterhoeven @ 2026-06-17 10:20 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615143943.1610095-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 16:40, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the core and module clock definitions for the Real-Time Clock (RTC)
> peripheral on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
From: Krzysztof Kozlowski @ 2026-06-17 10:20 UTC (permalink / raw)
To: Alim Akhtar
Cc: peter.griffin, robh, conor+dt, linusw, linux-samsung-soc,
linux-kernel, devicetree, linux-gpio, hajun.sung
In-Reply-To: <20260615085252.1964423-3-alim.akhtar@samsung.com>
On Mon, Jun 15, 2026 at 02:22:49PM +0530, Alim Akhtar wrote:
> Document pin controller support on Exynos8855 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
No wakeup-eint?
> Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: renesas,r9a09g077/87: Add PCLKRTC clock ID
From: Geert Uytterhoeven @ 2026-06-17 10:19 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615143943.1610095-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
Thanks for your patch!
On Mon, 15 Jun 2026 at 16:40, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the peripheral clock ID definition for the Real-Time Clock (PCLKRTC)
> on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs.
>
> Note that the LCDC_CLKD clock is utilized as the operating clock source
PCLKRTC
> for the RTC IP.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in a branch shared by renesas-clk and renesas-dts
with the above fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V2 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
From: Konrad Dybcio @ 2026-06-17 10:17 UTC (permalink / raw)
To: Monish Chunara, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Manivannan Sadhasivam
Cc: linux-arm-msm, devicetree, linux-kernel, Sarthak Garg,
Pradeep Pragallapati, Nitin Rawat, Shiraz Hashim
In-Reply-To: <20260616130347.3096034-2-monish.chunara@oss.qualcomm.com>
On 6/16/26 3:03 PM, Monish Chunara wrote:
> The Monaco SoC SDHC controller supports both eMMC and SD cards. However,
> the 'supports-cqe' property (Command Queue Engine) is specific to eMMC
> and conflicts with SD card operation.
>
> Remove 'supports-cqe' from the SoC device tree to ensure compatibility
> with SD cards. Simultaneously, add the property explicitly to the
> qcs8300-ride board device tree, as this board uses the controller in
> eMMC mode.
>
> This ensures the SoC definition remains generic while enabling features
> correctly at the board level.
>
> Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco.dtsi | 1 -
> arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 1 +
Please also fix up monaco-monza-som.dtsi
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support
From: Andy Shevchenko @ 2026-06-17 10:16 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <e1e6a5f3-4cf3-4454-ab73-a45ae7b77116@baylibre.com>
On Tue, Jun 16, 2026 at 10:55:34AM -0500, David Lechner wrote:
> On 6/16/26 3:36 AM, Andy Shevchenko wrote:
> > On Mon, Jun 15, 2026 at 05:00:02PM -0500, David Lechner (TI) wrote:
...
> >> + if (fwnode_property_present(child, "single-channel")) {
> >> + ret = fwnode_property_read_u32(child, "single-channel", &spec->channel);
> >> + if (ret)
> >> + return dev_err_probe(dev, ret,
> >> + "failed to read single-channel property\n");
> >> +
> >> + if (spec->channel >= 8)
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "single-channel value must be between 0 and 7\n");
> >> + } else if (fwnode_property_present(child, "diff-channels")) {
> >> + ret = fwnode_property_read_u32_array(child, "diff-channels", pair, ARRAY_SIZE(pair));
> >> + if (ret)
> >> + return dev_err_probe(dev, ret,
> >> + "failed to read diff-channels property\n");
> >> +
> >> + if (pair[0] >= 8 || pair[1] >= 8)
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "diff-channels values must be between 0 and 7\n");
> >> +
> >> + spec->channel = pair[0];
> >> + spec->channel2 = pair[1];
> >> + spec->differential = 1;
> >> + } else {
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "channel node missing channel type property\n");
> >> + }
> >
> > Looking how it's going to spread (I mean the above pattern), perhaps it's a time to introduce bunch of
> >
> > fwnode_property_read_*_optional()
> >
> > and the respective device_property_read_*_optional()?
> >
> > Let's start from u32 case only, as it will be most used anyway.
>
> I don't think that would be really any different from device_property_read_*
> and checking for -EINVAL or ignoring the error completely. TBH, I really like
> it this way with fwnode_property_present().
Yeah, it's explicit, but with _optional() we may simply have
propname = "single-channel";
ret = fwnode_property_read_u32_optional(child, propname, &spec->channel, 0);
if (ret)
return dev_err_probe(dev, ret, "failed to read %s property\n", propname);
if (spec->channel >= 8)
return dev_err_probe(dev, -EINVAL, "%s value must be between 0 and 7\n", propname);
However I admit that in the above case you also want to distinguish the cases.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Fenglin Wu @ 2026-06-17 10:12 UTC (permalink / raw)
To: Konrad Dybcio, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <29806448-0588-4590-8540-a689ccf1e7b0@oss.qualcomm.com>
On 6/17/2026 5:30 PM, Konrad Dybcio wrote:
> On 6/17/26 4:31 AM, Fenglin Wu wrote:
>>>> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> +
>>>> + for (; i < len; i++) {
>>>> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>> So if i'm reading this right, the first loop will always write
>>> 4*(len//4) bytes and the second one will be entered at most once,
>>> to write len rem 4 bytes.. should this be an if instead?
>> I should put a comment for clarification. Here’s some background: FIFO data writing supports both 4-byte bulk writes using registers [HAP_PTN_FIFO_DIN_0_REG ... HAP_PTN_FIFO_DIN_3_REG], and 1-byte writes using the HAP_PTN_FIFO_DIN_1B_REG register. The 4-byte bulk write is more efficient, especially for waveform which has several Kb data, and it helps to reduce software latency when loading effects and reduce the delay in triggering vibration. It also helps prevent the FIFO from running dry during data refill in FIFO-empty interrupts. Typically, we use 4-byte writes for the initial 4-byte aligned data, and 1-byte writes for any trailing remainder.
>>
>> So it still needs a 'for' loop here since the remainder could be more than 1 byte.
> Right, I mentioned len rem 4 but failed to notice it's a
> single-byte write.. anyway, a comment here would be good
>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Configure the hardware FIFO memory boundary.
>>>> + * FIFO occupies addresses [0, fifo_len).
>>>> + */
>>>> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
>>>> +{
>>>> + u32 fifo_len, fifo_units;
>>>> +
>>>> + /* Config all memory space for FIFO usage for now */
>>> What's the not-"for now" endgame for this?
>> The hardware supports more modes than the two currently supported in the driver. One of these, called 'PAT_MEM' mode, also shares memory space with FIFO mode. However, 'PAT_MEM' requires memory to be pre-reserved and waveform data to be pre-loaded. The entire 8K bytes of memory can be divided into partitions, and it is configurable, with FIFO mode always using the first partition [0, fifo_len], where 'fifo_len' is set via the 'MMAP_FIFO_REG' register. 'PAT_MEM' mode plays waveform using data preloaded in a memory bank defined by the registers 'PATX_MEM_START_ADDR_REG' and 'PATTERN_SPMI_PATX_LEN_REG' (they are not defined in the driver). Since PAT_MEM is mainly intended for hardware-triggered vibrations, such as a signal from a dedicated GPIO triggering a short vibration with a preloaded waveform, and although it also supports software triggers, I haven't found a suitable way to support it well into the driver under input FF framework yet. So, I am currently allocating the
>> entire 8K FIFO memory for FIFO mode only. We can adjust this later if we find a better way to incorporate 'PAT_MEM' mode into the driver.
> Sounds like a plan.
>
> For the other mode, would that GPIO trigger need any OS intervention?
> Could you speak a bit more about how that works?
>
> Konrad
I'll try to clarify the 'PAT_MEM' mode further. 'PAT_MEM' is useful for
latency-sensitive vibrations because it preloads the waveform into a
fixed memory bank, then it doesn't need to load the data of the effect
in the HW before triggering the play. When playback is triggered, it
plays the waveform from the specified memory address and length. This
memory should be preserved, and the data is preloaded during boot.
Unlike FIFO mode, it doesn't allow data refilling. The trigger can come
from hardware via dedicated GPIOs—currently, three are supported, each
mapping to a memory bank set through specific registers. Software
configuration can be done in the bootloader or in the driver probe, but
the 'fifo_len' should be adjusted accordingly. After setup, software
doesn't need to manage it further, relying on the GPIO signal to
activate the playback (for example, a pressure sensor triggering
vibration to simulate a physical key press). The trigger can also come
from software using SPMI commands by setting the play mode, start
address, and data length. I previously tried using the 'FF_HAPTIC'
effect by mapping 'hid_usage' to a predefined effect in the devicetree,
but later I found it unsuitable since 'FF_HAPTIC' is mainly for USB HID
touch devices and not general vibration usage. If you have any
suggestions for supporting 'PAT_MEM' mode through the input FF
framework, please let me know.
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: Add header file for ADC5 Gen3 channel macros
From: Neil Armstrong @ 2026-06-17 10:12 UTC (permalink / raw)
To: Konrad Dybcio, Jishnu Prakash, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <bae5b5be-16a9-4581-9863-4ca4eca88754@oss.qualcomm.com>
On 6/15/26 18:48, Konrad Dybcio wrote:
> On 6/15/26 6:39 PM, Neil Armstrong wrote:
>> Hi,
>>
>> On 6/15/26 17:55, Konrad Dybcio wrote:
>>> On 4/30/26 10:58 AM, Jishnu Prakash wrote:
>>>> Add macro definitions for virtual channels (combination of ADC channel
>>>> number and PMIC SID number), to be used in devicetree by clients of ADC5
>>>> GEN3 device and in the "reg" property of ADC channels.
>>>>
>>>> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>>>> ---
>>>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> And what happens with my patch [1] ?
>>
>> I had zero feedback so far
>>
>> [1] https://lore.kernel.org/all/20260504-topic-sm8x50-adc5-gen3-v2-1-5cc04d6ecda0@linaro.org/
>
> I think this approach (single generic header) is better. The existing
> ADC7 bindings which your series draws inspiration from come with a ton
> of boilerplate.
>
> There are some non-trivial mappings in there though, e.g.:
>
> +#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_100K_PU)
>
> but these would presumably be deducible from downstream
I'll try to rebase on this patch, seems all the values are defined, I just need to match the old and new defines
Neil
>
> Konrad
^ permalink raw reply
* Re: [PATCH v9 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Konrad Dybcio @ 2026-06-17 10:11 UTC (permalink / raw)
To: Stanislav Zaikin, devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, dmitry.baryshkov
In-Reply-To: <3bc5c1f5-8994-48b7-a376-39afc7e429e4@gmail.com>
On 6/17/26 9:55 AM, Stanislav Zaikin wrote:
> On 6/16/26 12:01 PM, Konrad Dybcio wrote:
>> On 6/8/26 4:33 PM, Stanislav Zaikin wrote:
>>> Xiaomi 12 Lite 5G is a handset released in 2022
>>>
>>> This commit has the following features working:
>>> - Display (with simple fb)
>>> - Touchscreen
>>> - UFS
>>> - Power and volume buttons
>>> - Pinctrl
>>> - RPM Regulators
>>> - Remoteprocs - wifi, bluetooth
>>> - USB (Device Mode)
>>>
>>> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
>>> ---
>>
>> [...]
>>
>>> +&ipa {
>>> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
>>> +
>>> + status = "okay";
>>> +};
>>
>> From make dtbs_check:
>>
>> qcom/sm7325-xiaomi-taoyao.dtb: ipa@1e40000 (qcom,sc7280-ipa): 'memory-region' is a required property
>>
>> Please fix that (or disable IPA)
>>
>> Otherwise:
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Konrad
>
> Thank you for the review.
>
> This patch depends on [0]. With [0] patch applied, dtbs_check passes w/o warnings.
>
> [0] https://lore.kernel.org/all/20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com/
Ah, I see, thank you
Konrad
^ permalink raw reply
* [PATCH v3] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-17 10:10 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v2:
- Add cs-gpios to required property
Link to v2: https://lore.kernel.org/all/20260615115311.515404-1-challauday369@gmail.com/
Changes since v1:
- Rename schema file to microchip,pic32mzda-spi.yaml
- Update subject prefix to match SPI DT binding conventions
Link to v1:https://lore.kernel.org/all/20260614175005.435826-1-challauday369@gmail.com/
---
.../bindings/spi/microchip,pic32mzda-spi.yaml | 82 +++++++++++++++++++
.../bindings/spi/microchip,spi-pic32.txt | 34 --------
2 files changed, 82 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
new file mode 100644
index 000000000000..4669b521fa1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA SPI Controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Fault interrupt
+ - description: Receive interrupt
+ - description: Transmit interrupt
+
+ interrupt-names:
+ items:
+ - const: fault
+ - const: rx
+ - const: tx
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mck0
+
+ cs-gpios:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: RX DMA channel
+ - description: TX DMA channel
+
+ dma-names:
+ items:
+ - const: spi-rx
+ - const: spi-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - cs-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi@1f821000 {
+ compatible = "microchip,pic32mzda-spi";
+ reg = <0x1f821000 0x200>;
+ interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
+ <110 IRQ_TYPE_LEVEL_HIGH>,
+ <111 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "fault", "rx", "tx";
+ clocks = <&PBCLK2>;
+ clock-names = "mck0";
+ cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
+ dmas = <&dma 134>, <&dma 135>;
+ dma-names = "spi-rx", "spi-tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt b/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
deleted file mode 100644
index 79de379f4dc0..000000000000
--- a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Microchip PIC32 SPI Master controller
-
-Required properties:
-- compatible: Should be "microchip,pic32mzda-spi".
-- reg: Address and length of register space for the device.
-- interrupts: Should contain all three spi interrupts in sequence
- of <fault-irq>, <receive-irq>, <transmit-irq>.
-- interrupt-names: Should be "fault", "rx", "tx" in order.
-- clocks: Phandle of the clock generating SPI clock on the bus.
-- clock-names: Should be "mck0".
-- cs-gpios: Specifies the gpio pins to be used for chipselects.
- See: Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- dmas: Two or more DMA channel specifiers following the convention outlined
- in Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: Names for the dma channels. There must be at least one channel
- named "spi-tx" for transmit and named "spi-rx" for receive.
-
-Example:
-
-spi1: spi@1f821000 {
- compatible = "microchip,pic32mzda-spi";
- reg = <0x1f821000 0x200>;
- interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
- <110 IRQ_TYPE_LEVEL_HIGH>,
- <111 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "fault", "rx", "tx";
- clocks = <&PBCLK2>;
- clock-names = "mck0";
- cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
- dmas = <&dma 134>, <&dma 135>;
- dma-names = "spi-rx", "spi-tx";
-};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/4] iio: adc: add ti-ads112c14 driver
From: Andy Shevchenko @ 2026-06-17 10:07 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <12831fd9-8a6f-442e-b1ca-f39248a5baf0@baylibre.com>
On Tue, Jun 16, 2026 at 10:38:05AM -0500, David Lechner wrote:
> On 6/16/26 2:32 AM, Andy Shevchenko wrote:
> > On Mon, Jun 15, 2026 at 05:00:00PM -0500, David Lechner (TI) wrote:
...
> >> + if (ret != -EREMOTEIO)
> >> + return ret;
> >
> > I would do it separately as
> >
> > if (ret == -EREMOTEIO)
> > /* ...big comment here... */
> > return 0;
What I meant here is
ret = 0;
Sorry for the confusion.
> We should not return early here. We just continue with the rest
> of the function as normal. So I think the way I had it was
> simplest. Otherwise we would need a goto or something like that.
>
>
> > if (ret) // which is regular pattern and doesn't need any comment.
> > return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 5/5] clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H display pipeline
From: Geert Uytterhoeven @ 2026-06-17 10:06 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the clock definitions and PLL logic required to supply the LCDC
> (VSPD/FCPVD/DU) blocks on the RZ/T2H (R9A09G077) SoC. The RZ/T2H display
> subsystem depends on a dedicated PLL (PLL3) and a set of new derived
> clocks.
>
> Introduce a new PLL clock type and implement rate recalculation,
> programming and locking sequences for PLL3 using the RZ/T2H specific
> divider and VCO limits. Add the corresponding muxes and divider entries,
> expose the LCDC core clock, and register the LCDC module clock using the
> correct PCLK parent.
>
> This enables the RZ/T2H clock driver to generate the display pipeline
> clocking tree needed by the DU and VSP-based composition engines, allowing
> upcoming display support to be integrated without duplicating CPG logic.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v2->v3:
> - In r9a09g077_cpg_lcdc_div_determine_rate() made use of
> clk_hw_get_parent_by_index() to ensure we retrieve pll3 as the parent.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: Andy Shevchenko @ 2026-06-17 10:05 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-3-063edcf74e60@herrie.org>
On Tue, Jun 16, 2026 at 03:02:06PM +0200, Herman van Hazendonk wrote:
> The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
> highest-sensitivity full-scale supported by the chip -- as the
> starting range. For the LSM303DLH that is +/-1.3 G; for the
> LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
>
> That is the right default for "minimal noise floor at a desk", but
> it leaves no margin for boards that pick up appreciable DC bias from
> nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
> LSM303DLH magnetometer is mounted close enough to the surrounding
> power planes that X reads back as the chip's 0xF000 overflow
> sentinel (== -4096 raw, the value the chip publishes when the ADC
> saturates) on every sample at the chip-default range, while Y and Z
> fall well within the +/-1.3 G window.
>
> Parse the st,fullscale-milligauss device-tree property (documented
> separately in dt-bindings/iio/st,st-sensors.yaml) in the
> magnetometer common probe to select the initial fs_avl entry by its
> mg value. The DT binding pins the accepted value set per compatible
> via allOf/if-then enum clauses, so a malformed mg value fails
> dt_binding_check rather than reaching the driver. Sensors with a
> fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
> register to switch and the property is rejected outright for them
> in the binding; the parse block is additionally gated on fs.addr as
> defence in depth against stale DTBs.
>
> Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
> LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
> 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
> they are 4000, 8000, 12000, 16000.
>
> Empirical scale sweep on the HP TouchPad confirmed that on this
> board any fs_avl >= 1 produces non-saturated X readings:
>
> scale (0.001 G/LSB) | X raw Y raw Z raw
> --------------------+-------------------------------
> 1.100 | -4096 44 46 (X saturated)
> 0.855 | -547 37 37 (clean)
> 0.670 | -433 94 103 (clean)
> 0.450 | -266 44 71 (clean)
> 0.400 | -235 34 65 (clean)
> 0.330 | -196 27 56 (clean)
> 0.230 | -145 15 40 (clean)
>
> 2500 mg is the natural choice for tenderloin: comfortably outside
> the saturation regime while keeping useful precision for compass
> applications.
Not sure if we need that big commit message, better to move to the point.
> + propname = "st,fullscale-milligauss";
> + if (mdata->sensor_settings->fs.addr &&
> + device_property_present(parent, propname)) {
> + struct st_sensor_fullscale *fs = &mdata->sensor_settings->fs;
> + u32 fs_mg;
> + int i;
Instead...
> + err = device_property_read_u32(parent, propname, &fs_mg);
> + if (err)
> + return err;
> + for (i = 0; i < ST_SENSORS_FULLSCALE_AVL_MAX; i++) {
for (unsigned int i = 0; i < ST_SENSORS_FULLSCALE_AVL_MAX; i++) {
> + if (!fs->fs_avl[i].num)
> + break;
> + if (fs->fs_avl[i].num == fs_mg) {
> + mdata->current_fullscale = &fs->fs_avl[i];
> + break;
> + }
> + }
> + if (mdata->current_fullscale->num != fs_mg)
> + dev_warn(parent, "%s=%u not supported, using %u\n",
> + propname, fs_mg,
> + mdata->current_fullscale->num);
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 9:54 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <DJB6XO07EC8Q.1X9P752MLFB4N@kernel.org>
Hi Michael,
> Hi,
>
> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] wrote:
>>>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to
>>>>>> fulfill these requirements in our
>>>>>> map() function.
>>>
>>> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>>> only called if the irq handling is set up via gc->irq.chip and not
>>> via
>>> gpiochip_irqchip_add_domain() like in gpio-regmap?
>>>
>>
>> The panic was caused by my driver including
>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>
> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>
> -michael
Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Additional information: our GPIO controller receives 3 separate interrupt lines.
Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
this multi-line hardware design, we are forced to create our own IRQ domain and pass
it via 'config->irq_domain'.
Given this constraint (that we must use our own IRQ domain), are you suggesting
that we should implement our own 'irq_request_resources' and
'irq_release_resources' callbacks instead of relying on
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
But if that is the case, we would much prefer to let the core gpiolib handle
these resource and state management tasks for us *as proposed in option 3), rather
than duplicating the effort in our driver.
Best Regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: kodiak: Elite-ify LPASS macros
From: Konrad Dybcio @ 2026-06-17 10:05 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, cros-qcom-dts-watchers
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260522-kodiak-elite-macros-v1-1-487661ac1270@fairphone.com>
On 5/22/26 4:46 PM, Luca Weiss wrote:
> Due to initial kodiak/sc7280 bringup being done for Chrome platforms,
> some Chrome-specific bits still remain in kodiak.dtsi, like the clocks
> and power-domains for the LPASS RX/TX/WSA/VA macros.
>
> Move them to sc7280-chrome-common.dtsi and put Elite (q6afecc)
> equivalents in its place. The qcs6490-audioreach.dtsi file can also drop
> deletion of power-domains properties then.
>
> This follows previous commits moving Chrome-specific configuration to
> the correct file, leaving kodiak.dtsi for Elite and
> qcs6490-audioreach.dtsi for AudioReach.
>
> No functional change intended. The clock-output-names property will now
> exist for both Chrome and AudioReach devices but this shouldn't have any
> relevant effect. And WSA macro clocks weren't added to Chrome because I
> don't believe this would've ever worked given it already referenced
> q6afecc and the nodes were originally added during AudioReach bringup.
I think it's better to keep them, if only to make sure that the result
of dtx_diff isn't outside the expectation of a commit that claims to
only reshuffle data for these platforms
It looks OK as-is for Elite and Audioreach platforms (for the record, I
checked rb3gen2 and FP5)
Konrad
^ permalink raw reply
* Re: [PATCH v3 4/5] clk: renesas: rzv2h-cpg: Extract PLL calculation math into a library
From: Geert Uytterhoeven @ 2026-06-17 10:04 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Move the common PLL and divider parameter calculation logic from the
> core rzv2h-cpg driver into a standalone library file.
>
> Introduce the CLK_RZV2H_CPG_LIB Kconfig configuration symbol and create
> rzv2h-cpg-lib.c to house rzv2h_cpg_get_pll_pars() and
> rzv2h_cpg_get_pll_divs_pars().
>
> Keep rzv2h_get_pll_pars() and rzv2h_get_pll_divs_pars() in the original
> driver as wrappers that call into the new library helper endpoints.
> These wrappers are maintained for this cycle because they are actively
> referenced by the DSI driver; they will be safely removed in a subsequent
> cycle once the DSI driver is updated to use the new APIs from the library,
> preventing cross-subsystem build breakages.
>
> This restructuring allows other Renesas SoC clock drivers, such as the
> upcoming RZ/T2H and RZ/N2H platforms that utilize similar LCDC clock
> divider mathematical logic, to share the iterative calculation helper
> infrastructure without duplication.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/include/linux/clk/renesas.h
> +++ b/include/linux/clk/renesas.h
> @@ -213,4 +213,27 @@ static inline bool rzv2h_get_pll_divs_pars(const struct rzv2h_pll_limits *limits
> }
> #endif
>
> +#ifdef CONFIG_CLK_RZV2H_CPG_LIB
> +bool rzv2h_cpg_get_pll_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_pars *pars, u64 freq_millihz);
> +
> +bool rzv2h_cpg_get_pll_divs_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_div_pars *pars,
> + const u8 *table, u8 table_size, u64 freq_millihz);
> +#else
> +static inline bool rzv2h_cpg_get_pll_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_pars *pars,
> + u64 freq_millihz)
> +{
> + return false;
> +}
> +
> +static inline bool rzv2h_cpg_get_pll_divs_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_div_pars *pars,
> + const u8 *table, u8 table_size,
> + u64 freq_millihz)
> +{
> + return false;
> +}
> +#endif
> #endif
What about just dropping the old functions, and adding two simple
compatibility defines in the header file:
#define rzv2h_get_pll_pars rzv2h_cpg_get_pll_pars
#define rzv2h_get_pll_divs_pars rzv2h_cpg_get_pll_divs_pars
That way there is less code to change in the next phase.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 06/12] rtc: rzn1: Sort headers alphabetically
From: Wolfram Sang @ 2026-06-17 10:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Prabhakar, Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdXg16frnn88_P_jHRH+HPy00wWfoqNKdOv8teSWNpMEGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> > @@ -15,8 +15,8 @@
> > #include <linux/clk.h>
> > #include <linux/init.h>
> > #include <linux/iopoll.h>
> > -#include <linux/module.h>
> > #include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
>
> Sorting of special characters w.r.t. alphanumericals is always
> a bit fuzzy...
I rely on the 'sort' utility which gives the same output, so:
> > #include <linux/platform_device.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/rtc.h>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: sashiko-bot @ 2026-06-17 10:04 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260617-mt6323-nvmem-v2-2-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unchecked traversal of device parent pointers causes a NULL pointer dereference.
- [High] Buffer overflow in the NVMEM read callback for unaligned read requests.
--
commit 6d793839a1a7e502029cf9f7b58d011fec9486e7
Author: Roman Vivchar <rva333@protonmail.com>
nvmem: add mt6323 PMIC EFUSE driver
This commit adds support for the EFUSE controller found in the Mediatek
MT6323 PMIC. The MT6323 EFUSE stores 24 bytes of hardware-related data,
such as thermal sensor calibration values.
> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..7a0ce4c7f5658
> --- /dev/null
> +++ b/drivers/nvmem/mt6323-efuse.c
[ ... ]
> +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct regmap *map = context;
> + u16 *buf = val;
> + u32 tmp;
> + int ret;
> +
> + /*
> + * A manual loop using regmap_read is required because PWRAP is not
> + * a continuous MMIO space, but rather a FSM that doesn't implement the
> + * necessary read callback for the regmap_read_raw and regmap_read_bulk
> + * functions.
> + */
> + for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> + ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> + if (ret)
> + return ret;
> +
> + *buf++ = tmp;
[Severity: High]
What happens if an internal client requests to read an odd number of bytes?
Since this loop unconditionally writes a 16-bit word on each iteration, an odd
bytes length would cause the loop to execute an extra time and write past the
end of the destination buffer. Because nvmem_device_read() does not enforce
word_size alignment on internal requests, this could corrupt adjacent memory
if the caller allocated a buffer matching the exact requested size.
Could the driver explicitly reject unaligned lengths or safely handle partial
word writes?
> + }
> +
> + return 0;
> +}
> +
> +static int mt6323_efuse_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_config config = {
> + .name = "mt6323-efuse",
> + .stride = 2,
> + .word_size = 2,
> + .size = MT6323_EFUSE_SIZE,
> + .reg_read = mt6323_efuse_read,
> + };
> + struct nvmem_device *nvmem;
> + struct regmap *regmap;
> +
> + /* efuse -> mfd -> pwrap */
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Could this lead to a NULL pointer dereference if the device tree hierarchy
is malformed?
If the device is instantiated at the top level or independently of the
expected MFD and PMIC wrapper structure, dev->parent could map to the
platform bus, making dev->parent->parent NULL. Passing a NULL pointer to
dev_get_regmap() will cause a kernel panic when it attempts to lock the
devres lock.
Would it be safer to verify that dev->parent and dev->parent->parent are
non-NULL before passing the grandparent pointer?
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data
From: Andy Shevchenko @ 2026-06-17 10:02 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree, stable
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-1-063edcf74e60@herrie.org>
On Tue, Jun 16, 2026 at 03:02:04PM +0200, Herman van Hazendonk wrote:
> st_sensors_read_axis_data() unconditionally decoded multi-byte
> results with get_unaligned_le16() / get_unaligned_le24() regardless
> of the channel's declared scan_type.endianness.
>
> For every ST sensor that has used this helper since it was introduced
> this happened to be fine because the ST IMU/accel/gyro/pressure
> families publish their data registers as little-endian and the
> channel specs in those drivers declare IIO_LE accordingly.
>
> The LSM303DLH magnetometer however publishes its X/Y/Z output as a
> pair of big-endian bytes (the H register sits at the lower address,
> 0x03/0x05/0x07, and the L register immediately after), and its
> channel specs in st_magn_core.c correctly declare IIO_BE -- but
> read_axis_data() ignored that and decoded as little-endian, swapping
> the high and low bytes of every magnetometer sample. The LSM303DLHC
> and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and
> were therefore byte-swapped by the same bug; users of those parts
> will see different in_magn_*_raw values after this fix lands.
>
> The bug is most visible on a stationary chip: in earth's field the
> true X reading is small and the high byte sits at 0x00, so swapping
> the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0
> = 240). Y and Z still appear "to vary" because their magnitudes are
> larger and the noise in the low byte produces big swings in the
> swapped high byte:
>
> before (LSM303DLH flat, sysfs in_magn_*_raw):
> X=240 (stuck), Y= 12032..23296, Z=-16128..-9728
>
> after (direct i2c-dev big-endian decode, same chip same orientation):
> X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's
> ambient field at low gauss range)
>
> Fix read_axis_data() to dispatch on ch->scan_type.endianness and
> call get_unaligned_be16() / get_unaligned_be24() when the channel
> declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro,
> st_pressure, st_lsm6dsx and others) are unaffected because their
> channel specs already declare IIO_LE and the LE path is unchanged.
>
> While restructuring the branches, replace the previously implicit
> silent-success-with-uninitialised-*data fall-through for
> byte_for_channel outside 1..3 with an explicit return -EINVAL. No
> in-tree ST sensor publishes such a channel, but the new behaviour
> is strictly safer than handing userspace garbage.
Sounds like inevitable change in ABI, but worth doing it.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: sashiko-bot @ 2026-06-17 10:02 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617-mt6323-nvmem-v2-4-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unchecked dereference of dev->parent when getting regmap.
--
commit f140540f16666ffd0b4a44edcb3b4ac15d83d749
Author: Roman Vivchar <rva333@protonmail.com>
ARM: dts: mediatek: mt6323: add EFUSE support
This commit adds the devicetree node for the mt6323 efuse to the mt6323
PMIC definition. It introduces the mediatek,mt6323-efuse compatible string
to instantiate the driver.
> diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> index c230c865116d0..807e000a7ff64 100644
> --- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> @@ -14,6 +14,10 @@ pmic: mt6323 {
> interrupt-controller;
> #interrupt-cells = <2>;
>
> + efuse {
> + compatible = "mediatek,mt6323-efuse";
[Severity: High]
Does binding to this compatible string introduce a regression under certain
devicetree configurations?
Looking at drivers/nvmem/mt6323-efuse.c:mt6323_efuse_probe(), the driver
blindly traverses the parent hierarchy:
/* efuse -> mfd -> pwrap */
regmap = dev_get_regmap(dev->parent->parent, NULL);
If the device is instantiated directly at the root of a Device Tree
or via a malformed overlay, it lacks a grandparent. In this case,
dev->parent is initialized to &platform_bus, and evaluating
dev->parent->parent results in a null pointer.
Passing a null pointer as the device to dev_get_regmap() triggers an
immediate kernel panic during probe(), because the underlying
devres_find() unconditionally dereferences the dev pointer.
Could the driver verify that the parent hierarchy exists before
attempting to traverse it and retrieve the regmap?
> + };
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=4
^ permalink raw reply
* Re: [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability
From: Wolfram Sang @ 2026-06-17 10:02 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
> Add system-wide power management support along with wakeup capability to
> the rtc-rzn1 driver.
Do you have an actual use case for the wakeup functionality? If it is so
limited, then we should maybe not support the weak abilities until
someone has a real use case? For which then, a proper solution has been
developed and tested?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: sashiko-bot @ 2026-06-17 10:00 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617-mt6323-nvmem-v2-1-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing core NVMEM schema reference for an NVMEM provider node.
--
commit 3b91c0fc686c29119bcba167256b72fe3a4c7b96
Author: Roman Vivchar <rva333@protonmail.com>
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
This commit adds devicetree binding documentation for the MediaTek mt6323
EFUSE. The efuse component is responsible for storing calibration data
within the mt6323 PMIC.
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 05c121b0cb3d8..beaa67bf0df2c 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -145,6 +145,23 @@ properties:
> required:
> - compatible
>
> + efuse:
> + type: object
> + unevaluatedProperties: false
> + description:
> + The efuse is responsible for storing calibration data, such as thermal
> + sensor calibration.
> +
> + properties:
> + compatible:
> + const: mediatek,mt6323-efuse
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
[Severity: Low]
Does this node need a reference to the core NVMEM schema?
Because the efuse node acts as an NVMEM provider and uses
unevaluatedProperties: false, it will currently reject standard NVMEM
properties like read-only and wp-gpios if they are specified in the
device tree.
Including a $ref to /schemas/nvmem/nvmem.yaml# would natively support
nvmem-layout and permit standard NVMEM provider features to pass validation.
> +
> + required:
> + - compatible
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=1
^ 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