* Re: [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, Srinivas Kandagatla
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326125834.2758331-1-srinivas.kandagatla@oss.qualcomm.com>
On Thu, 26 Mar 2026 12:58:34 +0000, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
>
Applied, thanks!
[1/1] arm64: dts: monaco: extend fastrpc compute cb
commit: af0d19ea5a31261e1e3aebbe7c7e45c57c4df999
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, Srinivas Kandagatla
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260326154111.2781802-1-srinivas.kandagatla@oss.qualcomm.com>
On Thu, 26 Mar 2026 15:41:11 +0000, Srinivas Kandagatla wrote:
> For some reason we ended up adding only 4 out of 11 compute cb's for
> CDSP, add the missing compute cb. This will also improve the end
> user-experience by enabling running multiple AI usecases in parallel.
>
>
Applied, thanks!
[1/1] arm64: dts: monaco: extend fastrpc compute cb
commit: af0d19ea5a31261e1e3aebbe7c7e45c57c4df999
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/3] Add support for GPUCC and GXCLK for SM8750
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Taniya Das
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, Konrad Dybcio,
Krzysztof Kozlowski, Abel Vesa
In-Reply-To: <20260305-gpucc_sm8750_v2-v5-0-78292b40b053@oss.qualcomm.com>
On Thu, 05 Mar 2026 16:10:07 +0530, Taniya Das wrote:
> Support the graphics clock controller for SM8750 for Graphics SW
> driver to use the clocks. GXCLKCTL (Graphics GX Clock Controller) is a
> block dedicated to managing clocks for the GPU subsystem on GX power
> domain. The GX clock controller driver manages only the GX GDSC and the
> rest of the resources of the controller are managed by the firmware.
>
> The Graphics GX clock controller is a reuse of the Kaanapali SW driver.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: clock: qcom: Add SM8750 GPU clocks
commit: 4aeadf8a18dbbe4fbe2f8e6f03f48f3492c8d1d1
[2/3] clk: qcom: Add a driver for SM8750 GPU clocks
commit: 5af11acae6608d3b1175aea86bac06f267c6db14
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: qcom: cleanup remaining zap-shaders
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tobias Heider
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260328-zap-v1-0-f6810b9b4930@canonical.com>
On Sat, 28 Mar 2026 16:49:20 +0100, Tobias Heider wrote:
> In commit 2377626fd216 ("arm64: dts: qcom: add gpu_zap_shader label")
> most of the Hamoa DTs were converted to use the gpu_zap_shader label
> instead of patching &gpu directly.
>
> This fixes the remaining ones that were added after the
> original fix landed. While there we can also remove the redundant
> memory-region property that is already defined in the original
> node.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: fix remaining gpu_zap_shader labels
commit: 79772ce80eb9615b69b00e77135bbfc6e4b6f158
[2/2] arm64: dts: qcom: drop redundant zap-shader memory-region
commit: c7c8ed27b71272fad8049d34257cf8ce3e37b097
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: sm8550-hdk: add support for the Display Card overlay
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Vladimir Zapolskiy
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-arm-msm, devicetree
In-Reply-To: <20260311001238.4191034-1-vladimir.zapolskiy@linaro.org>
On Wed, 11 Mar 2026 02:12:38 +0200, Vladimir Zapolskiy wrote:
> The SM8550-HDK board may be connected to a Display Card external PCB,
> which is identical to the already supported SM8650-HDK Display Card,
> it provides a VTDR6130 display with Goodix Berlin Touch controller, see
> also commit bc90f56a1699 ("arm64: dts: sm8650-hdk: add support for the
> Display Card overlay") for additional details.
>
> Two overlays are added to support SM8550-HDK plus Display Card and
> SM8550-HDK plus Display Card plus Rear Camera Card setups.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: sm8550-hdk: add support for the Display Card overlay
commit: 40c15162c873a481cb0e57f8aaa743a4bc66432f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: linux-kernel, Raymond Hackley
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, phone-devel, Max McNamee,
Stephan Gerhold, Nikita Travkin, ~postmarketos/upstreaming
In-Reply-To: <20260223220514.2556033-1-wonderfulshrinemaidenofparadise@postmarketos.org>
On Mon, 23 Feb 2026 22:05:11 +0000, Raymond Hackley wrote:
> Samsung Galaxy Core Prime Verizon Wireless is a phone based on MSM8916.
> They are similar to the other Samsung devices based on MSM8916 with only a
> few minor differences.
>
> The device trees contain initial support with:
> - GPIO keys
> - Regulator haptic
> - SDHCI (internal and external storage)
> - USB Device Mode
> - UART (on USB connector via the SM5502 MUIC)
> - WCNSS (WiFi/BT)
> - Regulators
> - QDSP6 audio
> - Speaker/earpiece/headphones/microphones via digital/analog codec in
> MSM8916/PM8916
> - WWAN Internet via BAM-DMUX
> - PMIC and charger
> - Touchscreen
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: msm8916-samsung-fortuna: Move SM5504 from rossa and refactor MUIC
commit: 21450547506ece7e36bef75681479a52e518c53b
[2/3] dt-bindings: qcom: Document samsung,coreprimeltevzw
commit: bb0a09a4fa4821a5a1da1b707e0e169d6a4e8cd2
[3/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
commit: 2ce450f77f1de5eb7b489fcd829a7f494952e1bf
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Erikas Bitovtas
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260330-z00t-cm36686-regulators-v1-1-03e23b03bd70@gmail.com>
On Mon, 30 Mar 2026 02:37:57 +0300, Erikas Bitovtas wrote:
> VCNL4000 includes support for regulators. Add regulators listed in the
> downstream device tree so they can be powered in during initialization.
> VLED supply is missing downstream, so it will be powered on by a dummy.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
commit: f757451504c4eaa77b3f87fdbed7a11d1f80df29
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, jingoohan1, mani,
lpieralisi, kwilczynski, bhelgaas, johan+linaro, vkoul, kishon,
neil.armstrong, Abel Vesa, Ziyue Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com>
On Mon, 30 Mar 2026 10:09:34 +0800, Ziyue Zhang wrote:
> Historically, the Qualcomm PCIe controller node (Host bridge) described
> all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
> a more accurate hardware description and to support future multi-Root Port
> controllers, these properties were moved to the Root Port node in the
> devicetree bindings.
>
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> initiated this transition for the Hamoa platform by moving the PHY
> property to the Root Port node in hamoa.dtsi. However, it only updated
> some platform specific DTS files for PERST# and WAKE#, leaving others in
> a "mixed" binding state.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
commit: 11b72b1ca9891c77bc876ef9fc39d6825847ffee
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH V2 5/5] dmaengine: xilinx_dma: Add support for reporting transfer size to AXI DMA / MCDMA client when app fields are unavailable
From: Frank Li @ 2026-03-30 16:04 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Vinod Koul, git, Frank Li, Michal Simek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suraj Gupta,
Radhey Shyam Pandey, Thomas Gessler, Folker Schwesinger,
Tomi Valkeinen, Kees Cook, Abin Joseph, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260313062533.421249-6-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:33AM +0530, Srinivas Neeli wrote:
> From: Suraj Gupta <suraj.gupta2@amd.com>
>
> The AXI4-stream status and control interface is optional in the AXI DMA /
> MCDMA IP design; when it is not present, app fields are not available in
> DMA descriptor. In such cases, the transferred byte count can be
> communicated to the client using the status field (bits 0-25) of
> AXI DMA / MCDMA descriptor.
>
> Add a xferred_bytes field to struct xilinx_dma_tx_descriptor to record the
> number of bytes transferred for each transaction. The value is calculated
> using the existing xilinx_dma_get_residue() function, which traverses all
> hardware descriptors associated with the async transaction descriptor,
> avoiding redundant traversal.
Can you split this change to new patch?
Frank
>
> The driver uses the xlnx,include-stscntrl-strm device tree property to
> determine if the status/control stream interface is present and selects the
> appropriate metadata source accordingly.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 28 ++++++++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 52203d44e7a4..f5ef03a1297c 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -380,6 +380,8 @@ struct xilinx_cdma_tx_segment {
> * @cyclic: Check for cyclic transfers.
> * @err: Whether the descriptor has an error.
> * @residue: Residue of the completed descriptor
> + * @xferred_bytes: Number of bytes transferred by this transaction
> + * descriptor.
> */
> struct xilinx_dma_tx_descriptor {
> struct xilinx_dma_chan *chan;
> @@ -389,6 +391,7 @@ struct xilinx_dma_tx_descriptor {
> bool cyclic;
> bool err;
> u32 residue;
> + u32 xferred_bytes;
> };
>
> /**
> @@ -515,6 +518,7 @@ struct xilinx_dma_config {
> * @mm2s_chan_id: DMA mm2s channel identifier
> * @max_buffer_len: Max buffer length
> * @has_axistream_connected: AXI DMA connected to AXI Stream IP
> + * @has_stsctrl_stream: AXI4-stream status and control interface is enabled
> */
> struct xilinx_dma_device {
> void __iomem *regs;
> @@ -534,6 +538,7 @@ struct xilinx_dma_device {
> u32 mm2s_chan_id;
> u32 max_buffer_len;
> bool has_axistream_connected;
> + bool has_stsctrl_stream;
> };
>
> /* Macros */
> @@ -672,8 +677,12 @@ static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
> struct xilinx_axidma_tx_segment, node);
> metadata_ptr = seg->hw.app;
> }
> - *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
> - return metadata_ptr;
> + if (desc->chan->xdev->has_stsctrl_stream) {
> + *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
> + return metadata_ptr;
> + }
> + *max_len = *payload_len = sizeof(desc->xferred_bytes);
> + return (void *)&desc->xferred_bytes;
> }
>
> static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
> @@ -864,6 +873,7 @@ xilinx_dma_alloc_tx_descriptor(struct xilinx_dma_chan *chan)
> return NULL;
>
> desc->chan = chan;
> + desc->xferred_bytes = 0;
> INIT_LIST_HEAD(&desc->segments);
>
> return desc;
> @@ -1014,6 +1024,7 @@ static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> struct xilinx_aximcdma_desc_hw *aximcdma_hw;
> struct list_head *entry;
> u32 residue = 0;
> + u32 xferred = 0;
>
> list_for_each(entry, &desc->segments) {
> if (chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) {
> @@ -1031,25 +1042,32 @@ static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> axidma_hw = &axidma_seg->hw;
> residue += (axidma_hw->control - axidma_hw->status) &
> chan->xdev->max_buffer_len;
> + xferred += axidma_hw->status & chan->xdev->max_buffer_len;
> } else {
> aximcdma_seg =
> list_entry(entry,
> struct xilinx_aximcdma_tx_segment,
> node);
> aximcdma_hw = &aximcdma_seg->hw;
> - if (chan->direction == DMA_DEV_TO_MEM)
> + if (chan->direction == DMA_DEV_TO_MEM) {
> residue +=
> (aximcdma_hw->control -
> aximcdma_hw->s2mm_status) &
> chan->xdev->max_buffer_len;
> - else
> + xferred += aximcdma_hw->s2mm_status &
> + chan->xdev->max_buffer_len;
> + } else {
> residue +=
> (aximcdma_hw->control -
> aximcdma_hw->mm2s_status) &
> chan->xdev->max_buffer_len;
> + xferred += aximcdma_hw->mm2s_status &
> + chan->xdev->max_buffer_len;
> + }
> }
> }
>
> + desc->xferred_bytes = xferred;
> return residue;
> }
>
> @@ -3284,6 +3302,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> xdev->has_axistream_connected =
> of_property_read_bool(node, "xlnx,axistream-connected");
> + xdev->has_stsctrl_stream =
> + of_property_read_bool(node, "xlnx,include-stscntrl-strm");
> }
>
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 3/7] cache: andes_llcache: improve performance of LLC operation
From: Conor Dooley @ 2026-03-30 16:04 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc, tim609,
alex749, az70021, Leo Yu-Chi Liang
In-Reply-To: <20260330102724.1012470-4-minachou@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]
On Mon, Mar 30, 2026 at 06:27:20PM +0800, Hui Min Mina Chou wrote:
> Eliminate get_cpu() on !CONFIG_SMP and switch readl/writel to their
Where is the get_cpu() that you're talking about eliminating here?
> relaxed variants to remove unnecessary fence instructions on I/O
> memory access. The platform specification defines all I/O regions are
> on channel 0 (point-to-point strongly ordered), so explicit fences are
> not required [1][2][3]. Explicit memory barriers (mb) are added before
> and after the CCTL loop to ensure overall memory consistency.
>
> Also fix hart ID mapping by switching to cpuid_to_hartid_map() instead
> of using the logical CPU ID directly. In AMP setups (e.g. Linux on
> Hart 1, RTOS on Hart 0), Linux sees itself as CPU 0 but must access
> Hart 1's CCTL registers, so using the logical ID would cause accidental
> interference with other cores.
This seems like it should be a separate fix for sure.
>
> [1] platform spec 2.1.1: https://github.com/riscvarchive/riscv-platform-specs/blob/main/riscv-platform-spec.adoc?plain=1#L169
> [2] privileged spec 3.6.5: https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L2835
> [3] riscv: asm/mmio.h: https://gitea.andestech.com/RD-SW/linux/src/branch/ast-v5_4_0-branch/arch/riscv/include/asm/mmio.h#L105
>
> Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> drivers/cache/andes_llcache.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> index d318b8009f7f..57f666bc537a 100644
> --- a/drivers/cache/andes_llcache.c
> +++ b/drivers/cache/andes_llcache.c
> @@ -66,7 +66,7 @@ static struct andes_priv andes_priv;
> /* LLC operations */
> static inline uint32_t andes_cpu_llc_get_cctl_status(void)
> {
> - return readl(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
> + return readl_relaxed(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
> }
>
> static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> @@ -74,16 +74,22 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> {
> unsigned long line_size = andes_priv.andes_cache_line_size;
> void __iomem *base = andes_priv.llc_base;
> - int mhartid = smp_processor_id();
> unsigned long pa;
> + int mhartid = 0;
>
> + if (IS_ENABLED(CONFIG_SMP))
> + mhartid = cpuid_to_hartid_map(get_cpu());
But I dunno why this dance is required. Can't you just retain the call
to smp_processor_id() and pass the result unconditionally to
cpuid_to_hartid_map()? Or just make it a oneliner with
cpuid_to_hartid_map(smp_processor_id())?
> + else
> + mhartid = cpuid_to_hartid_map(0);
> +
> + mb(); /* complete earlier memory accesses before the cache flush */
> while (end > start) {
> csr_write(CSR_UCCTLBEGINADDR, start);
> csr_write(CSR_UCCTLCOMMAND, l1_op);
>
> pa = virt_to_phys((void *)start);
> - writel(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> - writel(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
> + writel_relaxed(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> + writel_relaxed(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
> while ((andes_cpu_llc_get_cctl_status() &
> ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
> ANDES_LLC_CCTL_STATUS_IDLE)
> @@ -91,6 +97,10 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
>
> start += line_size;
> }
> + mb(); /* issue later memory accesses after the cache flush */
> +
> + if (IS_ENABLED(CONFIG_SMP))
> + put_cpu();
> }
>
> /* Write-back L1 and LLC entry */
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] cache: andes_llcache: refactor initialization and cache operations
From: Conor Dooley @ 2026-03-30 16:05 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc, tim609,
alex749, az70021
In-Reply-To: <20260330102724.1012470-3-minachou@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 4492 bytes --]
On Mon, Mar 30, 2026 at 06:27:19PM +0800, Hui Min Mina Chou wrote:
> This patch cleans up the Andes LLC cache driver:
> - improved error handling in andes_cache_init() by using goto labels
I don't agree that this is an improvement. There's no meaningful
teardown shared.
> - updated andes_dma_cache_inv/wback() to check for !size instead of
> start == end
> - cache-line-size mismatch from an error to a warning
> - Use ALIGN and ALIGN_DOWN helpers instead of the alignment logic in
> andes_dma_cache_inv() and andes_dma_cache_wback().
>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> drivers/cache/andes_llcache.c | 56 ++++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> index d5e382f3c801..d318b8009f7f 100644
> --- a/drivers/cache/andes_llcache.c
> +++ b/drivers/cache/andes_llcache.c
> @@ -111,21 +111,17 @@ static void andes_dma_cache_inv(phys_addr_t paddr, size_t size)
> {
> unsigned long start = (unsigned long)phys_to_virt(paddr);
> unsigned long end = start + size;
> - unsigned long line_size;
> + unsigned long line_size = andes_priv.andes_cache_line_size;
> unsigned long flags;
>
> - if (unlikely(start == end))
> + if (unlikely(!size))
> return;
>
> - line_size = andes_priv.andes_cache_line_size;
> -
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> + start = ALIGN_DOWN(start, line_size);
> + end = ALIGN(end, line_size);
>
> local_irq_save(flags);
> -
> andes_cpu_dcache_inval_range(start, end);
> -
> local_irq_restore(flags);
> }
>
> @@ -133,15 +129,15 @@ static void andes_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> unsigned long start = (unsigned long)phys_to_virt(paddr);
> unsigned long end = start + size;
> - unsigned long line_size;
> + unsigned long line_size = andes_priv.andes_cache_line_size;
> unsigned long flags;
>
> - if (unlikely(start == end))
> + if (unlikely(!size))
> return;
>
> - line_size = andes_priv.andes_cache_line_size;
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> + start = ALIGN_DOWN(start, line_size);
> + end = ALIGN(end, line_size);
> +
> local_irq_save(flags);
> andes_cpu_dcache_wb_range(start, end);
> local_irq_restore(flags);
> @@ -159,14 +155,13 @@ static int andes_get_llc_line_size(struct device_node *np)
>
> ret = of_property_read_u32(np, "cache-line-size", &andes_priv.andes_cache_line_size);
> if (ret) {
> - pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
> + pr_err("Cache: Failed to get cache-line-size\n");
> return ret;
> }
>
> if (andes_priv.andes_cache_line_size != ANDES_CACHE_LINE_SIZE) {
> - pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
> - andes_priv.andes_cache_line_size);
> - return -EINVAL;
> + pr_warn("Cache: Expected cache-line-size to be 64 bytes (found:%u)\n",
> + andes_priv.andes_cache_line_size);
> }
>
> return 0;
> @@ -186,16 +181,18 @@ static const struct of_device_id andes_cache_ids[] = {
> static int __init andes_cache_init(void)
> {
> struct resource res;
> - int ret;
> + int ret = 0;
>
> struct device_node *np __free(device_node) =
> of_find_matching_node(NULL, andes_cache_ids);
> - if (!of_device_is_available(np))
> - return -ENODEV;
> + if (!of_device_is_available(np)) {
> + ret = -ENODEV;
> + goto err_ret;
> + }
>
> ret = of_address_to_resource(np, 0, &res);
> if (ret)
> - return ret;
> + goto err_ret;
>
> /*
> * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
> @@ -208,17 +205,22 @@ static int __init andes_cache_init(void)
> return 0;
>
> andes_priv.llc_base = ioremap(res.start, resource_size(&res));
> - if (!andes_priv.llc_base)
> - return -ENOMEM;
> + if (!andes_priv.llc_base) {
> + ret = -ENOMEM;
> + goto err_ret;
> + }
>
> ret = andes_get_llc_line_size(np);
> - if (ret) {
> - iounmap(andes_priv.llc_base);
> - return ret;
> - }
> + if (ret)
> + goto err_unmap;
>
> riscv_noncoherent_register_cache_ops(&andes_cmo_ops);
>
> return 0;
> +
> +err_unmap:
> + iounmap(andes_priv.llc_base);
> +err_ret:
> + return ret;
> }
> early_initcall(andes_cache_init);
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v9 0/5] Add support to read the watchdog bootstatus from IMEM
From: Kathiravan Thirumoorthy @ 2026-03-30 16:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Wim Van Sebroeck, Guenter Roeck, Rajendra Nayak
Cc: linux-arm-msm, devicetree, linux-kernel, linux-watchdog,
Krzysztof Kozlowski, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <7593d19b-c124-48fb-9c0f-af8177dab1ac@oss.qualcomm.com>
On 3/16/2026 2:36 PM, Kathiravan Thirumoorthy wrote:
>
> On 2/28/2026 5:58 PM, Kathiravan Thirumoorthy wrote:
>> In Qualcomm IPQ SoCs, if the system is rebooted due to the watchdog
>> timeout, there is no way to identify it. Current approach of checking
>> the EXPIRED_STATUS in WDT_STS is not working.
>>
>> To achieve this, if the system is rebooted due to watchdog timeout, the
>> information is captured in the IMEM by the bootloader (along with other
>> reason codes as well).
>>
>> This series attempts to address this by adding the support to read the
>> IMEM and populate the information via bootstatus sysfs file.
>>
>> With the CONFIG_WATCHDOG_SYSFS enabled, user can extract the information
>> as below:
>>
>> cat
>> /sys/devices/platform/soc@0/f410000.watchdog/watchdog/watchdog0/bootstatus
>>
>> 32
>>
>> Signed-off-by: Kathiravan Thirumoorthy
>> <kathiravan.thirumoorthy@oss.qualcomm.com>
>
> Gentle Reminder on this series. If there are no further comments, can
> this be picked up for v7.1?
Bjorn, Guenter, Wim — gentle ping. FWIW, this series applies cleanly to
the next-20260327 tag. Please let me know if any improvements are required.
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for Texas Instruments INA4230 power monitor
From: Guenter Roeck @ 2026-03-30 16:07 UTC (permalink / raw)
To: Alexey Charkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260330-ina4230-v5-0-eeb322d95b3a@flipper.net>
On 3/30/26 08:14, Alexey Charkov wrote:
> TI INA4230 is a 4-channel power monitor with I2C interface, similar in
> operation to INA3221 (3-channel) and INA219 (single-channel) but with
> a different register layout, different alerting mechanism and slightly
> different support for directly reading calculated current/power/energy
> values (pre-multiplied by the device itself and needing only to be scaled
> by the driver depending on its selected LSB unit values).
>
> In this initial implementation, the driver supports reading voltage,
> current, power and energy values, but does not yet support alerts, which
> can be added separately if needed. Also the overflows during hardware
> calculations are not yet handled, nor is the support for the device's
> internal 32-bit energy counter reset.
>
> An example device tree using this binding and driver is available at [1]
> (not currently upstreamed, as the device in question is in engineering
> phase and not yet publicly available)
>
> [1] https://github.com/flipperdevices/flipper-linux-kernel/blob/flipper-devel/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> Changes in v5:
> - Reworded per-channel subnodes description in the binding for clarity (Sashiko)
> - NB: Sashiko's suggestion to allow interrupts in the binding sounds premature,
> as the alerts mechanism is not implemented yet and there are no known users
> to test it. If anyone has hardware with the alert pins wired to an interrupt
> line - please shout and we can test/extend it together
The bindings are supposed to be complete, even if not implemented, so I am not sure
if the DT maintainers will agree here. We'll see.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: timer: Add SiFive CLINT2
From: Conor Dooley @ 2026-03-30 16:16 UTC (permalink / raw)
To: Charles Perry
Cc: Nick Hu, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Samuel Holland,
Palmer Dabbelt, Anup Patel, linux-kernel, devicetree, linux-riscv
In-Reply-To: <acWdSsAtmyTTFVHb@bby-cbu-swbuild03.eng.microchip.com>
[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]
On Thu, Mar 26, 2026 at 01:55:38PM -0700, Charles Perry wrote:
> On Fri, Mar 21, 2025 at 04:35:06PM +0800, Nick Hu wrote:
> > Add compatible string and property for the SiFive CLINT v2. The SiFive
> > CLINT v2 is incompatible with the SiFive CLINT v0 due to differences
> > in their control methods.
>
> Hello Nick,
>
> Can you help me understand what is this different control method? I've
> found that both OpenSBI [1] and U-Boot [2] use the same match data in their
> clint driver which would indicate that they are compatible.
Hmm, good point. I didn't see that the drivers were not doing anything
different. I guess really the clintv2 should fall back to the clintv0,
and the difference in hardware should be elaborated on.
I think I also dropped the ball on sifive,fine-ctr-bits, and that should
be removed and the counter width determined from the compatible.
There's no users for that yet I think, and there's no valid users of the
clintv2 compatible /at all/ so maybe it can just get culled.
>
> Also, do you know if there's an easy way to tell if a sifive clint is a v0
> or v2?
>
> Thanks,
> Charles
>
> [1]: https://elixir.bootlin.com/opensbi/v1.8.1/source/lib/utils/timer/fdt_timer_mtimer.c#L163
> [2]: https://elixir.bootlin.com/u-boot/v2026.01/source/drivers/timer/riscv_aclint_timer.c#L86
>
> >
> > Signed-off-by: Nick Hu <nick.hu@sifive.com>
> > Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
> > ---
> > - v3 changes:
> > - Add the reason for the incompatibility between sifive,clint2 and
> > sifive,clint0.
> > - v2 changes:
> > - Don't allow sifive,clint2 by itself. Add '-{}' to the first entry
> > - Mark the sifive,fine-ctr-bits as the required property when
> > the compatible includes the sifive,clint2
> >
> > .../bindings/timer/sifive,clint.yaml | 22 +++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > index 76d83aea4e2b..34684cda8b15 100644
> > --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > @@ -36,6 +36,12 @@ properties:
> > - starfive,jh7110-clint # StarFive JH7110
> > - starfive,jh8100-clint # StarFive JH8100
> > - const: sifive,clint0 # SiFive CLINT v0 IP block
> > + - items:
> > + - {}
> > + - const: sifive,clint2 # SiFive CLINT v2 IP block
> > + description:
> > + SiFive CLINT v2 is the HRT that supports the Zicntr. The control of sifive,clint2
> > + differs from that of sifive,clint0, making them incompatible.
> > - items:
> > - enum:
> > - allwinner,sun20i-d1-clint
> > @@ -62,6 +68,22 @@ properties:
> > minItems: 1
> > maxItems: 4095
> >
> > + sifive,fine-ctr-bits:
> > + maximum: 15
> > + description: The width in bits of the fine counter.
> > +
> > +if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: sifive,clint2
> > +then:
> > + required:
> > + - sifive,fine-ctr-bits
> > +else:
> > + properties:
> > + sifive,fine-ctr-bits: false
> > +
> > additionalProperties: false
> >
> > required:
> > --
> > 2.17.1
> >
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v5 00/14] macb usrio/tsu patches
From: Conor Dooley @ 2026-03-30 16:20 UTC (permalink / raw)
To: Jiawen Wu
Cc: patchwork-bot+netdevbpf, netdev, conor.dooley,
Valentina.FernandezAlanis, andrew+netdev, davem, edumazet, kuba,
pabeni, robh, krzk+dt, conor+dt, daire.mcnamara, pjw, palmer, aou,
alex, nicolas.ferre, claudiu.beznea, richardcochran,
samuel.holland, devicetree, linux-kernel, linux-riscv,
dave.stevenson, sean.anderson, vineeth.karumanchi, abin.joseph,
theo.lebrun, Ryan.Wanner, haokexin
In-Reply-To: <06a701dcc014$86def5b0$949ce110$@trustnetic.com>
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
On Mon, Mar 30, 2026 at 03:12:10PM +0800, Jiawen Wu wrote:
> > Hello:
> >
> > This series was applied to netdev/net-next.git (main)
> > by Jakub Kicinski <kuba@kernel.org>:
> >
> > On Wed, 25 Mar 2026 16:28:04 +0000 you wrote:
> > > From: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Hey folks,
> > >
> > > At the very least, it'd be good of the soc vendor folks could check
> > > their platforms and see if their usrio stuff actually lines up with what
> > > the driver currently calls "macb_default_usrio". Ours didn't and it was
> > > a nasty surprise.
> > >
> > > [...]
> >
> > Here is the summary with links:
> > - [net-next,v5,02/14] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in
> There are compilation errors after merging this patch set.
> I believe the error occurred where the CONFIG_OF is not set.
Thanks for the report. I have sent what's hopefully a fix..
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-03-30 16:22 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-2-a547a3588730@nxp.com>
On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Cortex-M[7,33] processors use a fixed reset vector table format:
>
> 0x00 Initial SP value
> 0x04 Reset vector
> 0x08 NMI
> 0x0C ...
> ...
> IRQ[n]
>
> In ELF images, the corresponding layout is:
>
> reset_vectors: --> hardware reset address
> .word __stack_end__
> .word Reset_Handler
> .word NMI_Handler
> .word HardFault_Handler
> ...
> .word UART_IRQHandler
> .word SPI_IRQHandler
> ...
>
> Reset_Handler: --> ELF entry point address
> ...
>
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
>
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
>
> ELF entry point: 0x0ffc211d
> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>
But why? Why can't the ELF image be set to the right reset base?
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC-specific mask before
> programming the reset address registers, e.g.:
>
> reset_address = entry & reset_vector_mask
>
> Current driver always programs the reset vector as 0. But i.MX94 CM33S's
> default reset base is 0x0ffc0000, so the correct reset vector must be
> passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
>
> rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
> hardware reset vector address. To derive the proper reset vector, this
> patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
> point using the SoC‑specific 'reset_vector_mask'. The resulting reset
> vector address is then passed to the SM CPU/LMM reset vector API calls.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 17 ++++++++++++++---
> drivers/remoteproc/imx_rproc.h | 2 ++
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..d8ead42640881bd523d605fa7002935ef6e98077 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -345,7 +345,7 @@ static int imx_rproc_sm_cpu_start(struct rproc *rproc)
> const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> int ret;
>
> - ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
> + ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, rproc->bootaddr, true, false, false);
> if (ret) {
> dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
> return ret;
> @@ -365,7 +365,7 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
> * If the remoteproc core can't start the M7, it will already be
> * handled in imx_rproc_sm_lmm_prepare().
> */
> - ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
> + ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, rproc->bootaddr);
> if (ret) {
> dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
> dcfg->lmid, dcfg->cpuid, ret);
> @@ -739,6 +739,17 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
> return rproc_elf_find_loaded_rsc_table(rproc, fw);
> }
>
> +static u64 imx_rproc_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct imx_rproc *priv = rproc->priv;
> + u32 reset_vector_mask = GENMASK_U32(31, 0);
> +
> + if (priv->dcfg->reset_vector_mask)
> + reset_vector_mask = priv->dcfg->reset_vector_mask;
> +
> + return rproc_elf_get_boot_addr(rproc, fw) & reset_vector_mask;
> +}
> +
> static const struct rproc_ops imx_rproc_ops = {
> .prepare = imx_rproc_prepare,
> .attach = imx_rproc_attach,
> @@ -752,7 +763,7 @@ static const struct rproc_ops imx_rproc_ops = {
> .find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
> .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
> .sanity_check = rproc_elf_sanity_check,
> - .get_boot_addr = rproc_elf_get_boot_addr,
> + .get_boot_addr = imx_rproc_get_boot_addr,
> };
>
> static int imx_rproc_addr_init(struct imx_rproc *priv,
> diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
> index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
> --- a/drivers/remoteproc/imx_rproc.h
> +++ b/drivers/remoteproc/imx_rproc.h
> @@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
> /* For System Manager(SM) based SoCs */
> u32 cpuid; /* ID of the remote core */
> u32 lmid; /* ID of the Logcial Machine */
> + /* reset_vector = elf_entry_addr & reset_vector_mask */
> + u32 reset_vector_mask;
> };
>
> #endif /* _IMX_RPROC_H */
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH 0/2] Add support for Infineon Digital eFuse XDP720
From: Guenter Roeck @ 2026-03-30 16:25 UTC (permalink / raw)
To: ASHISH YADAV, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260330102345.37065-1-Ashish.Yadav@infineon.com>
Hi,
On 3/30/26 03:23, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Hi,
>
> These patches add support for Infineon Digital eFuse XDP720.
> XDP720 provides accurate system telemetry (V, I, P, T) and
> reports analog current at the IMON pin for post-processing.
>
> The Current and Power measurement depends on the RIMON and GIMON values.
> Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
> https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
>
Please address the issues reported in
https://sashiko.dev/#/patchset/20260330102345.37065-1-Ashish.Yadav%40infineon.com
Thanks,
Guenter
> With Best Regards,
> Ashish Yadav
>
>
> Ashish Yadav (2):
> dt-bindings: hwmon/pmbus: Add Infineon XDP720
> hwmon:(pmbus/xdp720) Add support for efuse xdp720
>
> .../bindings/hwmon/pmbus/infineon,xdp720.yaml | 52 ++++++++
> drivers/hwmon/pmbus/Kconfig | 9 ++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/xdp720.c | 122 ++++++++++++++++++
> 4 files changed, 184 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> create mode 100644 drivers/hwmon/pmbus/xdp720.c
>
^ permalink raw reply
* Re: [PATCH v5 4/4] platform: Add initial synology microp driver
From: Conor Dooley @ 2026-03-30 16:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: markus.probst, Hans de Goede, Ilpo Järvinen,
Bryan O'Donoghue, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan,
platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi
In-Reply-To: <6d2fb01a-216b-4f51-8a26-527d724002d7@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]
On Mon, Mar 30, 2026 at 08:51:14AM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 20:02, Markus Probst via B4 Relay wrote:
> > +
> > +kernel::of_device_table!(
> > + pub(crate) OF_TABLE,
> > + MODULE_OF_TABLE,
> > + Model,
> > + models![
> > + apollolake @ [
> > + ds918p,
> > + ],
> > + evansport @ [
> > + ds214play,
> > + ],
> > + geminilakenk @ [
> > + ds225p.led_usb_copy(),
> > + ds425p,
> > + ],
> > + pineview @ [
> > + ds710p.led_esata(),
> > + ds1010p.led_alert(Color::Orange),
> > + ],
> > + r1000 @ [
> > + ds923p,
> > + ds723p,
> > + ds1522p,
> > + rs422p.led_power(Color::Green),
> > + ],
> > + r1000nk @ [
> > + ds725p,
> > + ],
> > + rtd1296 @ [
> > + ds118,
> > + ],
> > + rtd1619b @ [
> > + ds124,
> > + ds223.led_usb_copy(),
> > + ds223j,
> > + ],
> > + v1000 @ [
> > + ds1823xsp,
> > + rs822p.led_power(Color::Green),
> > + rs1221p.led_power(Color::Green),
> > + rs1221rpp.led_power(Color::Green),
> > + ],
> > + v1000nk @ [
> > + ds925p,
> > + ds1525p,
> > + ds1825p,
> I don't see any compatible strings here. Actually, nowhere in the
> driver. If that's how you write Rust drivers then NAK. Compatibles must
> be greppable. Not only for humans but also for ABI check.
The code immediately prior creates a macro, which is called here to
produce these. This macro is barely grokkable to begin with IMO, but
you can see the DeviceID::new() call down there that creates the
compatible using string concatenation.
Definitely on the same page as you about compatibles being greppable.
It's not as if it is difficult to create the list using vim or whatever
code generator llm you wanna use. Probably making the macro was more
effort than writing them out!
+macro_rules! models {
+ [
+ $($arch:ident $(.$arch_func:ident( $($arch_arg:tt)* ))*
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ models![
+ $(
+ {
+ Architecture::new()
+ $(
+ .$arch_func($($arch_arg)*)
+ )*
+ }
+ @
+ [
+ $(
+ $model $(.$func($($arg)*))*,
+ )*
+ ],
+ )*
+ ]
+ };
+ [
+ $($arch:block
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ [
+ $(
+ $((
+ DeviceId::new(::kernel::c_str!(
+ ::core::concat!(
+ "synology,",
+ ::core::stringify!($model),
+ "-microp",
+ )
+ )),
+ Model::new($arch)
+ $(
+ .$func($($arg)*)
+ )*
+ ),)*
+ )*
+ ]
+ };
+}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/11] dt-bindings: mfd: ti,omap-usb-host: Add 'pbias-supply' property
From: Thomas Richard @ 2026-03-30 16:40 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-9-1c1e11b190dc@bootlin.com>
On 3/30/26 3:44 PM, Thomas Richard wrote:
> Add the 'pbias-supply' property, it is used to specify the voltage
> regulator that provides the bias voltage for USB cell.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> index 3b5b041f0321..d0a61dec4961 100644
> --- a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> +++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> @@ -83,6 +83,12 @@ properties:
>
> ranges: true
>
> + pbias-supply:
> + $ref: /schemas/types.yaml#/definitions/phandle
I'm sorry, I missed dt_binding_check error. $ref is not needed.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers
From: Herve Codina @ 2026-03-30 16:41 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <27e23c7b-4aca-41d2-96b8-df02c52e8121@sirena.org.uk>
On Mon, 30 Mar 2026 16:48:54 +0100
Mark Brown <broonie@kernel.org> wrote:
> On Mon, Mar 30, 2026 at 05:39:44PM +0200, Herve Codina wrote:
> > Mark Brown <broonie@kernel.org> wrote:
>
> > > This sounds a lot like simple-amplifier.c?
>
> > The gpio driven amplifier proposed is more generic and can handle
> > more complex design. I.e. op-amp + resistor and/or line (mute,
> > bypass) switching. Hardwares handled by this driver are a superset
> > of just dio2125 and so simple-amplifier.c.
>
> > IMHO, it makes sense to have a specific driver for those kind
> > of hardware design.
>
> Right, and if it's a superset it feels like it should all be one driver
> rather than two separate ones.
Also, it is worth noting that simple-amplifier.c considered a stereo
amplifier (left + right).
Considering the two op-amp available in dio2125 as just two op-amp used
in two separated mono channel with additional component to switch related
to resistors (independant switching for each channel) means that almost
everything proposed in audio-gpio-amp have to be duplicated (gain, mute,
bypass per channel) instead of just instantiate two audio-gpio-amps.
On the other hand, there is no reason to handle a stereo component in
audio-gpio-amp. Further more with the hardware I have handling a stereo
component doesn't make sense. Indeed, I only have independent mono lines
with their own resistor switched amplification circuitry.
I could merge everything in one .c file but only a few part of source code
will be common to simple-amplifier and audio-gpio-amp. IMHO the resulting
merged code will look like two different drivers merged in one .c file.
Best regards,
Hervé
^ permalink raw reply
* [PATCH v4 0/5] SDM670 LPASS LPI pin controller support
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
This adds support for the LPASS LPI pin controller on SDM670, which
controls some audio pins (e.g. TDM or PDM busses). The ADSP patches are
not sent yet.
Dependencies:
- SDM670 Basic SoC thermal zones (devicetree nodes are touching)
https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com
- Support for the Pixel 3a XL with the Tianma panel (for reserved GPIOs)
https://lore.kernel.org/r/20260310002606.16413-1-mailingradian@gmail.com
Changes since v2 (https://lore.kernel.org/r/20260328021036.85945-1-mailingradian@gmail.com):
- restore review tags (2-5/5)
- add review tags (1/5)
Changes since v2 (https://lore.kernel.org/r/20260310012446.32226-1-mailingradian@gmail.com):
- add minItems and maxItems (1/5)
- add review tags (2-5/5)
Changes since v1 (https://lore.kernel.org/r/20260210021109.11906-1-mailingradian@gmail.com):
- add LPASS in dt-bindings patch subject (2/5)
- change pin names (2/5, 3/5, 4/5)
- add reviewed-by from Krzysztof (2/5)
- specify gpio-reserved-ranges (1/5, 5/5)
Richard Acayan (5):
dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
pinctrl: qcom: add sdm670 lpi tlmm
arm64: dts: qcom: sdm670: add lpi pinctrl
arm64: dts: qcom: sdm670-google: add reserved lpi gpios
.../pinctrl/qcom,lpass-lpi-common.yaml | 8 +
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++
.../boot/dts/qcom/sdm670-google-common.dtsi | 4 +
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 ++++++++
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
7 files changed, 343 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
--
2.53.0
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
There can be reserved GPIOs on the LPASS LPI pin controller to possibly
control sensors. Add the property for reserved GPIOs so they can be
avoided appropriately.
Adapted from the same entry in qcom,tlmm-common.yaml.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pinctrl/qcom,lpass-lpi-common.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
index 619341dd637c..30f93b8159fd 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
@@ -27,6 +27,14 @@ properties:
gpio-ranges:
maxItems: 1
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 30
+ description:
+ Pins can be reserved for trusted applications or for LPASS, thereby
+ inaccessible from the OS. This property can be used to mark the pins
+ which resources should not be accessed by the OS.
+
required:
- gpio-controller
- "#gpio-cells"
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
Add the pin controller for the audio Low-Power Island (LPI) on SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++++++++++++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..c76ad70e6b9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM670 SoC LPASS LPI TLMM
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SDM670 SoC.
+
+properties:
+ compatible:
+ const: qcom,sdm670-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm670-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm670-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm670-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-9]|3[0-1])$"
+
+ function:
+ enum: [ gpio, comp_rx, dmic1_clk, dmic1_data, dmic2_clk, dmic2_data,
+ i2s1_clk, i2s_data, i2s_ws, lpi_cdc_rst, mclk0, pdm_rx,
+ pdm_sync, pdm_tx, slimbus_clk ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0x62b40000 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/5] pinctrl: qcom: add sdm670 lpi tlmm
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
The Snapdragon 670 has an Low-Power Island (LPI) TLMM for configuring
pins related to audio. Add the driver for this.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
3 files changed, 177 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index f56592411cf6..eb8ed3effd58 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -89,6 +89,16 @@ config PINCTRL_SM4250_LPASS_LPI
Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
(Low Power Island) found on the Qualcomm Technologies Inc SM4250 platform.
+config PINCTRL_SDM670_LPASS_LPI
+ tristate "Qualcomm Technologies Inc SDM670 LPASS LPI pin controller driver"
+ depends on GPIOLIB
+ depends on ARM64 || COMPILE_TEST
+ depends on PINCTRL_LPASS_LPI
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
+ (Low Power Island) found on the Qualcomm Technologies Inc SDM670 platform.
+
config PINCTRL_SM6115_LPASS_LPI
tristate "Qualcomm Technologies Inc SM6115 LPASS LPI pin controller driver"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 4269d1781015..ed2127d26912 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_SC8280XP) += pinctrl-sc8280xp.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM660_LPASS_LPI) += pinctrl-sdm660-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM670) += pinctrl-sdm670.o
+obj-$(CONFIG_PINCTRL_SDM670_LPASS_LPI) += pinctrl-sdm670-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
obj-$(CONFIG_PINCTRL_SDX65) += pinctrl-sdx65.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
new file mode 100644
index 000000000000..6270c6d09c22
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023-2026, Richard Acayan. All rights reserved.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-lpass-lpi.h"
+
+enum lpass_lpi_functions {
+ LPI_MUX_comp_rx,
+ LPI_MUX_dmic1_clk,
+ LPI_MUX_dmic1_data,
+ LPI_MUX_dmic2_clk,
+ LPI_MUX_dmic2_data,
+ LPI_MUX_i2s1_clk,
+ LPI_MUX_i2s1_data,
+ LPI_MUX_i2s1_ws,
+ LPI_MUX_lpi_cdc_rst,
+ LPI_MUX_mclk0,
+ LPI_MUX_pdm_rx,
+ LPI_MUX_pdm_sync,
+ LPI_MUX_pdm_tx,
+ LPI_MUX_slimbus_clk,
+ LPI_MUX_gpio,
+ LPI_MUX__,
+};
+
+static const struct pinctrl_pin_desc sdm670_lpi_pinctrl_pins[] = {
+ PINCTRL_PIN(0, "gpio0"),
+ PINCTRL_PIN(1, "gpio1"),
+ PINCTRL_PIN(2, "gpio2"),
+ PINCTRL_PIN(3, "gpio3"),
+ PINCTRL_PIN(4, "gpio4"),
+ PINCTRL_PIN(5, "gpio5"),
+ PINCTRL_PIN(6, "gpio6"),
+ PINCTRL_PIN(7, "gpio7"),
+ PINCTRL_PIN(8, "gpio8"),
+ PINCTRL_PIN(9, "gpio9"),
+ PINCTRL_PIN(10, "gpio10"),
+ PINCTRL_PIN(11, "gpio11"),
+ PINCTRL_PIN(12, "gpio12"),
+ PINCTRL_PIN(13, "gpio13"),
+ PINCTRL_PIN(14, "gpio14"),
+ PINCTRL_PIN(15, "gpio15"),
+ PINCTRL_PIN(16, "gpio16"),
+ PINCTRL_PIN(17, "gpio17"),
+ PINCTRL_PIN(18, "gpio18"),
+ PINCTRL_PIN(19, "gpio19"),
+ PINCTRL_PIN(20, "gpio20"),
+ PINCTRL_PIN(21, "gpio21"),
+ PINCTRL_PIN(22, "gpio22"),
+ PINCTRL_PIN(23, "gpio23"),
+ PINCTRL_PIN(24, "gpio24"),
+ PINCTRL_PIN(25, "gpio25"),
+ PINCTRL_PIN(26, "gpio26"),
+ PINCTRL_PIN(27, "gpio27"),
+ PINCTRL_PIN(28, "gpio28"),
+ PINCTRL_PIN(29, "gpio29"),
+ PINCTRL_PIN(30, "gpio30"),
+ PINCTRL_PIN(31, "gpio31"),
+};
+
+static const char * const comp_rx_groups[] = { "gpio22", "gpio24" };
+static const char * const dmic1_clk_groups[] = { "gpio26" };
+static const char * const dmic1_data_groups[] = { "gpio27" };
+static const char * const dmic2_clk_groups[] = { "gpio28" };
+static const char * const dmic2_data_groups[] = { "gpio29" };
+static const char * const i2s1_clk_groups[] = { "gpio8" };
+static const char * const i2s1_ws_groups[] = { "gpio9" };
+static const char * const i2s1_data_groups[] = { "gpio10", "gpio11" };
+static const char * const lpi_cdc_rst_groups[] = { "gpio29" };
+static const char * const mclk0_groups[] = { "gpio19" };
+static const char * const pdm_rx_groups[] = { "gpio21", "gpio23", "gpio25" };
+static const char * const pdm_sync_groups[] = { "gpio19" };
+static const char * const pdm_tx_groups[] = { "gpio20" };
+static const char * const slimbus_clk_groups[] = { "gpio18" };
+
+const struct lpi_pingroup sdm670_lpi_pinctrl_groups[] = {
+ LPI_PINGROUP(0, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(1, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(2, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(3, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(4, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(5, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(6, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(7, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(8, LPI_NO_SLEW, _, _, i2s1_clk, _),
+ LPI_PINGROUP(9, LPI_NO_SLEW, _, _, i2s1_ws, _),
+ LPI_PINGROUP(10, LPI_NO_SLEW, _, _, _, i2s1_data),
+ LPI_PINGROUP(11, LPI_NO_SLEW, _, i2s1_data, _, _),
+ LPI_PINGROUP(12, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(13, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(14, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(15, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(16, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(17, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(18, LPI_NO_SLEW, _, slimbus_clk, _, _),
+ LPI_PINGROUP(19, LPI_NO_SLEW, mclk0, _, pdm_sync, _),
+ LPI_PINGROUP(20, LPI_NO_SLEW, _, pdm_tx, _, _),
+ LPI_PINGROUP(21, LPI_NO_SLEW, _, pdm_rx, _, _),
+ LPI_PINGROUP(22, LPI_NO_SLEW, _, comp_rx, _, _),
+ LPI_PINGROUP(23, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(24, LPI_NO_SLEW, comp_rx, _, _, _),
+ LPI_PINGROUP(25, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(26, LPI_NO_SLEW, dmic1_clk, _, _, _),
+ LPI_PINGROUP(27, LPI_NO_SLEW, dmic1_data, _, _, _),
+ LPI_PINGROUP(28, LPI_NO_SLEW, dmic2_clk, _, _, _),
+ LPI_PINGROUP(29, LPI_NO_SLEW, dmic2_data, lpi_cdc_rst, _, _),
+ LPI_PINGROUP(30, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(31, LPI_NO_SLEW, _, _, _, _),
+};
+
+const struct lpi_function sdm670_lpi_pinctrl_functions[] = {
+ LPI_FUNCTION(comp_rx),
+ LPI_FUNCTION(dmic1_clk),
+ LPI_FUNCTION(dmic1_data),
+ LPI_FUNCTION(dmic2_clk),
+ LPI_FUNCTION(dmic2_data),
+ LPI_FUNCTION(i2s1_clk),
+ LPI_FUNCTION(i2s1_data),
+ LPI_FUNCTION(i2s1_ws),
+ LPI_FUNCTION(lpi_cdc_rst),
+ LPI_FUNCTION(mclk0),
+ LPI_FUNCTION(pdm_tx),
+ LPI_FUNCTION(pdm_rx),
+ LPI_FUNCTION(pdm_sync),
+ LPI_FUNCTION(slimbus_clk),
+};
+
+static const struct lpi_pinctrl_variant_data sdm670_lpi_pinctrl_data = {
+ .pins = sdm670_lpi_pinctrl_pins,
+ .npins = ARRAY_SIZE(sdm670_lpi_pinctrl_pins),
+ .groups = sdm670_lpi_pinctrl_groups,
+ .ngroups = ARRAY_SIZE(sdm670_lpi_pinctrl_groups),
+ .functions = sdm670_lpi_pinctrl_functions,
+ .nfunctions = ARRAY_SIZE(sdm670_lpi_pinctrl_functions),
+ .flags = LPI_FLAG_SLEW_RATE_SAME_REG,
+};
+
+static const struct of_device_id sdm670_lpi_pinctrl_of_match[] = {
+ {
+ .compatible = "qcom,sdm670-lpass-lpi-pinctrl",
+ .data = &sdm670_lpi_pinctrl_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdm670_lpi_pinctrl_of_match);
+
+static struct platform_driver sdm670_lpi_pinctrl_driver = {
+ .driver = {
+ .name = "qcom-sdm670-lpass-lpi-pinctrl",
+ .of_match_table = sdm670_lpi_pinctrl_of_match,
+ },
+ .probe = lpi_pinctrl_probe,
+ .remove = lpi_pinctrl_remove,
+};
+module_platform_driver(sdm670_lpi_pinctrl_driver);
+
+MODULE_AUTHOR("Richard Acayan <mailingradian@gmail.com>");
+MODULE_DESCRIPTION("QTI SDM670 LPI GPIO pin control driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: sdm670: add lpi pinctrl
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
The Snapdragon 670 has a separate TLMM for audio pins. Add the device
node for it.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 ++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index c5f7655421a3..85a34e2f0907 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -2346,6 +2346,79 @@ lmh_cluster0: lmh@17d78800 {
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0 0x62b40000 0 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_pdm_default: cdc-pdm-default-state {
+ clk-pins {
+ pins = "gpio18";
+ function = "slimbus_clk";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ sync-pins {
+ pins = "gpio19";
+ function = "pdm_sync";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ tx-pins {
+ pins = "gpio20";
+ function = "pdm_tx";
+ drive-strength = <8>;
+ };
+
+ rx-pins {
+ pins = "gpio21", "gpio23", "gpio25";
+ function = "pdm_rx";
+ drive-strength = <4>;
+ output-low;
+ };
+ };
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+
+ cdc_dmic_default: cdc-dmic-default-state {
+ clk1-pins {
+ pins = "gpio26";
+ function = "dmic1_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ clk2-pins {
+ pins = "gpio28";
+ function = "dmic2_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ data1-pins {
+ pins = "gpio27";
+ function = "dmic1_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+
+ data2-pins {
+ pins = "gpio29";
+ function = "dmic2_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+ };
+ };
};
thermal-zones {
--
2.53.0
^ 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