* Re: [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 10:07 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <891015c8-68df-4654-b1e7-94d73e74267c@oss.qualcomm.com>
On Wed, 2026-06-24 at 13:00 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:07 PM, Xin Xu wrote:
> > On Mon, 2026-06-22 at 13:40 +0200, Konrad Dybcio wrote:
> > > On 6/19/26 6:07 PM, Xin Xu wrote:
> > > > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > > > using GPIO84 as interrupt and GPIO76 as reset.
> > > >
> > > > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > > > ---
>
> [...]
>
> > > > + pm8008_default: pm8008-default-state {
> > > > + int-pins {
> > > > + pins = "gpio84";
> > > > + function = "gpio";
> > > > + bias-disable;
> > > > + drive-strength = <2>;
> > > > + input-enable;
> > > > + };
> > > > +
> > > > + reset-pins {
> > > > + pins = "gpio76";
> > > > + function = "gpio";
> > > > + bias-pull-up;
> > > > + drive-strength = <2>;
> > > > + output-high;
> > >
> > > Drop output-high, the driver will take care of setting the output
> > > state
> > >
> > > Konrad
> >
> > Thank you for your review!
> >
> > I will fix the coding style issues (blank line before status,
> > interrupts-extended, property order, and dropping output-high)
> > in the next version.
> >
> > I have verified all LDO voltages against the downstream device
> > tree:
> > https://github.com/MiCode/kernel_devicetree/tree/elish-r-oss/
> > The definitions can be found around lines 209–244 in
> > qcom/elish-sm8250-camera-board.dtsi
>
> Thanks. It's best if you grab the DTB from a running device (which
> has all the overlays applied etc.), which you can grab from
> /sys/firmware/fdt
>
> You can then pass that to DTC directly
>
> Konrad
For additional verification, I have extracted the device tree from
/sys/firmware/fdt on a running device. The voltage values match the
ones in my patch exactly. Below is the relevant pm8008 regulator
portion:
qcom,pm8008-regulator {
compatible = "qcom,pm8008-regulator";
pm8008_en-supply = <0x708>;
qcom,enable-ocp-broadcast;
vdd_l1_l2-supply = <0xad>;
vdd_l3_l4-supply = <0x2cf>;
phandle = <0x7e6>;
qcom,pm8008-l1@4000 {
reg = <0x4000>;
regulator-name = "pm8008_l1";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71c>;
};
qcom,pm8008-l2@4100 {
reg = <0x4100>;
regulator-name = "pm8008_l2";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x713>;
};
qcom,pm8008-l3@4200 {
reg = <0x4200>;
regulator-name = "pm8008_l3";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x714>;
};
qcom,pm8008-l4@4300 {
reg = <0x4300>;
regulator-name = "pm8008_l4";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x70e>;
};
qcom,pm8008-l5@4400 {
reg = <0x4400>;
regulator-name = "pm8008_l5";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71b>;
};
qcom,pm8008-l6@4400 {
reg = <0x4500>;
regulator-name = "pm8008_l6";
regulator-min-microvolt = <0x1b7740>; /* 1800000 */
regulator-max-microvolt = <0x1b7740>; /* 1800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x7e7>;
};
qcom,pm8008-l7@4400 {
reg = <0x4600>;
regulator-name = "pm8008_l7";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2c4020>; /* 2900000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x712>;
};
};
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:07 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Sa, Nuno, Andy Shevchenko, Hennerich, Michael,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux,
devicetree@vger.kernel.org
In-Reply-To: <20260621174548.5eca5db6@jic23-huawei>
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, June 22, 2026 12:46 AM
> To: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux
> <linux@analog.com>; devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, 15 Jun 2026 13:05:44 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > > with AD3530R (channel configuration, LDAC triggering, powerdown
> > > control), the main difference being the register address map due to
> > > the dual-bank architecture, handled by table-driven helpers.
> > >
> > > Add AD3532R-specific register definitions, channel specs, per-bank
> > > register arrays, a dedicated ad3532r_set_dac_powerdown(), and
> > > per-chip regmap_config to limit debugfs-exposed register space to
> > > each variant's actual address range.
> >
> > ...
> >
> >
> > > help
> > > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > > - Digital to Analog Converter.
> > > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
> >
> > This just shows how unscalable the above text is. That's why we
> > usually recommend to make the list explicit and separated.
> >
> > Say yes here to build support for the following Analog Devices
> > Digital to Analog Converters:
> > - AD3530/AD3530R (8-channel)
> > - AD3531/AD3531R (4-channel)
> > - AD3532/AD3532R (16-channel)
> >
> > (and looking into the C-file change, perhaps add here as well
> > distinctive information, such as number of channels, in the parentheses).
> >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad3530r.
> >
> > ...
> >
> > > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > > +#define AD3532R_INPUT_CH_0 0x10EB
> > > +#define AD3532R_INPUT_CH_1 0x30EB
> > > +#define AD3532R_MAX_REG_ADDR 0x30F9
> Whilst we are here, Sashiko thinks there is an off by one on that value as it's
> the lower of the two registers that make up channel 15.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260615-iio-
> ad3532r-support-v2-0-
> 84a0af8b83fa*40analog.com__;IyU!!A3Ni8CS0y2Y!88afCOStwucx32wuoeR
> SyZ9GpkZge9YDw5_PIMAf7SLs3OLykUC_qNRDUCnRw7wTwsxiIT1V-
> R8sH17sTg$
> It also suggests an existing bug that it would be good to look into.
I don't think it's off-by-one. INPUT_CHn registers are listed by LSB, so channel 15 is 0x30F8 (LSB) / 0x30F9 (MSB).
The driver addresses the MSB and the part defaults to descending mode, so the access goes 0x30F9 -> 0x30F8.
0x30F9 is also the highest valid address per the datasheet, so max_register looks correct same for AD3530R's 0xF9.
Does that match our understanding, or am I missing a case?
>
> >
> > Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes
> > together followed by "bank" 1). Jonathan, what's your preference here?
> Nuno, David?
> That is how people will typically check them vs the datasheet so I agree with
> numeric order. Maybe with a comment at the top about there effectively
> being two banks. Many of the registers are effectively copies for the new
> channels but not all of them, so a macro approach would probably be even
> more confusing.
>
> Jonathan
^ permalink raw reply
* Re: [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: sashiko-bot @ 2026-06-25 10:10 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, devicetree, robh, dri-devel
In-Reply-To: <20260625094449.708386-6-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The DC8000 panel enable, CRTC begin, and CRTC flush operations use incorrect registers and bits, directly contradicting the commit message and breaking hardware functionality.
- [Medium] The hw_irqs variable is passed to regmap_read() uninitialized and used without checking for read failures.
Pre-existing issues:
- [High] The DC8200 primary plane disable function erroneously sets the enable bit instead of clearing it, keeping the plane active.
- [High] The IRQ handler unconditionally dereferences dc->drm_dev, but the interrupt is enabled before dc->drm_dev is allocated and remains active after it is freed.
--
commit a518460571afb18a0b4ff8e14af894a66907ebde
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
controller (DC8000 generation) whose register layout differs from
the DC8200 in several important ways:
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
[Severity: High]
Do the functions implemented in this patch use the correct registers and bits
as described in the commit message?
In vs_dc8000_panel_enable_ex(), the code sets a reset bit
(VSDC_FB_CONFIG_RESET) in VSDC_FB_CONFIG instead of writing to PANEL_CONFIG.
Additionally, vs_dc8000_crtc_begin() and vs_dc8000_crtc_flush() use an
unmentioned VALID bit (VSDC_FB_CONFIG_VALID), and clear it after updates
complete, which seems to invert normal latch semantics.
Could this mismatch prevent the display panel from enabling properly?
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa1..d2fd8e4dff242 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_dc8200.o vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_dc8000.o vs_drm.o vs_hwdb.o \
[Severity: High]
This is a pre-existing issue, but while reviewing the driver files included
here, I noticed a potential problem in
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex().
The function appears to call regmap_set_bits() on VSDC_FB_CONFIG_EX_FB_EN
instead of regmap_clear_bits():
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex() {
...
regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
VSDC_FB_CONFIG_EX_FB_EN);
...
}
Does this erroneously keep the primary plane active when the DRM framework
expects it to be turned off, potentially breaking power management?
> 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_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index fd1f5fe67a68b..9499fffbca58e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -134,7 +134,10 @@ 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 (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
[Severity: High]
This is a pre-existing issue, but I noticed a potential lifecycle regression
in vs_dc_probe() just below this block.
The function calls devm_request_irq() to register vs_dc_irq_handler() before
calling vs_drm_initialize(), which is responsible for allocating and assigning
dc->drm_dev.
If an interrupt fires during this window, for example if the bootloader left
VSYNC interrupts enabled, the handler is invoked:
vs_drm.c:vs_drm_handle_irq() {
...
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
...
}
Will this unconditionally dereference dc->drm_dev and cause a NULL pointer
dereference before vs_drm_initialize() has completed?
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW capability\n");
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 0000000000000..fbe0fa516cac9
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,86 @@
[ ... ]
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
[Severity: Medium]
Is it safe to use hw_irqs here if regmap_read() fails?
If regmap_read() returns an error code, hw_irqs will remain uninitialized
stack memory.
The function then proceeds to bitwise-AND this uninitialized value to
determine which VSYNC interrupts fired:
for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
unified |= VSDC_IRQ_VSYNC(i);
}
Could this result in spurious VSYNC events being dispatched to the DRM core if
a read failure occurs?
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
> +
> + return unified;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-ab2: Enable MU2 for DSP communication
From: Daniel Baluta @ 2026-06-25 10:13 UTC (permalink / raw)
To: shengjiu.wang, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625054709.301209-1-shengjiu.wang@oss.nxp.com>
On 6/25/26 08:47, shengjiu.wang@oss.nxp.com wrote:
> [You don't often get email from shengjiu.wang@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> Enable the MU2 (Message Unit 2) node on the i.MX8MP Audio Board v2.
> MU2 is required for inter-processor communication between the
> application CPU and the HiFi4 DSP, allowing DSP firmware to exchange
> control and status messages with the Linux host.
>
> Without this change, the DSP driver cannot establish the message
> channel and DSP audio processing is non-functional.
>
> Fixes: bf68c18150efc ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Abel Vesa @ 2026-06-25 10:12 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610-eliza_dt-v1-1-7bb72b75fc5b@oss.qualcomm.com>
On 26-06-10 17:40:09, Krishna Chaitanya Chundru wrote:
> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
> the GCC clock references to use the newly added PHY nodes instead of
> placeholder zeros.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> This patch depends on https://lore.kernel.org/all/20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com/
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 359 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 357 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 7e97361a5dc5..2a51da62270d 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -610,8 +610,8 @@ gcc: clock-controller@100000 {
>
> clocks = <&bi_tcxo_div2>,
> <&sleep_clk>,
> - <0>,
> - <0>,
> + <&pcie0_phy>,
> + <&pcie1_phy>,
> <&ufs_mem_phy 0>,
> <&ufs_mem_phy 1>,
> <&ufs_mem_phy 2>,
> @@ -716,6 +716,361 @@ mmss_noc: interconnect@1780000 {
> #interconnect-cells = <2>;
> };
>
> + pcie0: pcie@1c00000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c00000 0 0x3000>,
> + <0 0x40000000 0 0xf1d>,
> + <0 0x40000f20 0 0xa8>,
> + <0 0x40001000 0 0x1000>,
> + <0 0x40100000 0 0x100000>,
> + <0 0x01c03000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x40200000 0 0x100000>,
> + <0x02000000 0 0x40300000 0 0x40300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_0_BCR>,
> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_0 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
> +
> + operating-points-v2 = <&pcie0_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1480 0x1>,
> + <0x100 &apps_smmu 0x1481 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <0>;
> + num-lanes = <1>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
> +
No pinctrl states?
> +
> + pcie1: pcie@1c08000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c08000 0 0x3000>,
> + <0 0x44000000 0 0xf1d>,
> + <0 0x44000f20 0 0xa8>,
> + <0 0x44001000 0 0x1000>,
> + <0 0x44100000 0 0x100000>,
> + <0 0x01c0b000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_1_BCR>,
> + <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_1 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_1 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_1_GDSC>;
> +
> + operating-points-v2 = <&pcie1_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1400 0x1>,
> + <0x100 &apps_smmu 0x1401 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <1>;
> + num-lanes = <2>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
No pinctrl states?
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Konrad Dybcio @ 2026-06-25 10:18 UTC (permalink / raw)
To: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio
Cc: Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On 6/23/26 4:52 PM, Hans de Goede wrote:
> Hi All,
>
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.
>
> It might still be interesting to at least parse the ACPI tables and make
> the ACPI fwnodes available for device-drivers to use. I call this DT-ACPI
> hybrid mode.
>
> This mainly is an experiment for now and possibly a method for accelerating
> the ongoing effort to run Linux on currently available Snapdragon laptops.
I like the part where the ACPI tables are parsed and are visible to
Linux (so that the user can e.g. do acpidump even though DT is in use,
since the tables are in memory anyway)
I think the 'hybrid enumeration path' is a cool technical experiment,
which lets the user skip _some parts_ of writing a device tree, but
the benefits are too minor - we can only make use of this for devices
that already have ACPI support in Linux and whose nodes fit within the
"describe the actual hw and how it's wired up, not the functions it
exposes" model (because on Windows that all ends up being hijacked by
the PEP driver or something similar in the chain).
This is natural for DT, but not so much for ACPI
The hid-over-i2c example you gave looks useful on the surface, but
if the user already has to have the knowledge and skills to grab and
decompile the tables, assess the right path for the device and still
have to put it in the DT (which again, they would have had to create
at this point) after all, they may as well take the 40 extra seconds
as a single-time cost to fill in the i2c address and interrupt source
to create a valid/full DT node.
The path lookup mechanisms relies on the paths remaining stable,
which I would assume should be the case, but I wouldn't bet money
on it _always_ being the case.
To put it simply, I don't think we should spend time on trying to
forcefully make the incomplete (actually incomplete, since Windows
today loads ACPI fragments sourced from Windows Update at runtime
and relies on many drivers having hardcoded data) DSDTs be any
useful, because in their current form, we would need to rely on
quasi-boardfiles for most things anyway.
If we need to provide the firmware description (DT) externally
anyway, let's just stick to that alone.
Konrad
^ permalink raw reply
* Re: [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: sashiko-bot @ 2026-06-25 10:22 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, robh, devicetree, dri-devel
In-Reply-To: <20260625094449.708386-7-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added DCUltraLite chip restricts the max cursor size to 32x32, but the driver does not configure `drm->mode_config.cursor_width` or `cursor_height`. DRM core defaults to 64x64 when these fields are 0. This incorrectly exposes a `DRM_CAP_CURSOR_WIDTH` of 64 to userspace, causing atomic commits with 64x64 hardware cursors to be rejected with `-EINVAL`, breaking display compositors.
--
commit a3c0d8a714c977c54ec25009535f44e9ded7c881
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DCUltraLite chip identity to HWDB
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 91524d16f7785..7d630a667a3f0 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -129,6 +129,16 @@ static struct vs_chip_identity vs_chip_identities[] = {
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = 0x0, /* DCUltraLite */
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .generation = VSDC_GEN_DC8000,
> + .display_count = 1,
> + .max_cursor_size = 32,
[Severity: High]
Does this code expose an incorrect DRM_CAP_CURSOR_WIDTH to userspace?
Looking at vs_mode_config_init() in drivers/gpu/drm/verisilicon/vs_drm.c,
the driver does not seem to configure drm->mode_config.cursor_width or
cursor_height:
drivers/gpu/drm/verisilicon/vs_drm.c:vs_mode_config_init() {
...
drm->mode_config.helper_private = &vs_mode_config_helper_funcs;
}
When these fields are 0, the DRM core defaults to 64x64. This means userspace
compositors might query the capability, receive 64x64, and attempt to commit
a 64x64 hardware cursor.
If this new chip restricts the max cursor size to 32x32, will the driver's
atomic check reject the 64x64 state and break display compositors?
> + .formats = &vs_formats_no_yuv444,
> + },
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Philipp Zabel @ 2026-06-25 10:22 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], mturquette@baylibre.com,
sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Edgar Lee [李承諭],
afaerber@suse.com, Jyan Chou [周芷安],
bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <f3b747e20110424c8a434cbd271edb87@realtek.com>
On Do, 2026-06-25 at 10:05 +0000, Yu-Chun Lin [林祐君] wrote:
> Hi Philipp,
>
> > On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > > From: Cheng-Yu Lee <cylee12@realtek.com>
> > >
> > > Add support for the ISO (Isolation) domain reset controller on the
> > > Realtek
> > > RTD1625 SoC.
> > >
> > > The reset controller shares the same register space with the ISO clock
> > > controller. To handle this shared register space, the reset driver is
> > > implemented as an auxiliary driver. It will be instantiated and probed
> > > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> > >
> > > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > ---
> > > Changes in v9:
> > > - Extract reset-related code from the previous clock driver patch
> > > (formerly patch 9 in v8).
> > > ---
> > > drivers/reset/realtek/Makefile | 2 +-
> > > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > > +++++++++++++++++++++++
> > > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > > drivers/reset/realtek/reset-rtd1625-iso.c
> > >
> > > diff --git a/drivers/reset/realtek/Makefile
> > > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > > 100644
> > > --- a/drivers/reset/realtek/Makefile
> > > +++ b/drivers/reset/realtek/Makefile
> > > @@ -1,3 +1,3 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +reset-rtd1625-iso.o
> >
> > Is there any benefit to these two being separate modules?
> > I suggest you merge them into one: reset-rtd1625.o
> >
>
> If I merge them into a single 'reset-rtd1625' module,
> both the 'crt' and 'iso' clock drivers would trigger the probe
> process for the same reset driver name, which would lead to a
> duplicate driver registration error.
What do you mean by duplicate driver registration error?
There would only be one auxiliary_driver, with support for all three
auxiliary_device_id's.
regards
Philipp
^ permalink raw reply
* [PATCH] dt-bindings: arm: qcom: sort compatibles alphabetically by base SoC
From: Kathiravan Thirumoorthy @ 2026-06-25 10:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio,
Kathiravan Thirumoorthy
The compatible entries in qcom.yaml were not in alphabetical order by
their base SoC compatible string (the last const: qcom,* in each block),
making the file harder to audit and maintain. Sort the entries for
better maintenance.
No functional change; reordering only.
Assisted-by: Claude:claude-sonnet-4-6
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 490 ++++++++++++------------
1 file changed, 245 insertions(+), 245 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..dfbc82377fcf 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -49,18 +49,31 @@ properties:
- qcom,apq8074-dragonboard
- const: qcom,apq8074
- - items:
- - enum:
- - qcom,apq8060-dragonboard
- - qcom,msm8660-surf
- - const: qcom,msm8660
-
- items:
- enum:
- qcom,apq8084-mtp
- qcom,apq8084-sbc
- const: qcom,apq8084
+ - items:
+ - enum:
+ - sony,karin_windy
+ - const: qcom,apq8094
+
+ - items:
+ - enum:
+ - arrow,apq8096-db820c
+ - inforce,ifc6640
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096
+
+ - items:
+ - const: arrow,apq8096sg-db820c
+ - const: arrow,apq8096-db820c
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096sg
+ - const: qcom,apq8096
+
- items:
- enum:
- qcom,eliza-mtp
@@ -73,102 +86,126 @@ properties:
- items:
- enum:
- - qcom,mahua-crd
- - const: qcom,mahua
+ - 8dev,jalapeno
+ - alfa-network,ap120c-ac
+ - const: qcom,ipq4018
- items:
- enum:
- - fairphone,fp6
- - nothing,asteroids
- - const: qcom,milos
+ - qcom,ipq4019-ap-dk01.1-c1
+ - qcom,ipq4019-ap-dk04.1-c3
+ - qcom,ipq4019-ap-dk07.1-c1
+ - qcom,ipq4019-ap-dk07.1-c2
+ - qcom,ipq4019-dk04.1-c1
+ - const: qcom,ipq4019
- items:
- enum:
- - microsoft,dempsey
- - microsoft,makepeace
- - microsoft,moneypenny
- - motorola,falcon
- - samsung,ms013g
- - samsung,s3ve3g
- - const: qcom,msm8226
+ - qcom,ipq5018-rdp432-c2
+ - tplink,archer-ax55-v1
+ - const: qcom,ipq5018
- items:
- enum:
- - htc,memul
- - microsoft,superman-lte
- - microsoft,tesla
- - motorola,peregrine
- - samsung,matisselte
- - const: qcom,msm8926
- - const: qcom,msm8226
+ - qcom,ipq5210-rdp504
+ - const: qcom,ipq5210
- items:
- enum:
- - wingtech,wt82918hd
- - const: qcom,msm8929
+ - qcom,ipq5332-ap-mi01.2
+ - qcom,ipq5332-ap-mi01.3
+ - qcom,ipq5332-ap-mi01.6
+ - qcom,ipq5332-ap-mi01.9
+ - const: qcom,ipq5332
- items:
- enum:
- - asus,z00t
- - huawei,kiwi
- - longcheer,l9100
- - samsung,a7
- - sony,kanuti-tulip
- - square,apq8039-t2
- - wingtech,wt82918
- - wingtech,wt82918hdhw39
- - const: qcom,msm8939
+ - qcom,ipq5424-rdp466
+ - const: qcom,ipq5424
- items:
- enum:
- - sony,kugo-row
- - sony,suzu-row
- - const: qcom,msm8956
+ - qcom,ipq6018-cp01
+ - qcom,ipq6018-cp01-c1
+ - const: qcom,ipq6018
- items:
- enum:
- - qcom,msm8960-cdp
- - samsung,expressatt
- - const: qcom,msm8960
+ - mikrotik,rb3011
+ - qcom,ipq8064-ap148
+ - const: qcom,ipq8064
- items:
- enum:
- - sony,huashan
- - const: qcom,msm8960t
- - const: qcom,msm8960
+ - qcom,ipq8074-hk01
+ - qcom,ipq8074-hk10-c1
+ - qcom,ipq8074-hk10-c2
+ - const: qcom,ipq8074
- items:
- enum:
- - lge,hammerhead
- - samsung,hlte
- - sony,xperia-amami
- - sony,xperia-honami
- - sony,xperia-togari
- - const: qcom,msm8974
+ - qcom,ipq9574-ap-al02-c2
+ - qcom,ipq9574-ap-al02-c2-emmc
+ - qcom,ipq9574-ap-al02-c6
+ - qcom,ipq9574-ap-al02-c7
+ - qcom,ipq9574-ap-al02-c7-emmc
+ - qcom,ipq9574-ap-al02-c8
+ - qcom,ipq9574-ap-al02-c9
+ - const: qcom,ipq9574
- items:
- enum:
- - fairphone,fp2
- - htc,m8
- - oneplus,bacon
- - samsung,klte
- - sony,xperia-aries
- - sony,xperia-castor
- - sony,xperia-leo
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,ipq9650-rdp488
+ - const: qcom,ipq9650
- items:
- enum:
- - samsung,kltechn
- - const: samsung,klte
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,kaanapali-mtp
+ - qcom,kaanapali-qrd
+ - const: qcom,kaanapali
- items:
- enum:
- - longcheer,l9360
- - const: qcom,msm8976
+ - qcom,mahua-crd
+ - const: qcom,mahua
+
+ - description: Sierra Wireless MangOH Green with WP8548 Module
+ items:
+ - const: swir,mangoh-green-wp8548
+ - const: swir,wp8548
+ - const: qcom,mdm9615
+
+ - items:
+ - enum:
+ - fairphone,fp6
+ - nothing,asteroids
+ - const: qcom,milos
+
+ - items:
+ - enum:
+ - microsoft,dempsey
+ - microsoft,makepeace
+ - microsoft,moneypenny
+ - motorola,falcon
+ - samsung,ms013g
+ - samsung,s3ve3g
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - htc,memul
+ - microsoft,superman-lte
+ - microsoft,tesla
+ - motorola,peregrine
+ - samsung,matisselte
+ - const: qcom,msm8926
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - qcom,apq8060-dragonboard
+ - qcom,msm8660-surf
+ - const: qcom,msm8660
- items:
- enum:
@@ -217,11 +254,28 @@ properties:
- xiaomi,tiare
- const: qcom,msm8917
+ - items:
+ - enum:
+ - wingtech,wt82918hd
+ - const: qcom,msm8929
+
- items:
- enum:
- xiaomi,land
- const: qcom,msm8937
+ - items:
+ - enum:
+ - asus,z00t
+ - huawei,kiwi
+ - longcheer,l9100
+ - samsung,a7
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - wingtech,wt82918
+ - wingtech,wt82918hdhw39
+ - const: qcom,msm8939
+
- items:
- enum:
- flipkart,rimob
@@ -232,6 +286,57 @@ properties:
- xiaomi,vince
- const: qcom,msm8953
+ - items:
+ - enum:
+ - sony,kugo-row
+ - sony,suzu-row
+ - const: qcom,msm8956
+
+ - items:
+ - enum:
+ - qcom,msm8960-cdp
+ - samsung,expressatt
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - sony,huashan
+ - const: qcom,msm8960t
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - lge,hammerhead
+ - samsung,hlte
+ - sony,xperia-amami
+ - sony,xperia-honami
+ - sony,xperia-togari
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - fairphone,fp2
+ - htc,m8
+ - oneplus,bacon
+ - samsung,klte
+ - sony,xperia-aries
+ - sony,xperia-castor
+ - sony,xperia-leo
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - samsung,kltechn
+ - const: samsung,klte
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - longcheer,l9360
+ - const: qcom,msm8976
+
- items:
- enum:
- lg,bullhead
@@ -240,11 +345,6 @@ properties:
- xiaomi,libra
- const: qcom,msm8992
- - items:
- - enum:
- - sony,karin_windy
- - const: qcom,apq8094
-
- items:
- enum:
- huawei,angler
@@ -256,20 +356,6 @@ properties:
- sony,suzuran-row
- const: qcom,msm8994
- - items:
- - enum:
- - arrow,apq8096-db820c
- - inforce,ifc6640
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096
-
- - items:
- - const: arrow,apq8096sg-db820c
- - const: arrow,apq8096-db820c
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096sg
- - const: qcom,apq8096
-
- items:
- enum:
- oneplus,oneplus3
@@ -303,86 +389,6 @@ properties:
- xiaomi,sagit
- const: qcom,msm8998
- - items:
- - enum:
- - 8dev,jalapeno
- - alfa-network,ap120c-ac
- - const: qcom,ipq4018
-
- - items:
- - enum:
- - qcom,ipq4019-ap-dk01.1-c1
- - qcom,ipq4019-ap-dk04.1-c3
- - qcom,ipq4019-ap-dk07.1-c1
- - qcom,ipq4019-ap-dk07.1-c2
- - qcom,ipq4019-dk04.1-c1
- - const: qcom,ipq4019
-
- - items:
- - enum:
- - qcom,ipq5018-rdp432-c2
- - tplink,archer-ax55-v1
- - const: qcom,ipq5018
-
- - items:
- - enum:
- - qcom,ipq5210-rdp504
- - const: qcom,ipq5210
-
- - items:
- - enum:
- - qcom,ipq5332-ap-mi01.2
- - qcom,ipq5332-ap-mi01.3
- - qcom,ipq5332-ap-mi01.6
- - qcom,ipq5332-ap-mi01.9
- - const: qcom,ipq5332
-
- - items:
- - enum:
- - qcom,ipq5424-rdp466
- - const: qcom,ipq5424
-
- - items:
- - enum:
- - mikrotik,rb3011
- - qcom,ipq8064-ap148
- - const: qcom,ipq8064
-
- - items:
- - enum:
- - qcom,ipq8074-hk01
- - qcom,ipq8074-hk10-c1
- - qcom,ipq8074-hk10-c2
- - const: qcom,ipq8074
-
- - items:
- - enum:
- - qcom,ipq9574-ap-al02-c2
- - qcom,ipq9574-ap-al02-c2-emmc
- - qcom,ipq9574-ap-al02-c6
- - qcom,ipq9574-ap-al02-c7
- - qcom,ipq9574-ap-al02-c7-emmc
- - qcom,ipq9574-ap-al02-c8
- - qcom,ipq9574-ap-al02-c9
- - const: qcom,ipq9574
-
- - items:
- - enum:
- - qcom,ipq9650-rdp488
- - const: qcom,ipq9650
-
- - items:
- - enum:
- - qcom,kaanapali-mtp
- - qcom,kaanapali-qrd
- - const: qcom,kaanapali
-
- - description: Sierra Wireless MangOH Green with WP8548 Module
- items:
- - const: swir,mangoh-green-wp8548
- - const: swir,wp8548
- - const: qcom,mdm9615
-
- description: Qualcomm Technologies, Inc. Robotics RB1
items:
- enum:
@@ -403,6 +409,20 @@ properties:
- thundercomm,rubikpi3
- const: qcom,qcm6490
+ - items:
+ - enum:
+ - qcom,qcs404-evb-1000
+ - qcom,qcs404-evb-4000
+ - const: qcom,qcs404-evb
+ - const: qcom,qcs404
+
+ - items:
+ - enum:
+ - arduino,monza
+ - qcom,monaco-evk
+ - qcom,qcs8300-ride
+ - const: qcom,qcs8300
+
- description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
items:
- enum:
@@ -416,6 +436,31 @@ properties:
- qcom,qru1000-idp
- const: qcom,qru1000
+ - items:
+ - enum:
+ - qcom,sa8155p-adp
+ - const: qcom,sa8155p
+
+ - items:
+ - enum:
+ - qcom,sa8295p-adp
+ - qcom,sa8540p-ride
+ - const: qcom,sa8540p
+
+ - items:
+ - enum:
+ - qcom,sa8775p-ride
+ - qcom,sa8775p-ride-r3
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
+ - qcom,lemans-evk
+ - qcom,qcs9100-ride
+ - qcom,qcs9100-ride-r3
+ - const: qcom,qcs9100
+ - const: qcom,sa8775p
+
- description: Qualcomm AR2 Gen1 platform
items:
- enum:
@@ -828,14 +873,6 @@ properties:
- const: google,zombie-sku514
- const: qcom,sc7280
- - description: Xiaomi Poco F1
- items:
- - enum:
- - xiaomi,beryllium-ebbg
- - xiaomi,beryllium-tianma
- - const: xiaomi,beryllium
- - const: qcom,sdm845
-
- items:
- enum:
- lenovo,flex-5g
@@ -853,6 +890,11 @@ properties:
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
+ - items:
+ - enum:
+ - inforce,ifc6560
+ - const: qcom,sda660
+
- items:
- enum:
- lenovo,tbx605f
@@ -867,11 +909,6 @@ properties:
- sony,voyager-row
- const: qcom,sdm630
- - items:
- - enum:
- - inforce,ifc6560
- - const: qcom,sda660
-
- items:
- enum:
- fairphone,fp3
@@ -899,74 +936,13 @@ properties:
- const: google,bonito
- const: qcom,sdm670
- - items:
- - enum:
- - qcom,sdx55-mtp
- - qcom,sdx55-telit-fn980-tlb
- - qcom,sdx55-t55
- - const: qcom,sdx55
-
- - items:
- - enum:
- - qcom,sdx65-mtp
- - const: qcom,sdx65
-
- - items:
- - enum:
- - qcom,sdx75-idp
- - const: qcom,sdx75
-
- - items:
- - enum:
- - qcom,ipq6018-cp01
- - qcom,ipq6018-cp01-c1
- - const: qcom,ipq6018
-
- - items:
- - enum:
- - qcom,qcs404-evb-1000
- - qcom,qcs404-evb-4000
- - const: qcom,qcs404-evb
- - const: qcom,qcs404
-
- - items:
- - enum:
- - arduino,monza
- - qcom,monaco-evk
- - qcom,qcs8300-ride
- - const: qcom,qcs8300
-
- - items:
- - enum:
- - qcom,qcs615-ride
- - qcom,talos-evk
- - const: qcom,qcs615
- - const: qcom,sm6150
-
- - items:
- - enum:
- - qcom,sa8155p-adp
- - const: qcom,sa8155p
-
- - items:
- - enum:
- - qcom,sa8295p-adp
- - qcom,sa8540p-ride
- - const: qcom,sa8540p
-
- - items:
- - enum:
- - qcom,sa8775p-ride
- - qcom,sa8775p-ride-r3
- - const: qcom,sa8775p
-
- - items:
+ - description: Xiaomi Poco F1
+ items:
- enum:
- - qcom,lemans-evk
- - qcom,qcs9100-ride
- - qcom,qcs9100-ride-r3
- - const: qcom,qcs9100
- - const: qcom,sa8775p
+ - xiaomi,beryllium-ebbg
+ - xiaomi,beryllium-tianma
+ - const: xiaomi,beryllium
+ - const: qcom,sdm845
- items:
- enum:
@@ -989,6 +965,23 @@ properties:
- xiaomi,polaris
- const: qcom,sdm845
+ - items:
+ - enum:
+ - qcom,sdx55-mtp
+ - qcom,sdx55-telit-fn980-tlb
+ - qcom,sdx55-t55
+ - const: qcom,sdx55
+
+ - items:
+ - enum:
+ - qcom,sdx65-mtp
+ - const: qcom,sdx65
+
+ - items:
+ - enum:
+ - qcom,sdx75-idp
+ - const: qcom,sdx75
+
- items:
- enum:
- oneplus,billie2
@@ -1024,6 +1017,13 @@ properties:
- xiaomi,willow
- const: qcom,sm6125
+ - items:
+ - enum:
+ - qcom,qcs615-ride
+ - qcom,talos-evk
+ - const: qcom,qcs615
+ - const: qcom,sm6150
+
- items:
- enum:
- sony,pdx213
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260623-reorg_qcom_binding-0648bdef8db8
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 10:34 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, linux-input, lee, linux-leds, robh, conor+dt,
devicetree
In-Reply-To: <20260625081812.33474-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The YAML schema introduces a `ports` wrapper node for the `audio-codec`, which conflicts with the original TXT binding and existing device trees that define `port@X` directly as children.
- [Medium] The schema explicitly expects the power button subnode to be named exactly `key-power`, but the in-tree device tree uses `button`.
- [Medium] The `spi-cs-high` property, which is physically required by the hardware and was explicitly listed as required in the legacy text binding, has been omitted from the `required` list in the YAML schema.
--
commit 30a40e2d4eb937fd9bbca306ed8246e061a54ab4
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
[Severity: Medium]
Will this break validation for existing device trees?
The legacy text binding example shows port@0 and port@1 directly under the
audio-codec node, but this schema requires them to be wrapped in a ports
node. Because additionalProperties is set to false on audio-codec, direct
port@X nodes in existing device trees will be rejected.
[ ... ]
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
[Severity: Medium]
Is it intentional to restrict the subnode name strictly to key-power?
Existing in-tree device trees use button for this node. By strictly matching
key-power, existing configurations will be rejected as an undocumented
property during schema validation.
[ ... ]
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
[Severity: Medium]
Does this schema incorrectly omit spi-cs-high from the required list?
The legacy text binding explicitly listed spi-cs-high as a required property.
Without it, incomplete device trees lacking this hardware-critical property
will incorrectly pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=3
^ permalink raw reply
* [PATCH v6 0/3] pwm: add support for Andes platform
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:35 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
The ATCPIT100 is a set of compact multi-function timers, which can be
a simple timer or PWM, or a combination of the timer and the PWM. This
IP block is a core component of the Andes AE350 platform, which serves
as a reference architecture for SoC designs. The QiLai SoC also
integrates this controller.
This device driver was previously part of the Linux Kernel, and the
compatible was its IP name "andestech,atcpit100". However, the driver
and its binding were removed due to the deprecation of the NDS32
architecture [1]. Although Andes now dedicates our effort on RISC-V,
ATCPIT100 is still one of our peripheral IPs, and that's why we are
re-introducing it now. Since only using the IP block name as the
compatible is forbidden now, change the compatible to
"andestech,ae350-pwm" and "andestech,qilai-pwm".
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
Changes in v6:
- Rebased on ukleinek/pwm/for-next.
- (2/3)
- Round a too-large period or duty cycle down to the largest achievable
value, and emulate 0%/100% relative duty cycles by parking the channel,
instead of erroring out. (Uwe)
- Choose the period from the requested period alone, so it no longer
depends on the requested duty cycle. (Uwe)
- Convert the period to ticks and compute the high/low phases in the tick
domain to avoid rounding errors. (Uwe)
- Reconstruct the period in .get_state() with a single DIV_ROUND_UP_ULL()
over both phases, shared by both polarities, and read the control
register with FIELD_GET(). (Uwe)
- Set an out-of-range clock rate to 0 so that source cannot be selected,
and name both rates in the "no usable clock" error message. (Uwe)
- Rename to_andes_pwm() to andes_pwm_from_chip(). (Uwe)
- Capitalize error messages. (Uwe)
- Tidy up the in-function comment and the limitations list.
- Link to v5: https://patch.msgid.link/20260330-andes-pwm-v5-0-01c59a659d2c@andestech.com
Changes in v5:
- Rebased on ukleinek/pwm/for-next
- (1/3)
- Added Rob's reviewed-by tag.
- Link to v4: https://patch.msgid.link/20260204-andes-pwm-v4-0-67016bb13555@andestech.com
Changes in v4:
- Updated cover letter title and its commit message.
- (1/3)
- Updated the compatibles and the binding file name.
- Added the description to the binding.
- Corrected device register size.
- Dropped the changes to the MAINTAINERS file.
- (2/3)
- Updated the driver name.
- Made the driver support inversed polarity.
- Changed the clock selection algorithm.
- Made the configuration depend on ARCH_ANDES, instead of RISCV. (Krzysztof)
- Dropped the changes to the MAINTAINERS file.
- (3/3) (new)
- Collected all changes to the MAINTAINERS file into a single patch.
- Link to v3: https://patch.msgid.link/20250123193534.874256-1-ben717@andestech.com
Changes in v3:
- (1/2):
- modified the compatible string. (Krzysztof)
- (2/2):
- added a check for the clock rate to prevent the overflow warning.
(kernel test robot)
- removed the unnecessary check in .apply(). (kernel test robot)
- Link to v2: https://patch.msgid.link/20241202060147.1271264-1-ben717@andestech.com
Changes in v2:
- (1/2):
- changed "title" in the yaml file.
- removed vendor-specific property, and added clocks property.
- (2/2):
- added a description for hardware limitations. (Uwe)
- switched the clock parent depending on the requested setting
instead of statically configuring the clock source in DT. (Uwe)
- Link to v1: https://patch.msgid.link/20241028102721.1961289-1-ben717@andestech.com
---
Ben Zong-You Xie (3):
dt-bindings: pwm: add support for AE350 PWM controller
pwm: add Andes PWM driver support
MAINTAINERS: add an entry for Andes PWM driver
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++
MAINTAINERS | 6 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 343 +++++++++++++++++++++
5 files changed, 421 insertions(+)
---
base-commit: 898ab0f30e008e411ce93ddf81c4099abd9d4e46
change-id: 20260204-andes-pwm-10ea6611c3cf
Best regards,
--
Ben Zong-You Xie <ben717@andestech.com>
^ permalink raw reply
* [PATCH v6 1/3] dt-bindings: pwm: add support for AE350 PWM controller
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:35 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
The ATCPIT100 is a set of compact multi-function timers, which can be
used as pulse width modulators (PWM) as well as simple timers.
ATCPIT100 supports up to 4 PIT channels, and each PIT channel may be
configured as a simple timer or PWM, or a combination of the timer and
the PWM. This IP block is a core component of the Andes AE350 platform,
which serves as a reference architecture for SoC designs. The QiLai SoC
also integrates this controller.
The binding introduces the following compatible strings:
- "andestech,qilai-pwm": For the implementation integrated into the
Andes QiLai SoC.
- "andestech,ae350-pwm": As a fallback compatible string representing
the base IP design used across the AE350 platform architecture.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
new file mode 100644
index 000000000000..287f3c62965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/andestech,ae350-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes PWM controller on AE350 platform
+
+description:
+ This controller has 4 channels and two clock sources. Each channel can
+ switch the clock source by programming the corresponding register.
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - andestech,qilai-pwm
+ - const: andestech,ae350-pwm
+ - const: andestech,ae350-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: APB bus clock
+ - description: External clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: extclk
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@f0400000 {
+ compatible = "andestech,ae350-pwm";
+ reg = <0xf0400000 0x100000>;
+ #pwm-cells = <3>;
+ clocks = <&pclk>, <&extclk>;
+ clock-names = "pclk", "extclk";
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v6 2/3] pwm: add Andes PWM driver support
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:36 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add a driver for the PWM controller found in Andes AE350 platforms and
QiLai SoCs.
The Andes PWM controller features:
- 4 independent channels.
- Dual clock source support (APB clock and external clock) to provide
a flexible range of frequencies.
- Support for normal and inversed polarity.
The driver implements the .apply() and .get_state() callbacks. Since the
clock source of each channel can be selected by programming the
register, clock selection logic is implemented to prioritize the
external clock to maximize the supported period range, falling back to
the APB clock for higher frequency requirements.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 343 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 354 insertions(+)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e8886a9b64d9..52dee4b7f081 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -73,6 +73,16 @@ config PWM_AIROHA
To compile this driver as a module, choose M here: the module
will be called pwm-airoha.
+config PWM_ANDES
+ tristate "Andes PWM support"
+ depends on ARCH_ANDES || COMPILE_TEST
+ help
+ Generic PWM framework driver for Andes platform, such as QiLai SoC
+ and AE350 platform.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-andes.
+
config PWM_APPLE
tristate "Apple SoC PWM support"
depends on ARCH_APPLE || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5630a521a7cf..c92369ee251d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
obj-$(CONFIG_PWM_ADP5585) += pwm-adp5585.o
obj-$(CONFIG_PWM_AIROHA) += pwm-airoha.o
+obj-$(CONFIG_PWM_ANDES) += pwm-andes.o
obj-$(CONFIG_PWM_APPLE) += pwm-apple.o
obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
diff --git a/drivers/pwm/pwm-andes.c b/drivers/pwm/pwm-andes.c
new file mode 100644
index 000000000000..580e673d2cff
--- /dev/null
+++ b/drivers/pwm/pwm-andes.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Andes PWM, used in Andes AE350 platform and QiLai SoC
+ *
+ * Copyright (C) 2026 Andes Technology Corporation.
+ *
+ * Limitations:
+ * - When disabling a channel, the current period is not completed and the
+ * output is driven to the PARK level (low when ANDES_PWM_CH_CTRL_PARK is
+ * clear, high when it is set).
+ * - The current period will be completed first if reconfiguring.
+ * - Further, if the reconfiguration changes the clock source, the output will
+ * not be the old one nor the new one. And the output will be the new one
+ * after writing to the reload register.
+ * - The hardware cannot run a 0% or 100% relative duty cycle; the driver
+ * emulates these by disabling the channel and parking the output at the
+ * constant level.
+ * - A period or duty cycle larger than the selected clock can represent is
+ * rounded down to the largest achievable value rather than rejected.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/math64.h>
+#include <linux/minmax.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#define ANDES_PWM_CH_ENABLE 0x1C
+#define ANDES_PWM_CH_ENABLE_PWM(ch) BIT(3 + (4 * (ch)))
+
+#define ANDES_PWM_CH_CTRL(ch) (0x20 + (0x10 * (ch)))
+#define ANDES_PWM_CH_CTRL_MODE_PWM BIT(2)
+#define ANDES_PWM_CH_CTRL_CLK BIT(3)
+#define ANDES_PWM_CH_CTRL_PARK BIT(4)
+#define ANDES_PWM_CH_CTRL_MASK GENMASK(4, 0)
+
+#define ANDES_PWM_CH_RELOAD(ch) (0x24 + (0x10 * (ch)))
+#define ANDES_PWM_CH_RELOAD_HIGH GENMASK(31, 16)
+#define ANDES_PWM_CH_RELOAD_LOW GENMASK(15, 0)
+
+#define ANDES_PWM_CH_COUNTER(ch) (0x28 + (0x10 * (ch)))
+
+#define ANDES_PWM_CH_MAX 4
+#define ANDES_PWM_CYCLE_MIN 1
+#define ANDES_PWM_CYCLE_MAX 0x10000
+
+struct andes_pwm {
+ struct regmap *regmap;
+ struct clk *pclk;
+ struct clk *extclk;
+ unsigned int pclk_rate;
+ unsigned int extclk_rate;
+};
+
+static const struct regmap_config andes_pwm_regmap_config = {
+ .name = "andes_pwm",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .pad_bits = 0,
+ .max_register = ANDES_PWM_CH_COUNTER(ANDES_PWM_CH_MAX - 1),
+ .cache_type = REGCACHE_NONE,
+};
+
+static inline struct andes_pwm *andes_pwm_from_chip(struct pwm_chip *chip)
+{
+ return pwmchip_get_drvdata(chip);
+}
+
+static int andes_pwm_enable(struct pwm_chip *chip, unsigned int channel,
+ bool enable)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+
+ return regmap_assign_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel), enable);
+}
+
+/*
+ * Hold the output at a constant level by parking the disabled channel. A
+ * disabled channel drives its output to the PARK level (low when @high is
+ * false, high when @high is true), which is used to emulate a 0% or 100%
+ * relative duty cycle.
+ */
+static int andes_pwm_park(struct pwm_chip *chip, unsigned int channel,
+ bool high)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+
+ regmap_assign_bits(ap->regmap, ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_PARK, high);
+
+ return andes_pwm_enable(chip, channel, false);
+}
+
+static int andes_pwm_config(struct pwm_chip *chip, unsigned int channel,
+ const struct pwm_state *state)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+ unsigned int clk_rate = ap->extclk_rate;
+ unsigned int ctrl = ANDES_PWM_CH_CTRL_MODE_PWM;
+ bool use_pclk = false;
+ u64 high_cycles;
+ u64 low_cycles;
+ u64 period_cycles;
+ u64 duty_cycles;
+ u32 reload;
+
+ /*
+ * Reload register for PWM mode:
+ *
+ * 31 : 16 15 : 0
+ * PWM16_Hi | PWM16_Lo
+ *
+ * The high duration is (PWM16_Hi + 1) cycles and the low duration is
+ * (PWM16_Lo + 1) cycles, so each phase spans ANDES_PWM_CYCLE_MIN to
+ * ANDES_PWM_CYCLE_MAX cycles. The hardware period (their sum) can reach
+ * 2 * ANDES_PWM_CYCLE_MAX cycles, but the PWM core requires the period
+ * to be chosen from the requested period alone, independent of the duty
+ * cycle. That holds only while both phases stay within
+ * ANDES_PWM_CYCLE_MAX for every duty split, so the usable period is
+ * capped at ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN cycles.
+ *
+ * The controller has two clock sources, the APB clock and an external
+ * clock. Since the external clock frequency must be slower than the APB
+ * clock, it is tried first for its wider period range; the APB clock is
+ * used only when the external clock is too fast to represent the period
+ * (it resolves fewer than two cycles) or is absent.
+ */
+ period_cycles = mul_u64_u64_div_u64(clk_rate, state->period,
+ NSEC_PER_SEC);
+ if (period_cycles < 2 * ANDES_PWM_CYCLE_MIN) {
+ use_pclk = true;
+ clk_rate = ap->pclk_rate;
+ period_cycles = mul_u64_u64_div_u64(clk_rate, state->period,
+ NSEC_PER_SEC);
+ if (period_cycles < 2 * ANDES_PWM_CYCLE_MIN)
+ return -EINVAL;
+ }
+
+ /*
+ * Round the period down to the largest value representable for every
+ * duty cycle, so the chosen period depends on the requested period
+ * alone. With both phases capped at ANDES_PWM_CYCLE_MAX, that bound is
+ * ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN cycles.
+ */
+ period_cycles = min_t(u64, period_cycles,
+ ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN);
+
+ /* The duty cycle cannot exceed the (possibly clamped) period. */
+ duty_cycles = mul_u64_u64_div_u64(clk_rate, state->duty_cycle,
+ NSEC_PER_SEC);
+ duty_cycles = min_t(u64, duty_cycles, period_cycles);
+ if (state->polarity == PWM_POLARITY_INVERSED) {
+ low_cycles = duty_cycles;
+ high_cycles = period_cycles - low_cycles;
+ } else {
+ high_cycles = duty_cycles;
+ low_cycles = period_cycles - high_cycles;
+ }
+
+ /*
+ * A zero-length phase means a 0% or 100% relative duty cycle, which the
+ * hardware cannot run. Emit the matching constant level by parking the
+ * channel: high_cycles == 0 stays low, low_cycles == 0 stays high.
+ */
+ if (!high_cycles)
+ return andes_pwm_park(chip, channel, false);
+ if (!low_cycles)
+ return andes_pwm_park(chip, channel, true);
+
+ /*
+ * If changing the clock source here, the output will not be the old one
+ * nor the new one. And the output will be the new one after writing to
+ * the reload register.
+ */
+ ctrl |= use_pclk ? ANDES_PWM_CH_CTRL_CLK : 0;
+ ctrl |= (state->polarity == PWM_POLARITY_INVERSED) ?
+ ANDES_PWM_CH_CTRL_PARK : 0;
+ regmap_update_bits(ap->regmap, ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_MASK, ctrl);
+ reload = FIELD_PREP(ANDES_PWM_CH_RELOAD_HIGH, high_cycles - 1) |
+ FIELD_PREP(ANDES_PWM_CH_RELOAD_LOW, low_cycles - 1);
+ regmap_write(ap->regmap, ANDES_PWM_CH_RELOAD(channel), reload);
+ return andes_pwm_enable(chip, channel, true);
+}
+
+static int andes_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ unsigned int channel = pwm->hwpwm;
+
+ if (!state->enabled) {
+ if (pwm->state.enabled)
+ andes_pwm_enable(chip, channel, false);
+
+ return 0;
+ }
+
+ return andes_pwm_config(chip, channel, state);
+}
+
+static int andes_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+ unsigned int channel = pwm->hwpwm;
+ unsigned int ctrl;
+ unsigned int clk_rate;
+ unsigned int reload;
+ u64 high_cycles;
+ u64 low_cycles;
+
+ regmap_read(ap->regmap, ANDES_PWM_CH_CTRL(channel), &ctrl);
+ clk_rate = FIELD_GET(ANDES_PWM_CH_CTRL_CLK, ctrl) ? ap->pclk_rate
+ : ap->extclk_rate;
+ if (!clk_rate) {
+ /*
+ * The selected clock source is unavailable, so the channel
+ * cannot be running; report it as disabled and avoid the
+ * division by zero below.
+ */
+ state->enabled = false;
+ state->period = 0;
+ state->duty_cycle = 0;
+ return 0;
+ }
+
+ state->enabled = regmap_test_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel)) > 0;
+ state->polarity = FIELD_GET(ANDES_PWM_CH_CTRL_PARK, ctrl) ?
+ PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ regmap_read(ap->regmap, ANDES_PWM_CH_RELOAD(channel), &reload);
+ high_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_HIGH, reload) + 1;
+ low_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_LOW, reload) + 1;
+
+ /*
+ * high_cycles and low_cycles are each at most ANDES_PWM_CYCLE_MAX
+ * (0x10000, 17 bits) and NSEC_PER_SEC is below 2^30, so the products
+ * below are safe from 64-bit overflow.
+ */
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ state->duty_cycle = DIV_ROUND_UP_ULL(low_cycles * NSEC_PER_SEC,
+ clk_rate);
+ else
+ state->duty_cycle = DIV_ROUND_UP_ULL(high_cycles * NSEC_PER_SEC,
+ clk_rate);
+
+ state->period = DIV_ROUND_UP_ULL((high_cycles + low_cycles) *
+ NSEC_PER_SEC, clk_rate);
+
+ return 0;
+}
+
+static const struct pwm_ops andes_pwm_ops = {
+ .apply = andes_pwm_apply,
+ .get_state = andes_pwm_get_state,
+};
+
+static int andes_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pwm_chip *chip;
+ struct andes_pwm *ap;
+ void __iomem *reg_base;
+ unsigned long pclk_rate;
+ unsigned long extclk_rate;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, ANDES_PWM_CH_MAX, sizeof(*ap));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ ap = andes_pwm_from_chip(chip);
+ reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(reg_base))
+ return dev_err_probe(dev, PTR_ERR(reg_base),
+ "Failed to map I/O space\n");
+
+ ap->pclk = devm_clk_get_enabled(dev, "pclk");
+ if (IS_ERR(ap->pclk))
+ return dev_err_probe(dev, PTR_ERR(ap->pclk),
+ "Failed to get APB clock\n");
+
+ ap->extclk = devm_clk_get_optional_enabled(dev, "extclk");
+ if (IS_ERR(ap->extclk))
+ return dev_err_probe(dev, PTR_ERR(ap->extclk),
+ "Failed to get external clock\n");
+
+ /*
+ * If the clock rate is greater than 10^9, there may be an overflow when
+ * calculating the cycles in andes_pwm_config()
+ */
+ pclk_rate = clk_get_rate(ap->pclk);
+ extclk_rate = clk_get_rate(ap->extclk);
+
+ ap->pclk_rate = pclk_rate > NSEC_PER_SEC ? 0 : pclk_rate;
+ ap->extclk_rate = extclk_rate > NSEC_PER_SEC ? 0 : extclk_rate;
+
+ if (!ap->pclk_rate && !ap->extclk_rate)
+ return dev_err_probe(dev, -EINVAL,
+ "No usable clock: pclk %lu Hz, extclk %lu Hz\n",
+ pclk_rate, extclk_rate);
+
+ ap->regmap = devm_regmap_init_mmio(dev, reg_base,
+ &andes_pwm_regmap_config);
+ if (IS_ERR(ap->regmap))
+ return dev_err_probe(dev, PTR_ERR(ap->regmap),
+ "Failed to initialize regmap\n");
+
+ chip->ops = &andes_pwm_ops;
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add PWM chip\n");
+
+ return 0;
+}
+
+static const struct of_device_id andes_pwm_of_match[] = {
+ { .compatible = "andestech,ae350-pwm" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, andes_pwm_of_match);
+
+static struct platform_driver andes_pwm_driver = {
+ .driver = {
+ .name = "andes_pwm",
+ .of_match_table = andes_pwm_of_match,
+ },
+ .probe = andes_pwm_probe,
+};
+module_platform_driver(andes_pwm_driver);
+
+MODULE_AUTHOR("Ben Zong-You Xie <ben717@andestech.com>");
+MODULE_DESCRIPTION("Andes PWM driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v6 3/3] MAINTAINERS: add an entry for Andes PWM driver
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:36 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add an entry for the Andes PWM driver to the MAINTAINERS file.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..2461683a5bbb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1874,6 +1874,12 @@ S: Supported
F: Documentation/devicetree/bindings/spi/andestech,ae350-spi.yaml
F: drivers/spi/spi-atcspi200.c
+ANDES PWM DRIVER
+M: Ben Zong-You Xie <ben717@andestech.com>
+S: Supported
+F: Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
+F: drivers/pwm/pwm-andes.c
+
ANDROID DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Arve Hjønnevåg <arve@android.com>
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 10:37 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <07fd4bcb-f55f-4856-9b93-7f4569a27b7f@oss.qualcomm.com>
On Wed, 2026-06-24 at 13:57 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:46 PM, Xin Xu wrote:
> > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > using GPIO84 as interrupt and GPIO76 as reset.
> >
> > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > ---
>
> [...]
>
> > + pm8008_default: pm8008-default-state {
> > + int-pins {
> > + pins = "gpio84";
> > + function = "gpio";
> > + bias-disable;
> > + drive-strength = <2>;
> > + input-enable;
> > + };
> > +
> > + reset-pins {
> > + pins = "gpio76";
> > + function = "gpio";
> > + bias-pull-up;
> > + drive-strength = <2>;
>
> nit: bias properties after drive-strength (I now noticed that 8250
> dtsi
> has it ""wrong"", we'll mass-touch it up once we have a tool for
> that..
> sorry for the trouble)
>
> otherwise
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
On Wed, 2026-06-24 at 14:00 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:46 PM, Xin Xu wrote:
> > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > using GPIO84 as interrupt and GPIO76 as reset.
> >
> > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > ---
>
> [...]
>
>
> > + pm8008_default: pm8008-default-state {
> > + int-pins {
> > + pins = "gpio84";
> > + function = "gpio";
> > + bias-disable;
> > + drive-strength = <2>;
> > + input-enable;
> > + };
>
> arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-boe.dtb: pinctrl@f100000
> (qcom,sm8250-pinctrl): pm8008-default-state: 'oneOf' conditional
> failed, one must be fixed:
> 'function' is a required property
> 'pins' is a required property
> Unevaluated properties are not allowed ('int-pins', 'reset-
> pins' were unexpected)
> False schema does not allow True
> from schema $id:
> http://devicetree.org/schemas/pinctrl/qcom,sm8250-pinctrl.yaml
>
> Please drop input-enable, it's not a thing on TLMM pins
>
> Konrad
Thank you for the review and the Reviewed-by tag!
I will fix these coding style issues (splitting the pinctrl nodes,
dropping input-enable, and reordering the bias properties) in the next
version.
Best regards,
Xin Xu
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: pwm: add support for AE350 PWM controller
From: sashiko-bot @ 2026-06-25 10:45 UTC (permalink / raw)
To: Ben Zong-You Xie via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625-andes-pwm-v6-1-3aef11711017@andestech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The DT binding defines a specific software use-case (PWM) rather than holistically describing the underlying multi-function hardware block (ATCPIT100), omitting inherent hardware properties like `interrupts`.
--
commit efdd46b6c3b84eb1768cdcc54800ffa3c62afeef
Author: Ben Zong-You Xie <ben717@andestech.com>
dt-bindings: pwm: add support for AE350 PWM controller
This commit adds the device tree binding for the ATCPIT100 PWM controller
used in the Andes AE350 platform and QiLai SoC.
> diff --git a/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
[ ... ]
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - andestech,qilai-pwm
> + - const: andestech,ae350-pwm
> + - const: andestech,ae350-pwm
[ ... ]
> +required:
> + - compatible
> + - reg
> + - "#pwm-cells"
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
[Severity: Medium]
The commit message mentions that the ATCPIT100 block is a set of
multi-function timers that can be used as PWMs or simple timers. Does
this binding restrict the hardware description to only the PWM software
use-case?
Since unevaluatedProperties is set to false and the properties block omits
inherent hardware properties like interrupts, will dtbs_check fail if a
device tree author attempts to accurately describe the full ATCPIT100
multi-function hardware block by wiring its interrupt lines?
Would it be better to describe the complete hardware capabilities upfront,
such as timer functionality and interrupts, to prevent redesigns breaking
backward compatibility (like transitioning to an MFD or adding #timer-cells)
when timer support is needed later?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-andes-pwm-v6-0-3aef11711017@andestech.com?part=1
^ permalink raw reply
* Re: [PATCH v6 2/3] pwm: add Andes PWM driver support
From: sashiko-bot @ 2026-06-25 10:46 UTC (permalink / raw)
To: Ben Zong-You Xie via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625-andes-pwm-v6-2-3aef11711017@andestech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver fails to update the hardware PARK level to the inactive state when disabling the PWM channel, leaving the output stuck ON or at the wrong polarity.
--
commit 6823cc7ba3d3233c8090db2e53dc0a9b52b74a25
Author: Ben Zong-You Xie <ben717@andestech.com>
pwm: add Andes PWM driver support
Add a driver for the PWM controller found in Andes AE350 platforms and
QiLai SoCs.
> diff --git a/drivers/pwm/pwm-andes.c b/drivers/pwm/pwm-andes.c
> new file mode 100644
> index 0000000000000..580e673d2cff0
> --- /dev/null
> +++ b/drivers/pwm/pwm-andes.c
[ ... ]
> +static int andes_pwm_config(struct pwm_chip *chip, unsigned int channel,
> + const struct pwm_state *state)
> +{
[ ... ]
> + /*
> + * A zero-length phase means a 0% or 100% relative duty cycle, which the
> + * hardware cannot run. Emit the matching constant level by parking the
> + * channel: high_cycles == 0 stays low, low_cycles == 0 stays high.
> + */
> + if (!high_cycles)
> + return andes_pwm_park(chip, channel, false);
> + if (!low_cycles)
> + return andes_pwm_park(chip, channel, true);
[Severity: High]
When configuring a 100 percent duty cycle, this code sets the PARK bit to the
active state to emulate the output. If the channel is subsequently disabled,
could the output remain stuck ON?
> +
> + /*
> + * If changing the clock source here, the output will not be the old one
[ ... ]
> +static int andes_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + unsigned int channel = pwm->hwpwm;
> +
> + if (!state->enabled) {
> + if (pwm->state.enabled)
> + andes_pwm_enable(chip, channel, false);
> +
> + return 0;
> + }
[Severity: High]
Does this early return path disable the channel but fail to update the
hardware's PARK bit to reflect the inactive state of the current polarity?
If the PWM was previously configured to 100 percent duty cycle where the PARK
bit was set active, it appears bypassing the PARK bit configuration on the
disable path leaves the output driven at the active level.
Additionally, if the polarity changes while the channel is disabled, will the
hardware's inactive level fail to update?
> +
> + return andes_pwm_config(chip, channel, state);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-andes-pwm-v6-0-3aef11711017@andestech.com?part=2
^ permalink raw reply
* [PATCH v19 0/7] coresight: ctcu: Enable byte-cntr function for TMC ETR
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Konrad Dybcio, Mike Leach, Krzysztof Kozlowski
The byte-cntr function provided by the CTCU device is used to count the
trace data entering the ETR. An interrupt is triggered if the data size
exceeds the threshold set in the BYTECNTRVAL register. The interrupt
handler counts the number of triggered interruptions.
Based on this concept, the irq_cnt can be used to determine whether
the etr_buf is full. The ETR device will be disabled when the active
etr_buf is nearly full or a timeout occurs. The nearly full buffer will
be switched to background after synced. A new buffer will be picked from
the etr_buf_list, then restart the ETR device.
The byte-cntr reading functions can access data from the synced and
deactivated buffer, transferring trace data from the etr_buf to userspace
without stopping the ETR device.
The byte-cntr read operation has integrated with the file node tmc_etr,
for example:
/dev/tmc_etr0
/dev/tmc_etr1
There are two scenarios for the tmc_etr file node with byte-cntr function:
1. BYTECNTRVAL register is configured and byte-cntr is enabled -> byte-cntr read
2. BYTECNTRVAL register is reset or byte-cntr is disabled -> original behavior
Shell commands to enable byte-cntr reading for etr0:
echo 1 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
echo 1 > /sys/bus/coresight/devices/etm0/enable_source
cat /dev/tmc_etr0
Reset the BYTECNTR register for etr0:
echo 0 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
---
Changes in v19:
1. coresight: tmc: add create/clean functions for etr_buf_list:
- Simplified the kernel-doc "Locking:" note on tmc_create_etr_buf_list()
and tmc_clean_etr_buf_list() to state only the required contract
(caller must guarantee exclusive access to drvdata->etr_buf_list),
dropping the over-specific call-path details.
- Lock the required code block in create/clean functions.
2. coresight: ctcu: enable byte-cntr for TMC ETR devices:
- Fixed a stale reading-state / double-free when irq_enabled was
cleared between prepare and unprepare: the byte-cntr read_unprepare
would return an error and tmc_read_unprepare_etr() would fall back
to the normal unprepare path, freeing drvdata->sysfs_buf while it
was still owned by the byte-cntr buffer list. irq_enabled_store()
now returns -EBUSY while byte_cntr_data->reading is set, so the flag
can no longer change mid-session, and tmc_read_unprepare_byte_cntr()
additionally guards on byte_cntr_data->reading.
- Moved enable_irq_wake()/disable_irq_wake() out of the
byte_cntr_data->spin_lock critical section in
tmc_read_prepare_byte_cntr()/tmc_read_unprepare_byte_cntr().
irq_set_irq_wake() may sleep on slow-bus irqchips, so it must not
be called under a raw spinlock. The threshold IRQ is already
disabled by the in-lock register write before disable_irq_wake() on
the unprepare path, so no wake event can race in the gap.
- Added a comment on the byte_cntr_sysfs_ops pointer documenting the
single-CTCU-instance-per-system assumption.
- Link to v18: https://lore.kernel.org/r/20260507-enable-byte-cntr-for-ctcu-v18-0-2b2d590463a3@oss.qualcomm.com
Changes in v18:
1. add a NULL check for the in_conns instance in patch 1.
2. fix a bug in patch 2: the tmc_alloc_etr_buf never return NULL and the
previous check for the return value is incorrect.
3. add more kernel_doc description for tmc_clean_etr_buf_list function
in patch 2
- Link to v17: https://lore.kernel.org/r/20260421-enable-byte-cntr-for-ctcu-v17-0-9cf36ff55fc0@oss.qualcomm.com
Changes in v17:
1. fix race issue during allocat buffer.
2. fix user after free issue observed when remove module.
- Link to v16: https://lore.kernel.org/r/20260323-enable-byte-cntr-for-ctcu-v16-0-7a413d211b8d@oss.qualcomm.com
Changes in v16:
1. Remove lock/unlock processes in patch "coresight: tmc: add create/clean
functions for etr_buf_list" because we are allocating/freeing memory.
- Link to v15: https://lore.kernel.org/r/20260313-enable-byte-cntr-for-ctcu-v15-0-1777f14ed319@oss.qualcomm.com
Changes in v15:
1. add lockdep_assert_held in patch "coresight: tmc: add create/clean
functions for etr_buf_list"
2. optimize tmc_clean_etr_buf_list function
3. optimize the patch "enable byte-cntr for TMC ETR devices" according
to Suzuki's comments
- call byte_cntr_sysfs_ops from etr_sysfs_ops
- optimize the lock usage in all functions
- remove the buf_node parameter in etr_drvdata, move it to
byte_cntr_data
- move the tmc_reset_sysfs_buf function to tmc-etr.c
- add a read flag to struct etr_buf_node to allow updating pos while
traversing etr_buf_list during data reads.
Link to v14: https://lore.kernel.org/r/20260309-enable-byte-cntr-for-ctcu-v14-0-c08823e5a8e6@oss.qualcomm.com
Changes in V14:
1. Drop the patch: integrate byte-cntr's sysfs_ops with tmc sysfs file_ops
2. Replace tmc_sysfs_ops with byte_cntr_sysfs_ops in byte_cntr_start
function and restore etr_sysfs_ops in byte_cntr_unprepare function.
3. Remove redundant checks in byte‑cntr functions.
Link to V13: https://lore.kernel.org/all/20260223-enable-byte-cntr-for-ctcu-v13-0-9cb44178b250@oss.qualcomm.com/
Changes in v13:
1. initilize the byte_cntr_data->raw_spin_lock before using.
2. replace kzalloc with kzalloc_obj.
Link to V12: https://lore.kernel.org/all/20260203-enable-byte-cntr-for-ctcu-v12-0-7bf81b86b70e@oss.qualcomm.com/
Changes in v12:
1. Add a new function for retrieving the CTCU's coresight_dev instead of
refactor the existing function.
Link to v11: https://lore.kernel.org/r/20260126-enable-byte-cntr-for-ctcu-v11-0-c0af66ba15cf@oss.qualcomm.com
Changes in v11:
1. Correct the description in patch1 for the function coresight_get_in_port.
2. Renaming the sysfs_ops to tmc_sysfs_ops per Suzuki's suggestion.
Link to v10: https://lore.kernel.org/r/20260122-enable-byte-cntr-for-ctcu-v10-0-22978e3c169f@oss.qualcomm.com
Changes in v10:
1. fix a free memory issue that is reported by robot for patch 2.
Link to v9: https://lore.kernel.org/r/20251224-enable-byte-cntr-for-ctcu-v9-0-886c4496fed4@oss.qualcomm.com
Changes in v9:
1. Drop the patch: add a new API to retrieve the helper device
2. Add a new patch to refactor the tmc_etr_get_catu_device function,
making it generic to support all types of helper devices associated with ETR.
3. Optimizing the code for creating irq_threshold sysfs node.
4. Remove interrupt-name property and obtain the IRQ based on the
in-port number.
Link to v8: https://lore.kernel.org/r/20251211-enable-byte-cntr-for-ctcu-v8-0-3e12ff313191@oss.qualcomm.com
Changes in V8:
1. Optimizing the patch 1 and patch 2 according to Suzuki's comments.
2. Combine the patch 3 and patch 4 together.
3. Rename the interrupt-name to prevent confusion, for example:etr0->etrirq0.
Link to V7 - https://lore.kernel.org/all/20251013-enable-byte-cntr-for-ctcu-v7-0-e1e8f41e15dd@oss.qualcomm.com/
Changes in V7:
1. rebased on tag next-20251010
2. updated info for sysfs node document
Link to V6 - https://lore.kernel.org/all/20250908-enable-byte-cntr-for-tmc-v6-0-1db9e621441a@oss.qualcomm.com/
Changes in V6:
1. rebased on next-20250905.
2. fixed the issue that the dtsi file has re-named from sa8775p.dtsi to
lemans.dtsi.
3. fixed some minor issues about comments.
Link to V5 - https://lore.kernel.org/all/20250812083731.549-1-jie.gan@oss.qualcomm.com/
Changes in V5:
1. Add Mike's reviewed-by tag for patchset 1,2,5.
2. Remove the function pointer added to helper_ops according to Mike's
comment, it also results the patchset has been removed.
3. Optimizing the paired create/clean functions for etr_buf_list.
4. Remove the unneeded parameter "reading" from the etr_buf_node.
Link to V4 - https://lore.kernel.org/all/20250725100806.1157-1-jie.gan@oss.qualcomm.com/
Changes in V4:
1. Rename the function to coresight_get_in_port_dest regarding to Mike's
comment (patch 1/10).
2. Add lock to protect the connections regarding to Mike's comment
(patch 2/10).
3. Move all byte-cntr functions to coresight-ctcu-byte-cntr file.
4. Add tmc_read_ops to wrap all read operations for TMC device.
5. Add a function in helper_ops to check whether the byte-cntr is
enabkled.
6. Call byte-cntr's read_ops if byte-cntr is enabled when reading data
from the sysfs node.
Link to V3 resend - https://lore.kernel.org/all/20250714063109.591-1-jie.gan@oss.qualcomm.com/
Changes in V3 resend:
1. rebased on next-20250711.
Link to V3 - https://lore.kernel.org/all/20250624060438.7469-1-jie.gan@oss.qualcomm.com/
Changes in V3:
1. The previous solution has been deprecated.
2. Add a etr_buf_list to manage allcated etr buffers.
3. Add a logic to switch buffer for ETR.
4. Add read functions to read trace data from synced etr buffer.
Link to V2 - https://lore.kernel.org/all/20250410013330.3609482-1-jie.gan@oss.qualcomm.com/
Changes in V2:
1. Removed the independent file node /dev/byte_cntr.
2. Integrated the byte-cntr's file operations with current ETR file
node.
3. Optimized the driver code of the CTCU that associated with byte-cntr.
4. Add kernel document for the export API tmc_etr_get_rwp_offset.
5. Optimized the way to read the rwp_offset according to Mike's
suggestion.
6. Removed the dependency of the dts patch.
Link to V1 - https://lore.kernel.org/all/20250310090407.2069489-1-quic_jiegan@quicinc.com/
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Jie Gan (7):
coresight: core: refactor ctcu_get_active_port and make it generic
coresight: tmc: add create/clean functions for etr_buf_list
coresight: tmc: introduce tmc_sysfs_ops to wrap sysfs read operations
coresight: etr: add a new function to retrieve the CTCU device
dt-bindings: arm: add an interrupt property for Coresight CTCU
coresight: ctcu: enable byte-cntr for TMC ETR devices
arm64: dts: qcom: lemans: add interrupts to CTCU device
.../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
.../bindings/arm/qcom,coresight-ctcu.yaml | 10 +
arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +
drivers/hwtracing/coresight/Makefile | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 27 ++
.../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 327 +++++++++++++++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 146 +++++++--
drivers/hwtracing/coresight/coresight-ctcu.h | 81 ++++-
drivers/hwtracing/coresight/coresight-priv.h | 2 +
drivers/hwtracing/coresight/coresight-tmc-core.c | 55 ++--
drivers/hwtracing/coresight/coresight-tmc-etr.c | 265 ++++++++++++++++-
drivers/hwtracing/coresight/coresight-tmc.h | 42 +++
12 files changed, 896 insertions(+), 73 deletions(-)
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260309-enable-byte-cntr-for-ctcu-ff86e6198b7f
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v19 1/7] coresight: core: refactor ctcu_get_active_port and make it generic
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Mike Leach
In-Reply-To: <20260625-enable-byte-cntr-for-ctcu-v19-0-8fbbf22e8381@oss.qualcomm.com>
Remove ctcu_get_active_port from CTCU module and add it to the core
framework.
The port number is crucial for the CTCU device to identify which ETR
it serves. With the port number we can correctly get required parameters
of the CTCU device in TMC module.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-core.c | 27 +++++++++++++++++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 19 +---------------
drivers/hwtracing/coresight/coresight-priv.h | 2 ++
3 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 6d65c43d574f..7a7a85acdca0 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -773,6 +773,33 @@ struct coresight_device *coresight_get_sink(struct coresight_path *path)
}
EXPORT_SYMBOL_GPL(coresight_get_sink);
+/**
+ * coresight_get_in_port: Find the input port number at @remote where the @csdev
+ * device is connected to.
+ *
+ * @csdev: csdev of the device.
+ * @remote: csdev of the remote device which is connected to @csdev.
+ *
+ * Return: port number upon success or -EINVAL for fail.
+ */
+int coresight_get_in_port(struct coresight_device *csdev,
+ struct coresight_device *remote)
+{
+ struct coresight_platform_data *pdata = remote->pdata;
+ int i;
+
+ for (i = 0; i < pdata->nr_inconns; ++i) {
+ if (!pdata->in_conns[i])
+ continue;
+
+ if (pdata->in_conns[i]->src_dev == csdev)
+ return pdata->in_conns[i]->dest_port;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(coresight_get_in_port);
+
u32 coresight_get_sink_id(struct coresight_device *csdev)
{
if (!csdev->ea)
diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
index 9043cad42f01..e8720026c9e3 100644
--- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
+++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
@@ -116,23 +116,6 @@ static int __ctcu_set_etr_traceid(struct coresight_device *csdev, u8 traceid, in
return 0;
}
-/*
- * Searching the sink device from helper's view in case there are multiple helper devices
- * connected to the sink device.
- */
-static int ctcu_get_active_port(struct coresight_device *sink, struct coresight_device *helper)
-{
- struct coresight_platform_data *pdata = helper->pdata;
- int i;
-
- for (i = 0; i < pdata->nr_inconns; ++i) {
- if (pdata->in_conns[i]->src_dev == sink)
- return pdata->in_conns[i]->dest_port;
- }
-
- return -EINVAL;
-}
-
static int ctcu_set_etr_traceid(struct coresight_device *csdev, struct coresight_path *path,
bool enable)
{
@@ -145,7 +128,7 @@ static int ctcu_set_etr_traceid(struct coresight_device *csdev, struct coresight
return -EINVAL;
}
- port_num = ctcu_get_active_port(sink, csdev);
+ port_num = coresight_get_in_port(sink, csdev);
if (port_num < 0)
return -EINVAL;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index dddac946659f..854c0a3cb080 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -155,6 +155,8 @@ void coresight_remove_links(struct coresight_device *orig,
u32 coresight_get_sink_id(struct coresight_device *csdev);
int coresight_path_assign_trace_id(struct coresight_path *path,
enum cs_mode mode);
+int coresight_get_in_port(struct coresight_device *csdev,
+ struct coresight_device *remote);
#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
int etm_readl_cp14(u32 off, unsigned int *val);
--
2.34.1
^ permalink raw reply related
* [PATCH v19 2/7] coresight: tmc: add create/clean functions for etr_buf_list
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Mike Leach
In-Reply-To: <20260625-enable-byte-cntr-for-ctcu-v19-0-8fbbf22e8381@oss.qualcomm.com>
Introduce functions for creating and inserting or removing the
etr_buf_node to/from the etr_buf_list.
The byte-cntr functionality requires two etr_buf to receive trace data.
The active etr_buf collects the trace data from source device, while the
byte-cntr reading function accesses the deactivated etr_buf after is
has been filled and synced, transferring data to the userspace.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tmc-core.c | 1 +
drivers/hwtracing/coresight/coresight-tmc-etr.c | 126 +++++++++++++++++++++++
drivers/hwtracing/coresight/coresight-tmc.h | 17 +++
3 files changed, 144 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index bc5a133ada3e..bc7dd676da47 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -835,6 +835,7 @@ static int __tmc_probe(struct device *dev, struct resource *res)
idr_init(&drvdata->idr);
mutex_init(&drvdata->idr_mutex);
dev_list = "tmc_etr";
+ INIT_LIST_HEAD(&drvdata->etr_buf_list);
break;
case TMC_CONFIG_TYPE_ETF:
desc.groups = coresight_etf_groups;
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 361a433e6f0c..9b3ef73e9cf2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1918,6 +1918,132 @@ const struct coresight_ops tmc_etr_cs_ops = {
.panic_ops = &tmc_etr_sync_ops,
};
+/**
+ * tmc_clean_etr_buf_list - clean the etr_buf_list.
+ * @drvdata: driver data of the TMC device.
+ *
+ * Remove all nodes from @drvdata->etr_buf_list and free their buffers.
+ * If a node holds the live sysfs_buf and the device is active, the node is
+ * removed but the buffer is not freed; ownership stays with drvdata->sysfs_buf.
+ *
+ * Locking: callers must guarantee exclusive access to @drvdata->etr_buf_list
+ * and must not hold @drvdata->spinlock. The spinlock is taken internally only
+ * to serialise the @drvdata->sysfs_buf accesses against the ETR sink
+ * enable/disable paths. Must be called from process context: buffers are freed
+ * with the lock released.
+ */
+void tmc_clean_etr_buf_list(struct tmc_drvdata *drvdata)
+{
+ struct etr_buf_node *nd, *next;
+ unsigned long flags;
+
+ list_for_each_entry_safe(nd, next, &drvdata->etr_buf_list, link) {
+ raw_spin_lock_irqsave(&drvdata->spinlock, flags);
+ if (nd->sysfs_buf == drvdata->sysfs_buf) {
+ if (coresight_get_mode(drvdata->csdev) != CS_MODE_DISABLED)
+ /*
+ * The device is still active. Keep the live
+ * buffer owned by drvdata->sysfs_buf and only
+ * drop the list's reference to it.
+ */
+ nd->sysfs_buf = NULL;
+ else
+ /* Free the buffer below through nd->sysfs_buf */
+ drvdata->sysfs_buf = NULL;
+ }
+ raw_spin_unlock_irqrestore(&drvdata->spinlock, flags);
+
+ /* Free the buffer (NULL is ignored) and the node out of the lock */
+ tmc_etr_free_sysfs_buf(nd->sysfs_buf);
+ list_del(&nd->link);
+ kfree(nd);
+ }
+}
+EXPORT_SYMBOL_GPL(tmc_clean_etr_buf_list);
+
+/**
+ * tmc_create_etr_buf_list - create a list to manage the etr_buf_node.
+ * @drvdata: driver data of the TMC device.
+ * @num_nodes: number of nodes want to create with the list.
+ *
+ * Locking: callers must guarantee exclusive access to @drvdata->etr_buf_list
+ * and must not hold @drvdata->spinlock. The spinlock is taken internally only
+ * to serialise the @drvdata->sysfs_buf accesses against the ETR sink
+ * enable/disable paths. Must be called from process context: buffers and nodes
+ * are allocated with the lock released.
+ *
+ * Return 0 upon success and return the error number if fail.
+ */
+int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes)
+{
+ struct etr_buf_node *new_node;
+ struct etr_buf *sysfs_buf;
+ unsigned long flags;
+ int i = 0, ret = 0;
+
+ /* We don't need a list if there is only one node */
+ if (num_nodes < 2)
+ return -EINVAL;
+
+ /*
+ * We expect that sysfs_buf in drvdata has already been allocated.
+ * Wrap the live sysfs_buf into the first node so the captured trace
+ * data is preserved. The list is owned by the caller, so no lock is
+ * needed to read sysfs_buf or to add the node here.
+ */
+ if (drvdata->sysfs_buf) {
+ new_node = kzalloc_obj(*new_node, GFP_KERNEL);
+ if (!new_node)
+ return -ENOMEM;
+
+ new_node->sysfs_buf = drvdata->sysfs_buf;
+ new_node->is_free = false;
+ list_add(&new_node->link, &drvdata->etr_buf_list);
+ i++;
+ }
+
+ while (i < num_nodes) {
+ new_node = kzalloc_obj(*new_node, GFP_KERNEL);
+ if (!new_node) {
+ ret = -ENOMEM;
+ break;
+ }
+
+ /* Allocate the buffer with the lock released */
+ sysfs_buf = tmc_alloc_etr_buf(drvdata, drvdata->size, 0, cpu_to_node(0), NULL);
+ if (IS_ERR(sysfs_buf)) {
+ kfree(new_node);
+ ret = PTR_ERR(sysfs_buf);
+ break;
+ }
+
+ new_node->sysfs_buf = sysfs_buf;
+ /*
+ * Only the drvdata->sysfs_buf write needs the spinlock, to
+ * serialise against the ETR sink enable/disable paths.
+ */
+ raw_spin_lock_irqsave(&drvdata->spinlock, flags);
+ /* We don't have an available sysfs_buf in drvdata, set one up */
+ if (!drvdata->sysfs_buf) {
+ drvdata->sysfs_buf = sysfs_buf;
+ new_node->is_free = false;
+ } else {
+ new_node->is_free = true;
+ }
+ raw_spin_unlock_irqrestore(&drvdata->spinlock, flags);
+
+ list_add_tail(&new_node->link, &drvdata->etr_buf_list);
+ i++;
+ }
+
+ /* Clean the list if there is an error */
+ if (ret)
+ tmc_clean_etr_buf_list(drvdata);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tmc_create_etr_buf_list);
+
int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
{
int ret = 0;
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 319a354ede9f..6e994678f926 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -208,6 +208,19 @@ struct tmc_resrv_buf {
s64 len;
};
+/**
+ * @sysfs_buf: Allocated sysfs_buf.
+ * @is_free: Indicates whether the buffer is free to choose.
+ * @pos: Offset to the start of the buffer.
+ * @link: list_head of the node.
+ */
+struct etr_buf_node {
+ struct etr_buf *sysfs_buf;
+ bool is_free;
+ loff_t pos;
+ struct list_head link;
+};
+
/**
* struct tmc_drvdata - specifics associated to an TMC component
* @atclk: optional clock for the core parts of the TMC.
@@ -245,6 +258,7 @@ struct tmc_resrv_buf {
* (after crash) by default.
* @crash_mdata: Reserved memory for storing tmc crash metadata.
* Used by ETR/ETF.
+ * @etr_buf_list: List that is used to manage allocated etr_buf.
*/
struct tmc_drvdata {
struct clk *atclk;
@@ -275,6 +289,7 @@ struct tmc_drvdata {
struct etr_buf *perf_buf;
struct tmc_resrv_buf resrv_buf;
struct tmc_resrv_buf crash_mdata;
+ struct list_head etr_buf_list;
};
struct etr_buf_operations {
@@ -447,5 +462,7 @@ struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
enum cs_mode mode,
struct coresight_path *path);
extern const struct attribute_group coresight_etr_group;
+void tmc_clean_etr_buf_list(struct tmc_drvdata *drvdata);
+int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes);
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v19 3/7] coresight: tmc: introduce tmc_sysfs_ops to wrap sysfs read operations
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Mike Leach
In-Reply-To: <20260625-enable-byte-cntr-for-ctcu-v19-0-8fbbf22e8381@oss.qualcomm.com>
Introduce tmc_sysfs_ops as a wrapper, wrap sysfs read operations,
for reading trace data from the TMC buffer.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tmc-core.c | 51 ++++++++++--------------
drivers/hwtracing/coresight/coresight-tmc.h | 15 +++++++
2 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index bc7dd676da47..4b40b692be4d 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -228,17 +228,10 @@ static int tmc_read_prepare(struct tmc_drvdata *drvdata)
{
int ret = 0;
- switch (drvdata->config_type) {
- case TMC_CONFIG_TYPE_ETB:
- case TMC_CONFIG_TYPE_ETF:
- ret = tmc_read_prepare_etb(drvdata);
- break;
- case TMC_CONFIG_TYPE_ETR:
- ret = tmc_read_prepare_etr(drvdata);
- break;
- default:
+ if (drvdata->sysfs_ops)
+ ret = drvdata->sysfs_ops->read_prepare(drvdata);
+ else
ret = -EINVAL;
- }
if (!ret)
dev_dbg(&drvdata->csdev->dev, "TMC read start\n");
@@ -250,17 +243,10 @@ static int tmc_read_unprepare(struct tmc_drvdata *drvdata)
{
int ret = 0;
- switch (drvdata->config_type) {
- case TMC_CONFIG_TYPE_ETB:
- case TMC_CONFIG_TYPE_ETF:
- ret = tmc_read_unprepare_etb(drvdata);
- break;
- case TMC_CONFIG_TYPE_ETR:
- ret = tmc_read_unprepare_etr(drvdata);
- break;
- default:
+ if (drvdata->sysfs_ops)
+ ret = drvdata->sysfs_ops->read_unprepare(drvdata);
+ else
ret = -EINVAL;
- }
if (!ret)
dev_dbg(&drvdata->csdev->dev, "TMC read end\n");
@@ -287,15 +273,7 @@ static int tmc_open(struct inode *inode, struct file *file)
static ssize_t tmc_get_sysfs_trace(struct tmc_drvdata *drvdata, loff_t pos, size_t len,
char **bufpp)
{
- switch (drvdata->config_type) {
- case TMC_CONFIG_TYPE_ETB:
- case TMC_CONFIG_TYPE_ETF:
- return tmc_etb_get_sysfs_trace(drvdata, pos, len, bufpp);
- case TMC_CONFIG_TYPE_ETR:
- return tmc_etr_get_sysfs_trace(drvdata, pos, len, bufpp);
- }
-
- return -EINVAL;
+ return drvdata->sysfs_ops->get_trace_data(drvdata, pos, len, bufpp);
}
static ssize_t tmc_read(struct file *file, char __user *data, size_t len,
@@ -764,6 +742,18 @@ static void register_crash_dev_interface(struct tmc_drvdata *drvdata,
"Valid crash tracedata found\n");
}
+static const struct tmc_sysfs_ops etb_sysfs_ops = {
+ .read_prepare = tmc_read_prepare_etb,
+ .read_unprepare = tmc_read_unprepare_etb,
+ .get_trace_data = tmc_etb_get_sysfs_trace,
+};
+
+static const struct tmc_sysfs_ops etr_sysfs_ops = {
+ .read_prepare = tmc_read_prepare_etr,
+ .read_unprepare = tmc_read_unprepare_etr,
+ .get_trace_data = tmc_etr_get_sysfs_trace,
+};
+
static int __tmc_probe(struct device *dev, struct resource *res)
{
int ret = 0;
@@ -823,6 +813,7 @@ static int __tmc_probe(struct device *dev, struct resource *res)
desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
desc.ops = &tmc_etb_cs_ops;
dev_list = "tmc_etb";
+ drvdata->sysfs_ops = &etb_sysfs_ops;
break;
case TMC_CONFIG_TYPE_ETR:
desc.groups = coresight_etr_groups;
@@ -835,6 +826,7 @@ static int __tmc_probe(struct device *dev, struct resource *res)
idr_init(&drvdata->idr);
mutex_init(&drvdata->idr_mutex);
dev_list = "tmc_etr";
+ drvdata->sysfs_ops = &etr_sysfs_ops;
INIT_LIST_HEAD(&drvdata->etr_buf_list);
break;
case TMC_CONFIG_TYPE_ETF:
@@ -844,6 +836,7 @@ static int __tmc_probe(struct device *dev, struct resource *res)
desc.subtype.link_subtype = CORESIGHT_DEV_SUBTYPE_LINK_FIFO;
desc.ops = &tmc_etf_cs_ops;
dev_list = "tmc_etf";
+ drvdata->sysfs_ops = &etb_sysfs_ops;
break;
default:
pr_err("%s: Unsupported TMC config\n", desc.name);
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 6e994678f926..a14645b04624 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -259,6 +259,7 @@ struct etr_buf_node {
* @crash_mdata: Reserved memory for storing tmc crash metadata.
* Used by ETR/ETF.
* @etr_buf_list: List that is used to manage allocated etr_buf.
+ * @sysfs_ops: Read operations for the sysfs mode.
*/
struct tmc_drvdata {
struct clk *atclk;
@@ -290,6 +291,20 @@ struct tmc_drvdata {
struct tmc_resrv_buf resrv_buf;
struct tmc_resrv_buf crash_mdata;
struct list_head etr_buf_list;
+ const struct tmc_sysfs_ops *sysfs_ops;
+};
+
+/**
+ * struct tmc_sysfs_ops - read operations for TMC and its helper devices
+ * @read_prepare: prepare operation.
+ * @read_unprepare: unprepare operation.
+ * @get_trace_data: read operation.
+ */
+struct tmc_sysfs_ops {
+ int (*read_prepare)(struct tmc_drvdata *drvdata);
+ int (*read_unprepare)(struct tmc_drvdata *drvdata);
+ ssize_t (*get_trace_data)(struct tmc_drvdata *drvdata, loff_t pos,
+ size_t len, char **bufpp);
};
struct etr_buf_operations {
--
2.34.1
^ permalink raw reply related
* [PATCH v3] dt-bindings: pwm: st,pwm: convert to DT schema
From: Charan Pedumuru @ 2026-06-25 10:46 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones
Cc: linux-pwm, devicetree, linux-kernel, Charan Pedumuru
Convert STMicroelectronics STiH41x PWM/Capture controller binding
to DT schema.
Changes during conversion:
- Fix compatible string from "st,pwm" to "st,sti-pwm" to match the
actual hardware variant naming convention used across STi bindings.
- Drop pinctrl-names from the required list as pinctrl properties are
inherited and validated by the pinctrl schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v3:
- Fix compatible to "st,sti-pwm".
- Drop pinctrl-names from required.
- Modify the commit message to explain the changes made.
- Change maintainer to "Lee Jones <lee.jones@linaro.org>".
- Link to v2: https://patch.msgid.link/20260618-st-pwm-v2-1-c792d5795ce2@gmail.com
Changes in v2:
- Add the missing interrupts to the required following the old binding.
- Modify the commit message to explain the changes made.
- Link to v1: https://patch.msgid.link/20260613-st-pwm-v1-1-458c2c89709a@gmail.com
---
Documentation/devicetree/bindings/pwm/pwm-st.txt | 43 ----------
.../devicetree/bindings/pwm/st,sti-pwm.yaml | 92 ++++++++++++++++++++++
2 files changed, 92 insertions(+), 43 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-st.txt b/Documentation/devicetree/bindings/pwm/pwm-st.txt
deleted file mode 100644
index 19fce774cafa..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-st.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-STMicroelectronics PWM driver bindings
---------------------------------------
-
-Required parameters:
-- compatible : "st,pwm"
-- #pwm-cells : Number of cells used to specify a PWM. First cell
- specifies the per-chip index of the PWM to use and the
- second cell is the period in nanoseconds - fixed to 2
- for STiH41x.
-- reg : Physical base address and length of the controller's
- registers.
-- pinctrl-names: Set to "default".
-- pinctrl-0: List of phandles pointing to pin configuration nodes
- for PWM module.
- For Pinctrl properties, please refer to [1].
-- clock-names: Valid entries are "pwm" and/or "capture".
-- clocks: phandle of the clock used by the PWM module.
- For Clk properties, please refer to [2].
-- interrupts: IRQ for the Capture device
-
-Optional properties:
-- st,pwm-num-chan: Number of available PWM channels. Default is 0.
-- st,capture-num-chan: Number of available Capture channels. Default is 0.
-
-[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Example:
-
-pwm1: pwm@fe510000 {
- compatible = "st,pwm";
- reg = <0xfe510000 0x68>;
- #pwm-cells = <2>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pwm1_chan0_default
- &pinctrl_pwm1_chan1_default
- &pinctrl_pwm1_chan2_default
- &pinctrl_pwm1_chan3_default>;
- clocks = <&clk_sysin>;
- clock-names = "pwm";
- st,pwm-num-chan = <4>;
- st,capture-num-chan = <2>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/st,sti-pwm.yaml b/Documentation/devicetree/bindings/pwm/st,sti-pwm.yaml
new file mode 100644
index 000000000000..c69073e79ce9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/st,sti-pwm.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/st,sti-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STiH41x PWM/Capture controller
+
+maintainers:
+ - Lee Jones <lee.jones@linaro.org>
+
+description:
+ The STiH41x PWM controller supports both PWM output and input capture
+ functionality. It provides multiple PWM output channels for generating
+ variable duty-cycle waveforms, and multiple input capture channels for
+ measuring external signal periods and pulse widths. PWM output channels
+ and input capture channels are configured independently via
+ st,pwm-num-chan and st,capture-num-chan respectively.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: st,sti-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+ pinctrl-names:
+ const: default
+
+ clock-names:
+ items:
+ enum: [pwm, capture]
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ description: IRQ line for the capture device.
+ maxItems: 1
+
+ st,pwm-num-chan:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of available PWM output channels.
+ minimum: 0
+ maximum: 4
+ default: 0
+
+ st,capture-num-chan:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of available input capture channels.
+ minimum: 0
+ maximum: 4
+ default: 0
+
+required:
+ - reg
+ - compatible
+ - "#pwm-cells"
+ - clock-names
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pwm@fe510000 {
+ compatible = "st,pwm";
+ reg = <0xfe510000 0x68>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ #pwm-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1_chan0_default
+ &pinctrl_pwm1_chan1_default
+ &pinctrl_pwm1_chan2_default
+ &pinctrl_pwm1_chan3_default>;
+ clocks = <&clk_sysin>;
+ clock-names = "pwm";
+ st,pwm-num-chan = <4>;
+ st,capture-num-chan = <2>;
+ };
+...
---
base-commit: c425609d6ac4012c8bbf01ec2e10e801b1923a7b
change-id: 20260613-st-pwm-1feade6cfea3
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply related
* [PATCH v19 4/7] coresight: etr: add a new function to retrieve the CTCU device
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree
In-Reply-To: <20260625-enable-byte-cntr-for-ctcu-v19-0-8fbbf22e8381@oss.qualcomm.com>
Add tmc_etr_get_ctcu_device function to find the ptr of the
coresight_device of the CTCU device if the CTCU device is connected to
the TMC ETR device.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 24 ++++++++++++++++++++++++
drivers/hwtracing/coresight/coresight-tmc.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 9b3ef73e9cf2..2b26ce6455a7 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -865,6 +865,30 @@ tmc_etr_get_catu_device(struct tmc_drvdata *drvdata)
}
EXPORT_SYMBOL_GPL(tmc_etr_get_catu_device);
+/*
+ * TMC ETR could be connected to a CTCU device, which can provide ATID filter
+ * and byte-cntr service. This is represented by the output port of the TMC
+ * (ETR) connected to the input port of the CTCU.
+ *
+ * Returns : coresight_device ptr for the CTCU device if a CTCU is found.
+ * : NULL otherwise.
+ */
+struct coresight_device *
+tmc_etr_get_ctcu_device(struct tmc_drvdata *drvdata)
+{
+ struct coresight_device *etr = drvdata->csdev;
+ union coresight_dev_subtype ctcu_subtype = {
+ .helper_subtype = CORESIGHT_DEV_SUBTYPE_HELPER_CTCU
+ };
+
+ if (!IS_ENABLED(CONFIG_CORESIGHT_CTCU))
+ return NULL;
+
+ return coresight_find_output_type(etr->pdata, CORESIGHT_DEV_TYPE_HELPER,
+ ctcu_subtype);
+}
+EXPORT_SYMBOL_GPL(tmc_etr_get_ctcu_device);
+
static const struct etr_buf_operations *etr_buf_ops[] = {
[ETR_MODE_FLAT] = &etr_flat_buf_ops,
[ETR_MODE_ETR_SG] = &etr_sg_buf_ops,
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index a14645b04624..fbb015079872 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -470,6 +470,7 @@ static inline uint32_t find_crash_tracedata_crc(struct tmc_drvdata *drvdata,
}
struct coresight_device *tmc_etr_get_catu_device(struct tmc_drvdata *drvdata);
+struct coresight_device *tmc_etr_get_ctcu_device(struct tmc_drvdata *drvdata);
void tmc_etr_set_catu_ops(const struct etr_buf_operations *catu);
void tmc_etr_remove_catu_ops(void);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-25 10:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260625-lean-debonair-anteater-c22f83@quoll>
Am 25.06.2026 um 08:43 schrieb Krzysztof Kozlowski:
> On Fri, Jun 19, 2026 at 11:13:40AM +0200, Gerald Loacker wrote:
>> Add support for the optional rockchip,clk-lane-phase device tree property
>> to allow board-specific tuning of the clock lane sampling phase for
>> improved signal integrity across supported data rates.
>>
>> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
>> ---
>> .../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> index 03950b3cad08c..010950a8a8856 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> @@ -56,6 +56,15 @@ properties:
>> description:
>> Some additional phy settings are access through GRF regs.
>>
>> + rockchip,clk-lane-phase:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 7
>
> Missing default here. If default is unknown, explain that in commit msg.
>
You're right, I missed the default.
I'll add it in the next revision.
Gerald
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v19 5/7] dt-bindings: arm: add an interrupt property for Coresight CTCU
From: Jie Gan @ 2026-06-25 10:45 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jie Gan, Bjorn Andersson,
Konrad Dybcio, Yuanfang Zhang, Mao Jinlong
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Krzysztof Kozlowski, Mike Leach
In-Reply-To: <20260625-enable-byte-cntr-for-ctcu-v19-0-8fbbf22e8381@oss.qualcomm.com>
Add an interrupt property to CTCU device. The interrupt will be triggered
when the data size in the ETR buffer exceeds the threshold of the
BYTECNTRVAL register. Programming a threshold in the BYTECNTRVAL register
of CTCU device will enable the interrupt.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
index e002f87361ad..2981001a7d7f 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
@@ -44,6 +44,11 @@ properties:
items:
- const: apb
+ interrupts:
+ items:
+ - description: Interrupt for the ETR device connected to in-port0.
+ - description: Interrupt for the ETR device connected to in-port1.
+
label:
description:
Description of a coresight device.
@@ -65,6 +70,8 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
ctcu@1001000 {
compatible = "qcom,sa8775p-ctcu";
reg = <0x1001000 0x1000>;
@@ -72,6 +79,9 @@ examples:
clocks = <&aoss_qmp>;
clock-names = "apb";
+ interrupts = <GIC_SPI 270 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 262 IRQ_TYPE_EDGE_RISING>;
+
in-ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1
^ permalink raw reply related
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