* Re: [PATCH 5/5] dt-bindings: mailbox: qcom: Document Maili CPUCP mailbox controller
From: Krzysztof Kozlowski @ 2026-06-22 13:59 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-5-d6ede0352113@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:51:20PM +0530, Taniya Das wrote:
> Document the CPU Control Processor (CPUCP) mailbox controller for the
> Qualcomm Maili SoC. It is software compatible with the X1E80100 CPUCP
> mailbox controller and uses it as a fallback compatible string.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: clock: qcom: Add Maili global clock controller
From: Krzysztof Kozlowski @ 2026-06-22 13:58 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-3-d6ede0352113@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:51:18PM +0530, Taniya Das wrote:
> clocks:
> items:
> diff --git a/include/dt-bindings/clock/qcom,hawi-gcc.h b/include/dt-bindings/clock/qcom,hawi-gcc.h
> index 6cd7fa0884f535efce90b60997662ca90cfb9b7e..9e0e382af3112b980997f0c7e223720517f12b02 100644
> --- a/include/dt-bindings/clock/qcom,hawi-gcc.h
> +++ b/include/dt-bindings/clock/qcom,hawi-gcc.h
> @@ -196,6 +196,16 @@
> #define GCC_VIDEO_AXI0C_CLK 186
> #define GCC_VIDEO_XO_CLK 187
>
> +/* Maili has below additional clocks on top of Hawi */
> +#define GCC_QUPV3_WRAP5_CORE_2X_CLK 188
> +#define GCC_QUPV3_WRAP5_CORE_CLK 189
> +#define GCC_QUPV3_WRAP5_QSPI_REF_CLK 190
> +#define GCC_QUPV3_WRAP5_QSPI_REF_CLK_SRC 191
> +#define GCC_QUPV3_WRAP5_S0_CLK 192
> +#define GCC_QUPV3_WRAP5_S0_CLK_SRC 193
> +#define GCC_QUPV3_WRAP_5_M_AHB_CLK 194
> +#define GCC_QUPV3_WRAP_5_S_AHB_CLK 195
I think this should be moved to its own header which will include the
qcom,hawi-gcc.h. We already do it for
include/dt-bindings/clock/qcom,sm8650-videocc.h.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Marek Vasut @ 2026-06-22 13:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <CAMuHMdUEPR0xWXRwLjBt5sF7i4HxcDLHCQGmc=gGvFmHRDv-Jw@mail.gmail.com>
On 6/22/26 12:35 PM, Geert Uytterhoeven wrote:
Hello Geert,
> On Sun, 21 Jun 2026 at 04:51, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
>> which already has that soc: label. The soc: label is useful in U-Boot
>> where it is used in U-Boot extras DT fragments.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> For the whole series:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v7.3, squashed into a single
> commit. Unfortunately there is no cover letter, so I will have to add
> all nine Link-tags.
Is that why cover letter helps you ?
If so, I will start generating ones ?
Thank you for your help !
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: clock: qcom: Add Maili TCSR clock controller
From: Krzysztof Kozlowski @ 2026-06-22 13:56 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-2-d6ede0352113@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:51:17PM +0530, Taniya Das wrote:
> Add bindings documentation for TCSR clock controller on the
> Qualcomm Maili SoC.
>
> Maili is a derivative of the Hawi SoC and the tcsr clock controller
> is identical to that of Hawi. Therefore Maili uses the fallback
> compatible to reuse the Hawi tcsrcc driver.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,sm8550-tcsr.yaml | 34 +++++++++++++---------
> 1 file changed, 20 insertions(+), 14 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 09/12] iio: dac: ad5686: implement new sync() op for the spi bus
From: David Lechner @ 2026-06-22 13:55 UTC (permalink / raw)
To: Rodrigo Alencar, rodrigo.alencar, Michael Auchter, linux,
linux-iio, devicetree, linux-kernel, linux-hardening
Cc: Michael Hennerich, Jonathan Cameron, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <3i3fdq6qjd2h4o4wwicl4zlpzyggzb7gljm2acwz33k75ds57k@7mdevoavx3ao>
On 6/22/26 3:50 AM, Rodrigo Alencar wrote:
> On 20/06/26 11:33, David Lechner wrote:
>> On 6/16/26 3:21 AM, Rodrigo Alencar via B4 Relay wrote:
>>> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>>>
>>> Use of local SPI bus data to manage a collection of SPI transfers and
>>> flush them to the SPI platform driver with the sync() operation. This
>>> allows for faster handling of multiple channel DAC writes, avoiding kernel
>>> overhead per spi_sync() call, which will be helpful when enabling
>>> triggered buffer support.
>
> ...
>
>>> +/**
>>> + * struct ad5686_spi_data - SPI bus specific data
>>> + * @msg: SPI message used for transfers
>>> + * @size: number of transfers currently in the message
>>> + * @capacity: maximum number of transfers that can be added to the message
>>> + * @xfers: array of SPI transfers, allocated with the provided capacity
>>> + */
>>> +struct ad5686_spi_data {
>>> + struct spi_message msg;
>>> + unsigned int size;
>>> + unsigned int capacity;
>>> + struct spi_transfer xfers[] __counted_by(capacity);
>>> +};
>>> +
>>> static int ad5686_spi_write(struct ad5686_state *st,
>>> u8 cmd, u8 addr, u16 val)
>>> {
>>> - struct spi_device *spi = to_spi_device(st->dev);
>>> - u8 tx_len, *buf;
>>> + struct ad5686_spi_data *bus_data = st->bus_data;
>>> + struct spi_transfer *xfer;
>>>
>>> + if (bus_data->size >= bus_data->capacity)
>>> + return -E2BIG;
>>> +
>>> + if (bus_data->size)
>>> + bus_data->xfers[bus_data->size - 1].cs_change = 1;
>>> + else
>>> + spi_message_init(&bus_data->msg);
>>
>> Seems odd that spi_message_init() is called conditionally. What
>> prevents spi_message_add_tail() from growing the message unbounded
>> on repeated calls?
>
> The "size >= capacity" check right above this.
OK, but it could still grow to capacity, adding one xfer each
time this function is called with bus_data->size > 0, right?
>
>>
>>> +
>>> + xfer = &bus_data->xfers[bus_data->size];
>>> switch (st->chip_info->regmap_type) {
>>> case AD5310_REGMAP:
>>> - st->data[0].d16 = cpu_to_be16(AD5310_CMD(cmd) |
>>> - val);
>>> - buf = &st->data[0].d8[0];
>>> - tx_len = 2;
>>> + st->data[bus_data->size].d16 =
>>> + cpu_to_be16(AD5310_CMD(cmd) | val);
>>> + *xfer = (struct spi_transfer) {
>>> + .tx_buf = &st->data[bus_data->size].d16,
>>> + .len = sizeof(st->data[bus_data->size].d16),
>>> + };
>>> break;
>>> case AD5683_REGMAP:
>>> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
>>> - AD5683_DATA(val));
>>> - buf = &st->data[0].d8[1];
>>> - tx_len = 3;
>>> + st->data[bus_data->size].d32 =
>>> + cpu_to_be32(AD5686_CMD(cmd) | AD5683_DATA(val));
>>> + *xfer = (struct spi_transfer) {
>>> + .tx_buf = &st->data[bus_data->size].d8[1],
>>> + .len = sizeof(st->data[bus_data->size].d32) - 1,
>>> + };
>>> break;
>>> case AD5686_REGMAP:
>>> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
>>> - AD5686_ADDR(addr) |
>>> - val);
>>> - buf = &st->data[0].d8[1];
>>> - tx_len = 3;
>>> + st->data[bus_data->size].d32 =
>>> + cpu_to_be32(AD5686_CMD(cmd) | AD5686_ADDR(addr) | val);
>>> + *xfer = (struct spi_transfer) {
>>> + .tx_buf = &st->data[bus_data->size].d8[1],
>>> + .len = sizeof(st->data[bus_data->size].d32) - 1,
>>> + };
>>> break;
>>> default:
>>> return -EINVAL;
>>> }
>>>
>>> - return spi_write(spi, buf, tx_len);
>>
>> If this function no longer writes, should we change the name of
>> the function to something like ad5686_spi_write_prepare_msg()?
>>
>>> + spi_message_add_tail(xfer, &bus_data->msg);
>>> + bus_data->size++;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int ad5686_spi_sync(struct ad5686_state *st)
>>> +{
>>> + struct spi_device *spi = to_spi_device(st->dev);
>>> + struct ad5686_spi_data *bus_data = st->bus_data;
>>> +
>>> + bus_data->size = 0; /* always reset, even on sync failure */
>>> + return spi_sync(spi, &bus_data->msg);
>>> }
>>>
>>> static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
>>> {
>>> - struct spi_transfer t[] = {
>>> - {
>>> - .tx_buf = &st->data[0].d8[1],
>>> - .len = 3,
>>> - .cs_change = 1,
>>> - }, {
>>> - .tx_buf = &st->data[1].d8[1],
>>> - .rx_buf = &st->data[2].d8[1],
>>> - .len = 3,
>>> - },
>>> - };
>>> struct spi_device *spi = to_spi_device(st->dev);
>>> + struct ad5686_spi_data *bus_data = st->bus_data;
>>> + struct spi_transfer *xfer = &bus_data->xfers[0];
>>> u8 cmd = 0;
>>> int ret;
>>>
>>> @@ -85,8 +117,21 @@ static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
>>> AD5686_ADDR(addr));
>>> st->data[1].d32 = cpu_to_be32(AD5686_CMD(AD5686_CMD_NOOP));
>>>
>>> - ret = spi_sync_transfer(spi, t, ARRAY_SIZE(t));
>>> - if (ret < 0)
>>> + xfer[0] = (struct spi_transfer) {
>>> + .tx_buf = &st->data[0].d8[1],
>>> + .len = sizeof(st->data[0].d32) - 1,
>>
>> Would make more sense to say `sizeof(st->data[0].d8) - 1` since
>> the buffer is &st->data[0].d8[1].
>
> the buffer is d8[1], d8[2] and d8[3], skipping d8[0], for a len = 3.
Yes, I see that. This is why I suggested that it should be based on
sizeof(...d8) - 1 rather than sizeof(...d32) - 1. It makes more sense
to use the same field for both the size and the buffer pointer.
>
>>> + .cs_change = 1,
>>> + };
>>> + xfer[1] = (struct spi_transfer) {
>>> + .tx_buf = &st->data[1].d8[1],
>>> + .rx_buf = &st->data[2].d8[1],
>>> + .len = sizeof(st->data[1].d32) - 1,
>>
>> And here.
>>
>>> + };
>>> +
>>> + spi_message_init_with_transfers(&bus_data->msg, xfer, 2);
>>> +
>>> + ret = spi_sync(spi, &bus_data->msg);
>>> + if (ret)
>>> return ret;
>>>
>>> return be32_to_cpu(st->data[2].d32);
>>> @@ -95,12 +140,26 @@ static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
>>> static const struct ad5686_bus_ops ad5686_spi_ops = {
>>> .write = ad5686_spi_write,
>>> .read = ad5686_spi_read,
>>> + .sync = ad5686_spi_sync,
>>> };
>>>
>
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: clock: qcom-rpmhcc: Add RPMH clock controller for Maili
From: Krzysztof Kozlowski @ 2026-06-22 13:51 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260618-maili_initial_clock-v1-1-d6ede0352113@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:51:16PM +0530, Taniya Das wrote:
> Document the RPMH clock controller for the Qualcomm Maili SoC.
>
> Maili SoC is a derivative of the Hawi SoC and the rpmh clock controller
> is identical to that of Hawi. Therefore Maili uses the fallback
> compatible to reuse the Hawi rpmhcc driver.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> .../devicetree/bindings/clock/qcom,rpmhcc.yaml | 65 ++++++++++++----------
> 1 file changed, 35 insertions(+), 30 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] firmware: stratix10-svc: add support for agilex5
From: Adrian Ng Ho Yin @ 2026-06-22 13:44 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin
In-Reply-To: <cover.1782135785.git.adrian.ho.yin.ng@altera.com>
On Agilex5 the DDR base address starts at 0x8000_0000, which is
outside the addressable range of the SDM. The SMMU is used to remap
DDR-allocated buffers to an IOVA within the SDM-accessible 0-512MB
window. Return -ENODEV at probe if no IOMMU domain is found for an
intel,agilex5-svc device.
Configure a 29-bit DMA mask to constrain IOVA allocations to the
0-512MB range accessible to the SDM. Agilex5 REV B introduced a
hardware SDM address remapper; bypass it via SMC so no additional
offset is applied to the IOVA, keeping the implementation
consistent across all Agilex5 revisions.
ATF validates FPGA_CONFIG_WRITE addresses against the DDR range
starting at 0x8000_0000. Since IOVAs are below 0x2000_0000, the
driver adds 0x8000_0000 to the IOVA before the SMC call so ATF's
is_address_in_ddr_range() check passes. ATF then strips the offset
and uses the SMMU to translate the remaining IOVA to the underlying
physical memory for SDM access.
The firmware COMPLETED_WRITE response returns the raw IOVA without
the 0x8000_0000 offset. Compensate by storing dma_addr_offset in
the controller and adding it back before the svc_pa_to_va() lookup.
dma_addr_offset is zero on non-SMMU paths so existing platforms are
unaffected.
Fix a pre-existing bug in stratix10_svc_free_memory() where an
unknown-address fallthrough called list_del(&svc_data_mem),
corrupting the list head. Replace it with dev_warn().
Register a devm cleanup action at probe to reclaim any DMA
coherent buffers that service clients fail to free before driver
unbind, preventing memory leaks across probe/remove cycles.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
---
drivers/firmware/stratix10-svc.c | 258 +++++++++++++++----
include/linux/firmware/intel/stratix10-smc.h | 23 ++
2 files changed, 237 insertions(+), 44 deletions(-)
diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c
index 00e134e663c8..4140cc488d96 100644
--- a/drivers/firmware/stratix10-svc.c
+++ b/drivers/firmware/stratix10-svc.c
@@ -7,7 +7,9 @@
#include <linux/atomic.h>
#include <linux/completion.h>
#include <linux/delay.h>
+#include <linux/dma-mapping.h>
#include <linux/genalloc.h>
+#include <linux/iommu.h>
#include <linux/hashtable.h>
#include <linux/idr.h>
#include <linux/io.h>
@@ -43,6 +45,23 @@
#define FPGA_CONFIG_STATUS_TIMEOUT_SEC 30
#define BYTE_TO_WORD_SIZE 4
+/*
+ * SVC_SDM_DMA_ADDR_BITS - constrains the IOVA allocated by
+ * dma_alloc_coherent() to 29 bits (0x0000_0000 - 0x1FFF_FFFF)
+ * when SMMU is active on Agilex5. The SDM accesses these buffers
+ * via the SMMU using IOVAs, so the 29-bit limit keeps IOVAs within
+ * the SDM's addressable window.
+ *
+ * SVC_SDM_DMA_ADDR_OFFSET - ATF on Agilex5 distinguishes
+ * SMMU-mapped buffers from direct physical addresses by the
+ * presence of this offset. The driver adds it to the IOVA before
+ * passing the address to ATF via SMC; ATF strips it, translates
+ * the remaining IOVA through the SMMU, and the SDM accesses the
+ * underlying physical memory.
+ */
+#define SVC_SDM_DMA_ADDR_BITS 29
+#define SVC_SDM_DMA_ADDR_OFFSET 0x80000000UL
+
/* stratix10 service layer clients */
#define STRATIX10_RSU "stratix10-rsu"
@@ -133,18 +152,25 @@ struct stratix10_svc_sh_memory {
/**
* struct stratix10_svc_data_mem - service memory structure
* @vaddr: virtual address
- * @paddr: physical address
+ * @paddr: address passed to ATF via SMC and echoed back in completion
+ * notifications; used as the lookup key in svc_pa_to_va().
+ * On the SMMU path this is (IOVA + %SVC_SDM_DMA_ADDR_OFFSET);
+ * on the gen_pool path this equals the raw physical address.
* @size: size of memory
+ * @dma_addr: IOVA returned by dma_alloc_coherent(); used to free the
+ * mapping via dma_free_coherent() on the SMMU path.
* @node: link list head node
*
* This struct is used in a list that keeps track of buffers which have
* been allocated or freed from the memory pool. Service layer driver also
- * uses this struct to transfer physical address to virtual address.
+ * uses this struct to map the address returned by ATF back to a virtual
+ * address.
*/
struct stratix10_svc_data_mem {
void *vaddr;
phys_addr_t paddr;
size_t size;
+ dma_addr_t dma_addr;
struct list_head node;
};
@@ -277,6 +303,15 @@ struct stratix10_svc_chan {
* @svc: manages the list of client svc drivers
* @sdm_lock: only allows a single command single response to SDM
* @actrl: async control structure
+ * @use_dma_mem: when true, buffers are allocated via dma_alloc_coherent()
+ * instead of the ATF reserved-memory gen_pool.
+ * @dma_addr_offset: value added to the DMA address (IOVA) before passing it
+ * to ATF via SMC. ATF uses this offset to distinguish
+ * SMMU-mapped buffers from direct physical addresses; it
+ * strips the offset, translates the remaining IOVA through
+ * the SMMU, and the SDM accesses the underlying memory.
+ * Set to %SVC_SDM_DMA_ADDR_OFFSET on Agilex5 when SMMU is
+ * active; zero otherwise.
* @chans: array of service channels
*
* This struct is used to create communication channels for service clients, to
@@ -293,6 +328,8 @@ struct stratix10_svc_controller {
struct stratix10_svc *svc;
struct mutex sdm_lock;
struct stratix10_async_ctrl actrl;
+ bool use_dma_mem;
+ unsigned long dma_addr_offset;
struct stratix10_svc_chan chans[] __counted_by(num_chans);
};
@@ -318,11 +355,12 @@ static void *svc_pa_to_va(unsigned long addr)
pr_debug("claim back P-addr=0x%016x\n", (unsigned int)addr);
guard(mutex)(&svc_mem_lock);
- list_for_each_entry(pmem, &svc_data_mem, node)
+ list_for_each_entry(pmem, &svc_data_mem, node) {
if (pmem->paddr == addr)
return pmem->vaddr;
+ }
- /* physical address is not found */
+ /* address is not found */
return NULL;
}
@@ -356,11 +394,17 @@ static void svc_thread_cmd_data_claim(struct stratix10_svc_controller *ctrl,
break;
}
cb_data->status = BIT(SVC_STATUS_BUFFER_DONE);
- cb_data->kaddr1 = svc_pa_to_va(res.a1);
+ /*
+ * The firmware COMPLETED_WRITE response returns the
+ * raw IOVA (without dma_addr_offset). Add it back to
+ * match the key stored in pmem->paddr at allocation
+ * time. dma_addr_offset is zero on non-SMMU paths.
+ */
+ cb_data->kaddr1 = svc_pa_to_va(res.a1 + ctrl->dma_addr_offset);
cb_data->kaddr2 = (res.a2) ?
- svc_pa_to_va(res.a2) : NULL;
+ svc_pa_to_va(res.a2 + ctrl->dma_addr_offset) : NULL;
cb_data->kaddr3 = (res.a3) ?
- svc_pa_to_va(res.a3) : NULL;
+ svc_pa_to_va(res.a3 + ctrl->dma_addr_offset) : NULL;
p_data->chan->scl->receive_cb(p_data->chan->scl,
cb_data);
} else {
@@ -981,6 +1025,38 @@ svc_create_memory_pool(struct platform_device *pdev,
return genpool;
}
+/**
+ * svc_setup_dma_memory() - configure the device for dynamic DMA allocation
+ * @pdev: pointer to service layer device
+ *
+ * Called instead of svc_get_sh_memory() + svc_create_memory_pool() when
+ * the device is behind an SMMU. Sets a 29-bit coherent DMA mask so that
+ * every subsequent dma_alloc_coherent() call yields an IOVA within the
+ * first 512MB (0x0000_0000 - 0x1FFF_FFFF). The driver then adds
+ * %SVC_SDM_DMA_ADDR_OFFSET to the IOVA before passing it to ATF; ATF
+ * strips the offset and uses the SMMU to translate the IOVA to the
+ * underlying physical memory for SDM access.
+ *
+ * Return: 0 on success, or a negative error code on failure.
+ */
+static int svc_setup_dma_memory(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(SVC_SDM_DMA_ADDR_BITS));
+ if (ret) {
+ dev_err(dev,
+ "failed to set %u-bit DMA mask: %d\n",
+ SVC_SDM_DMA_ADDR_BITS, ret);
+ return ret;
+ }
+
+ dev_info(dev,
+ "SMMU enabled: using dynamic DMA allocation (IOVA range 0-512MB)\n");
+ return 0;
+}
+
/**
* svc_smccc_smc() - secure monitor call between normal and secure world
* @a0: argument passed in registers 0
@@ -1842,32 +1918,52 @@ EXPORT_SYMBOL_GPL(stratix10_svc_done);
void *stratix10_svc_allocate_memory(struct stratix10_svc_chan *chan,
size_t size)
{
+ struct stratix10_svc_controller *ctrl = chan->ctrl;
struct stratix10_svc_data_mem *pmem;
- unsigned long va;
- phys_addr_t pa;
- struct gen_pool *genpool = chan->ctrl->genpool;
- size_t s = roundup(size, 1 << genpool->min_alloc_order);
+ struct gen_pool *genpool;
+ dma_addr_t dma_addr;
+ size_t s;
+ void *va;
- pmem = devm_kzalloc(chan->ctrl->dev, sizeof(*pmem), GFP_KERNEL);
- if (!pmem)
- return ERR_PTR(-ENOMEM);
+ if (ctrl->use_dma_mem) {
+ pmem = kzalloc_obj(*pmem, GFP_KERNEL);
+ if (!pmem)
+ return ERR_PTR(-ENOMEM);
- guard(mutex)(&svc_mem_lock);
- va = gen_pool_alloc(genpool, s);
- if (!va)
- return ERR_PTR(-ENOMEM);
+ va = dma_alloc_coherent(ctrl->dev, size, &dma_addr, GFP_KERNEL);
+ if (!va) {
+ kfree(pmem);
+ return ERR_PTR(-ENOMEM);
+ }
- memset((void *)va, 0, s);
- pa = gen_pool_virt_to_phys(genpool, va);
+ pmem->vaddr = va;
+ pmem->paddr = dma_addr + ctrl->dma_addr_offset;
+ pmem->dma_addr = dma_addr;
+ pmem->size = size;
+ } else {
+ genpool = ctrl->genpool;
+ s = roundup(size, 1 << genpool->min_alloc_order);
+
+ pmem = devm_kzalloc(ctrl->dev, sizeof(*pmem), GFP_KERNEL);
+ if (!pmem)
+ return ERR_PTR(-ENOMEM);
+
+ va = (void *)gen_pool_alloc(genpool, s);
+ if (!va)
+ return ERR_PTR(-ENOMEM);
+
+ memset(va, 0, s);
+ pmem->vaddr = va;
+ pmem->paddr = gen_pool_virt_to_phys(genpool, (unsigned long)va);
+ pmem->size = s;
+ }
- pmem->vaddr = (void *)va;
- pmem->paddr = pa;
- pmem->size = s;
+ guard(mutex)(&svc_mem_lock);
list_add_tail(&pmem->node, &svc_data_mem);
- pr_debug("%s: %s: va=%p, pa=0x%016x\n", __func__,
- chan->name, pmem->vaddr, (unsigned int)pmem->paddr);
+ pr_debug("%s: %s: va=%p, addr=0x%016llx\n", __func__,
+ chan->name, pmem->vaddr, (unsigned long long)pmem->paddr);
- return (void *)va;
+ return va;
}
EXPORT_SYMBOL_GPL(stratix10_svc_allocate_memory);
@@ -1880,25 +1976,37 @@ EXPORT_SYMBOL_GPL(stratix10_svc_allocate_memory);
*/
void stratix10_svc_free_memory(struct stratix10_svc_chan *chan, void *kaddr)
{
+ struct stratix10_svc_controller *ctrl = chan->ctrl;
struct stratix10_svc_data_mem *pmem;
+
guard(mutex)(&svc_mem_lock);
- list_for_each_entry(pmem, &svc_data_mem, node)
- if (pmem->vaddr == kaddr) {
- gen_pool_free(chan->ctrl->genpool,
- (unsigned long)kaddr, pmem->size);
+ list_for_each_entry(pmem, &svc_data_mem, node) {
+ if (pmem->vaddr != kaddr)
+ continue;
+
+ if (ctrl->use_dma_mem) {
+ dma_free_coherent(ctrl->dev, pmem->size,
+ pmem->vaddr, pmem->dma_addr);
+ list_del(&pmem->node);
+ kfree(pmem);
+ } else {
+ gen_pool_free(ctrl->genpool,
+ (unsigned long)kaddr, pmem->size);
pmem->vaddr = NULL;
list_del(&pmem->node);
- return;
}
+ return;
+ }
- list_del(&svc_data_mem);
+ dev_warn(ctrl->dev, "free of unknown buffer %p\n", kaddr);
}
EXPORT_SYMBOL_GPL(stratix10_svc_free_memory);
static const struct of_device_id stratix10_svc_drv_match[] = {
{.compatible = "intel,stratix10-svc"},
{.compatible = "intel,agilex-svc"},
+ {.compatible = "intel,agilex5-svc"},
{},
};
@@ -1909,13 +2017,39 @@ static const char * const chan_names[SVC_NUM_CHANNEL] = {
SVC_CLIENT_HWMON
};
+static void svc_data_mem_cleanup(void *data)
+{
+ struct stratix10_svc_controller *ctrl = data;
+ struct stratix10_svc_data_mem *pmem, *tmp;
+
+ guard(mutex)(&svc_mem_lock);
+
+ list_for_each_entry_safe(pmem, tmp, &svc_data_mem, node) {
+ dev_warn(ctrl->dev, "leaked svc buffer %p, freeing on unbind\n",
+ pmem->vaddr);
+ if (ctrl->use_dma_mem) {
+ dma_free_coherent(ctrl->dev, pmem->size,
+ pmem->vaddr, pmem->dma_addr);
+ list_del(&pmem->node);
+ kfree(pmem);
+ } else {
+ gen_pool_free(ctrl->genpool,
+ (unsigned long)pmem->vaddr, pmem->size);
+ pmem->vaddr = NULL;
+ list_del(&pmem->node);
+ }
+ }
+}
+
static int stratix10_svc_drv_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct stratix10_svc_controller *controller;
- struct gen_pool *genpool;
+ struct gen_pool *genpool = NULL;
struct stratix10_svc_sh_memory *sh_memory;
struct stratix10_svc *svc = NULL;
+ struct arm_smccc_res res;
+ bool use_dma_mem = false;
svc_invoke_fn *invoke_fn;
size_t fifo_size;
@@ -1926,18 +2060,47 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev)
if (IS_ERR(invoke_fn))
return -EINVAL;
- sh_memory = devm_kzalloc(dev, sizeof(*sh_memory), GFP_KERNEL);
- if (!sh_memory)
- return -ENOMEM;
+ /*
+ * Agilex5-specific setup: SMMU is required as the base address of the DDR memory for Agilex5 starts from
+ * 0x8000_0000 which is out of the addressible range of the SDM. SMMU is enabled to allow memory allocated
+ * within the DDR to be remapped to the accessible address range of the SDM. An address remapper is implemented
+ * in Agilex5 REV B, the SDM address remapper must be bypassed so there is no additional offset applied to the
+ * IOVA to keep implementation consistent across all Agilex5 revisions.
+ */
+ if (of_device_is_compatible(dev->of_node, "intel,agilex5-svc")) {
+ if (!iommu_get_domain_for_dev(dev)) {
+ dev_err(dev,
+ "SMMU is required for agilex5-svc but no IOMMU domain found\n");
+ dev_err(dev,
+ "Ensure the SMMU node is enabled in the device tree and 'iommus' is set for this node\n");
+ return -ENODEV;
+ }
- sh_memory->invoke_fn = invoke_fn;
- ret = svc_get_sh_memory(pdev, sh_memory);
- if (ret)
- return ret;
+ use_dma_mem = true;
- genpool = svc_create_memory_pool(pdev, sh_memory);
- if (IS_ERR(genpool))
- return PTR_ERR(genpool);
+ invoke_fn(INTEL_SIP_SMC_SDM_REMAPPER_CONFIG,
+ INTEL_SIP_SMC_SDM_REMAPPER_BYPASS,
+ 0, 0, 0, 0, 0, 0, &res);
+ }
+
+ if (use_dma_mem) {
+ ret = svc_setup_dma_memory(pdev);
+ if (ret)
+ return ret;
+ } else {
+ sh_memory = devm_kzalloc(dev, sizeof(*sh_memory), GFP_KERNEL);
+ if (!sh_memory)
+ return -ENOMEM;
+
+ sh_memory->invoke_fn = invoke_fn;
+ ret = svc_get_sh_memory(pdev, sh_memory);
+ if (ret)
+ return ret;
+
+ genpool = svc_create_memory_pool(pdev, sh_memory);
+ if (IS_ERR(genpool))
+ return PTR_ERR(genpool);
+ }
/* allocate service controller and supporting channel */
controller = devm_kzalloc(dev, struct_size(controller, chans, SVC_NUM_CHANNEL),
@@ -1952,9 +2115,15 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev)
controller->num_active_client = 0;
controller->genpool = genpool;
controller->invoke_fn = invoke_fn;
+ controller->use_dma_mem = use_dma_mem;
+ controller->dma_addr_offset = use_dma_mem ? SVC_SDM_DMA_ADDR_OFFSET : 0;
INIT_LIST_HEAD(&controller->node);
init_completion(&controller->complete_status);
+ ret = devm_add_action_or_reset(dev, svc_data_mem_cleanup, controller);
+ if (ret)
+ goto err_destroy_pool;
+
ret = stratix10_svc_async_init(controller);
if (ret) {
dev_dbg(dev, "Intel Service Layer Driver: Error on stratix10_svc_async_init %d\n",
@@ -2022,7 +2191,8 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev)
kfifo_free(&controller->chans[i].svc_fifo);
stratix10_svc_async_exit(controller);
err_destroy_pool:
- gen_pool_destroy(genpool);
+ if (genpool)
+ gen_pool_destroy(genpool);
return ret;
}
diff --git a/include/linux/firmware/intel/stratix10-smc.h b/include/linux/firmware/intel/stratix10-smc.h
index 9116512169dc..daa693699c97 100644
--- a/include/linux/firmware/intel/stratix10-smc.h
+++ b/include/linux/firmware/intel/stratix10-smc.h
@@ -746,4 +746,27 @@ INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_COMPLETED_WRITE)
#define INTEL_SIP_SMC_ASYNC_FUNC_ID_RSU_NOTIFY (0xEC)
#define INTEL_SIP_SMC_ASYNC_RSU_NOTIFY \
INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_RSU_NOTIFY)
+
+/**
+ * Request INTEL_SIP_SMC_SDM_REMAPPER_CONFIG
+ *
+ * Sync call to configure the SDM address remapper. On Agilex5, the remapper
+ * must be bypassed when the SMMU is active to avoid conflicts with IOMMU
+ * address translation.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_SDM_REMAPPER_CONFIG
+ * a1: INTEL_SIP_SMC_SDM_REMAPPER_ENABLE or INTEL_SIP_SMC_SDM_REMAPPER_BYPASS
+ * a2-7: not used
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK
+ * a1-3: not used
+ */
+#define INTEL_SIP_SMC_FUNCID_SDM_REMAPPER_CONFIG 513
+#define INTEL_SIP_SMC_SDM_REMAPPER_CONFIG \
+ INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_SDM_REMAPPER_CONFIG)
+#define INTEL_SIP_SMC_SDM_REMAPPER_ENABLE 0
+#define INTEL_SIP_SMC_SDM_REMAPPER_BYPASS 1
+
#endif
--
2.49.GIT
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: socfpga: agilex5: add FPGA manager and region nodes
From: Adrian Ng Ho Yin @ 2026-06-22 13:44 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin
In-Reply-To: <cover.1782135785.git.adrian.ho.yin.ng@altera.com>
Add the fpga-mgr child node under the svc firmware node and a fpga-region
node to enable FPGA configuration and partial reconfiguration on Agilex5.
Also enable the SMMU by removing the disabled status from the smmu
node, which is required for the svc driver to allocate DMA buffers
within the SDM-accessible address range.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
---
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 02e62d954e94..1cd9773a1500 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -85,9 +85,20 @@ svc {
method = "smc";
memory-region = <&service_reserved>;
iommus = <&smmu 10>;
+
+ fpga_mgr: fpga-mgr {
+ compatible = "intel,agilex-soc-fpga-mgr";
+ };
};
};
+ fpga-region {
+ compatible = "fpga-region";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ fpga-mgr = <&fpga_mgr>;
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
@@ -385,7 +396,6 @@ smmu: iommu@16000000 {
interrupt-names = "eventq", "gerror", "priq";
dma-coherent;
#iommu-cells = <1>;
- status = "disabled";
};
spi0: spi@10da4000 {
--
2.49.GIT
^ permalink raw reply related
* [PATCH 0/2] Add FPGA configuration and partial reconfiguration support for Agilex5
From: Adrian Ng Ho Yin @ 2026-06-22 13:44 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin
This series enables FPGA configuration and partial reconfiguration on Altera Agilex5 SoC.
On Agilex5 the DDR base address starts at 0x8000_0000, which is
outside the addressable range of the SDM. The SMMU is used to remap
DDR-allocated buffers to an IOVA within the SDM-accessible 0-512MB
window. Agilex5 REV B introduced a hardware SDM address remapper,
but it must be bypassed so no additional offset is applied to the
IOVA, keeping the implementation consistent across all Agilex5
revisions.
Patch 1 adds the fpga-mgr child node and fpga-region to the Agilex5
DTSI and enables the SMMU, which is always required on Agilex5 for
the service layer to operate correctly.
Patch 2 extends the stratix10-svc driver to support the new
intel,agilex5-svc compatible. It enforces SMMU presence at probe,
configures a 29-bit DMA mask, and bypasses the SDM address remapper
via SMC. The driver adds 0x8000_0000 to each IOVA before the SMC
call so the address passes ATF's is_address_in_ddr_range() check;
the firmware COMPLETED_WRITE response returns the raw IOVA, so the
offset is added back before the svc_pa_to_va() lookup. It also
fixes a pre-existing list corruption bug in
stratix10_svc_free_memory() and adds a devm cleanup action to
reclaim leaked buffers on driver unbind.
Adrian Ng Ho Yin (2):
arm64: dts: socfpga: agilex5: add FPGA manager and region nodes
firmware: stratix10-svc: add support for agilex5
.../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 12 +-
drivers/firmware/stratix10-svc.c | 258 +++++++++++++++---
include/linux/firmware/intel/stratix10-smc.h | 23 ++
3 files changed, 248 insertions(+), 45 deletions(-)
--
2.49.GIT
^ permalink raw reply
* Re: [PATCH v1 6/8] arm64: dts: qcom: shikra-cqs-evk: Enable sound card support
From: Krzysztof Kozlowski @ 2026-06-22 13:47 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel,
Pratyush Meduri
In-Reply-To: <20260616201315.2565115-7-mohammad.rafi.shaik@oss.qualcomm.com>
On 16/06/2026 22:13, Mohammad Rafi Shaik wrote:
>
> +&i2c3 {
> + status = "okay";
> +
> + wsa885x_i2c: speaker@c {
> + compatible = "qcom,wsa885x-i2c";
NAK.
There is no such compatible. And there will never be.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 5/8] arm64: dts: qcom: shikra-cqm-evk: Enable sound card support
From: Krzysztof Kozlowski @ 2026-06-22 13:46 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260616201315.2565115-6-mohammad.rafi.shaik@oss.qualcomm.com>
On 16/06/2026 22:13, Mohammad Rafi Shaik wrote:
> +
> wcn3988-pmu {
> compatible = "qcom,wcn3988-pmu";
>
> @@ -60,6 +129,79 @@ vreg_pmu_ch1: ldo4 {
> };
> };
>
> +&gpr {
> + status = "disabled";
> +};
> +
> +&i2c3 {
> + status = "okay";
> +
> + wsa885x_i2c: speaker@c {
> + compatible = "qcom,wsa885x-i2c";
This was EXPLICITLY NAKED as in disagreed.
When you receive a NAK for a binding, you cannot send a DTS six days
later having that wrong compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/8] arm64: dts: qcom: shikra: Add gpr node
From: Krzysztof Kozlowski @ 2026-06-22 13:44 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel,
Pratyush Meduri
In-Reply-To: <20260616201315.2565115-4-mohammad.rafi.shaik@oss.qualcomm.com>
On 16/06/2026 22:13, Mohammad Rafi Shaik wrote:
> Add GPR(Generic Pack router) node along with
Missing spaces before (.
> APM(Audio Process Manager) and PRM(Proxy resource
> Manager) audio services.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> @@ -1851,6 +1854,42 @@ glink-edge {
> mboxes = <&apcs_glb 12>;
> qcom,remote-pid = <1>;
> label = "mpss";
> +
> + gpr: gpr {
> + compatible = "qcom,gpr";
> + qcom,glink-channels = "modem_apps";
> + qcom,domain = <GPR_DOMAIN_ID_MODEM>;
> + qcom,intents = <200 20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + q6apm: service@1 {
> + compatible = "qcom,q6apm";
> + reg = <GPR_APM_MODULE_IID>;
> + #sound-dai-cells = <0>;
> +
> + q6apmbedai: bedais {
> + compatible = "qcom,q6apm-lpass-dais";
> + #sound-dai-cells = <1>;
> + };
> +
> + q6apmdai: dais {
> + compatible = "qcom,q6apm-dais";
> + qcom,vmid = <QCOM_SCM_VMID_LPASS
> + QCOM_SCM_VMID_MSS_MSA>;
I don't understand what is happening here.
Other patch made a change like:
-qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
But even here you do not have it.
I don't understand what is happening here, but for now it looks that
this patchset is incorrect and incomplete.
> + };
> + };
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: shikra: Add MDSP carveout memory and update APM DAIs memory regions
From: Krzysztof Kozlowski @ 2026-06-22 13:42 UTC (permalink / raw)
To: Ajay Kumar Nandam
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260618113509.2025881-3-ajay.nandam@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 05:05:09PM +0530, Ajay Kumar Nandam wrote:
> Add a dedicated MDSP carveout memory region for audio usecases on
> Shikra and mark both existing audio heap and MDSP carveout regions
> as shared DMA pools.
>
> Update the Q6 APM DAI node to reference multiple memory regions,
> where index 0 is used for control path buffers and index 1 is used
> for MDSP data path buffers. This separation ensures proper memory
> allocation and access for APM communication between APSS and MDSP.
>
> Also add shared-dma-pool compatibility to the existing audio heap
> region to align with upstream DMA pool usage.
>
> Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 88954ee943ef..d744f7e38ca6 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -365,7 +365,14 @@ smem_mem: smem@86000000 {
> };
>
> audio_heap_mem: audio-heap@86200000 {
> - reg = <0x0 0x86200000 0x0 0x100000>;
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x86200000 0x0 0x40000>;
> + no-map;
> + };
> +
> + audio_mdsp_carveout_mem: audio-mdsp-carveout@86240000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x86240000 0x0 0x100000>;
> no-map;
> };
>
> @@ -1935,7 +1942,10 @@ q6apmbedai: bedais {
>
> q6apmdai: dais {
> compatible = "qcom,q6apm-dais";
> - qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
There is no such line in next-20260619, which means this is some wrong
base.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: sound: qcom,q6apm-dai: add memory-region property
From: Krzysztof Kozlowski @ 2026-06-22 13:41 UTC (permalink / raw)
To: Ajay Kumar Nandam
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260618113509.2025881-2-ajay.nandam@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 05:05:08PM +0530, Ajay Kumar Nandam wrote:
> Document the new memory-region property that allows one or more
> reserved-memory carveout regions to be SCM-assigned to the VMIDs
> listed in qcom,vmid.
>
> - Add memory-region as an optional phandle-array (1-8 entries).
> Each entry must point to a shared-dma-pool, no-map reserved-memory
> node. Index 0 is the control-path buffer; subsequent entries are
> data-path buffers.
> - Enforce via dependentRequired that memory-region is only valid
> when qcom,vmid is also present.
> - Expand qcom,vmid description to mention carveout regions and the
> qcom_scm_is_available() probe-defer requirement.
> - Add a second example showing both properties in use with two
> carveout regions and two destination VMIDs.
>
> Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
> ---
> .../bindings/sound/qcom,q6apm-dai.yaml | 38 +++++++++++++++++--
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
> index b767625985a7..601055182da6 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
> @@ -10,7 +10,11 @@ maintainers:
> - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> description: |
> - This binding describes the Qualcomm APM DAIs in DSP
> + This binding describes the Qualcomm APM DAIs in DSP.
> + When qcom,vmid is present, the driver performs SCM memory
> + assignment for PCM DMA buffers and any reserved-memory regions
> + listed in memory-region, granting the specified VMIDs RW access
> + while retaining HLOS as a co-owner.
>
> properties:
> compatible:
> @@ -20,9 +24,24 @@ properties:
> minItems: 1
> maxItems: 2
>
> + memory-region:
> + description:
> + List of phandles to reserved-memory regions (shared-dma-pool,
> + no-map) that must be SCM-assigned to the VMIDs in qcom,vmid.
> + The first entry is the control-path buffer; subsequent entries
> + are data-path buffers. Only meaningful when qcom,vmid is present.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Drop ref, not needed.
> + items:
> + maxItems: 1
> + minItems: 1
> + maxItems: 8
> +
> qcom,vmid:
> - description: Optional list of destination VMIDs to share PCM DMA buffers with.
> - HLOS retains RW access as source owner and must not be listed.
This is confusing context. There is no qcom,vmid in this file.
Anyway, I think adding SCM interface and handling of VMIDs is quite
different design of this firmware/hardware, thus this should be a
different compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 8/8] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Qiang Yu @ 2026-06-22 13:34 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <a9506482-aa46-40b9-830b-afc259f9e47e@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 01:37:06PM +0200, Konrad Dybcio wrote:
> On 6/22/26 7:11 AM, Qiang Yu wrote:
> > PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
> > clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
> > directly instead.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
>
> This must be squashed with patch 7, otherwise PCIe won't probe on
> Mahua
>
Okay, will squash it with patch 7 in next version.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH v6 7/8] arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
From: Qiang Yu @ 2026-06-22 13:31 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <e6c0971b-ec41-4914-aa34-6caef51d2327@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 02:18:54PM +0200, Konrad Dybcio wrote:
> On 6/22/26 7:11 AM, Qiang Yu wrote:
> > Mahua has a different PCIe QREF topology from glymur. Override the TCSR
> > compatible to qcom,mahua-tcsr in mahua.dtsi, and wire up the required
> > LDO supplies for the PCIe clkref paths on the CRD board.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/mahua-crd.dts | 15 +++++++++++++++
> > arch/arm64/boot/dts/qcom/mahua.dtsi | 4 ++++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/mahua-crd.dts b/arch/arm64/boot/dts/qcom/mahua-crd.dts
> > index 9c8244e892dd..8b42f5174b31 100644
> > --- a/arch/arm64/boot/dts/qcom/mahua-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/mahua-crd.dts
> > @@ -19,3 +19,18 @@ / {
> > model = "Qualcomm Technologies, Inc. Mahua CRD";
> > compatible = "qcom,mahua-crd", "qcom,mahua";
> > };
> > +
> > +&tcsr {
> > + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt3-0p9-supply = <&vreg_l1f_e1_0p82>;
> > + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
> > + vdda-qrefrpt5-0p9-supply = <&vreg_l2h_e0_0p72>;
> > + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrx3-0p9-supply = <&vreg_l2h_e0_0p72>;
> > + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> > + vdda-refgen3-0p9-supply = <&vreg_l1f_e1_0p82>;
> > + vdda-refgen3-1p2-supply = <&vreg_l4f_e1_1p08>;
>
> The supplies are correct, but QREF uses refgen4 on Mahua
>
The instance is REFGEN4, but its regulator name is refgen3_xxx. Do you
think rename the supplies as vdda-refgen4-0p9-supply is better?
> There's also rx0 with a 0p9 supply on l2f_e1
Okay, RX0 is required for USB and EDP, will add it.
- Qaing Yu
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
From: Geert Uytterhoeven @ 2026-06-22 13:30 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-5-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:41, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> RZ/G3E SMARC board has a DA7212 audio codec connected via I2C1 for
> sound input/output using SSI3/SSI4 where:
>
> - The codec receives its master clock from the Versa3 clock
> generator present on the SoM
> - SSI4 shares clock pins with SSI3 to provide a separate data
> line for full-duplex audio capture.
>
> Enable audio support on RZ/G3E SMARC2 EVK boards with a DA7212 audio codec.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v6: No changes.
> v5:
> - Drop the unnecessary #address-cells / #size-cells from the
> codec@1a node; the port child has no unit address or reg, and the
> da7212 binding sets unevaluatedProperties: false.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 3/4] arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
From: Geert Uytterhoeven @ 2026-06-22 13:30 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-4-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:41, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add pinmux definitions for SSI3/SSI4 audio interface on RZ/G3E SMARC SoM:
>
> - sound_clk_pins: AUDIO_CLKB and AUDIO_CLKC clock outputs
> - sound_pins: SSI3_SCK, SSI3_WS, SSI3_SDATA (playback) and
> SSI4_SDATA (capture)
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v6: No changes.
> v5:
> - Rename the sound_clk / sound pinctrl node names to use hyphens
> instead of underscores.
> - Sort the sound pinmux entries by GPIO number.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 2/4] arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
From: Geert Uytterhoeven @ 2026-06-22 13:30 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-3-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add the Renesas 5P35023 (Versa3) programmable clock generator on the
> I2C2 bus along with its 24MHz input clock (x2 oscillator) to feed the
> audio subsystem.
>
> The Versa3 provides the following clock outputs:
> - Output 0: 24MHz (reference)
> - Output 1: 12.288MHz (audio, 48kHz family)
> - Output 2: 11.2896MHz (audio, 44.1kHz family)
> - Output 3: 12.288MHz (audio)
> - Output 4: 25MHz (DIFF1, Ethernet)
>
> These clocks are required for the audio codec and the Ethernet
> controller found on the RZ/G3E SMARC EVK.
>
> Output 5 (DIFF2) is left out, as it is not connected on this board.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v6:
> - Actually drop Versa3 output 5 (DIFF2) from assigned-clocks and
> assigned-clock-rates; v5 documented the removal in the commit
> message but left the entry in the DTS.
> v5:
> - Document output 4 (DIFF1) in the commit message; it is needed for
> Ethernet.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 13:29 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <CAMuHMdVVm8CjeBthANW7BCJ2+4jByCfVamwe-NGPb1YzZQy_bg@mail.gmail.com>
On Mon, 22 Jun 2026 at 12:19, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 19 Jun 2026 at 10:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> > Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
> >
> > - SSI (Serial Sound Interface) units 0-9
> > - SSIU (Serial Sound Interface Unit) units 0-27
> > - SRC (Sample Rate Converter) units 0-9
> > - CTU (Channel Transfer Unit) units 0-7
> > - DVC (Digital Volume Control) units 0-1
> > - MIX (Mixer) units 0-1
> >
> > Sub-node names follow the new RZ/G3E sound binding: unprefixed
> > 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> > the legacy 'rcar_sound,xxx' R-Car prefix.
> >
> > Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> > with repeated channel names, so that the DMA core can pick the first
> > available controller.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > ---
> >
> > Chqnges:
> >
> > v6: No changes.
>
> So same stylistic issues as v5.
> No need to resend just for this (every resend consumes review time on
> my side), I may fix it while applying.
The rest LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3 with the style issues fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Krzysztof Kozlowski @ 2026-06-22 13:26 UTC (permalink / raw)
To: Patrice Chotard
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Christophe Kerello, linux-spi,
devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-add_power_domain_for_qpsi-v1-1-4d7e57bcfb9a@foss.st.com>
On Thu, Jun 18, 2026 at 08:46:35AM +0200, Patrice Chotard wrote:
> STM32 QSPI may be in a power domain. Allow a single 'power-domains'
> entry for STM32 QSPI.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
> Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties
From: Krzysztof Kozlowski @ 2026-06-22 13:25 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Sandy Huang, Heiko Stübner, Andy Yan, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
kernel, Andy Yan, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260617-dw-hdmi-qp-yuv-v1-1-a665cfd06d7d@collabora.com>
On Wed, Jun 17, 2026 at 09:51:54PM +0300, Cristian Ciocaltea wrote:
> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
> provided only on RK3588.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> .../bindings/display/rockchip/rockchip-vop2.yaml | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 6/8] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
From: Qiang Yu @ 2026-06-22 13:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <314bab03-5f19-4954-9ad6-fe14d429ff5a@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 02:16:45PM +0200, Konrad Dybcio wrote:
> On 6/22/26 7:11 AM, Qiang Yu wrote:
> > The TCSR clkref_en clocks gate the QREF block which provides reference
> > clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
> > and refgen blocks on the CRD board.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
> > index c98dfb3941fa..92b929ee3448 100644
> > --- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
> > @@ -278,6 +278,26 @@ &smb2370_k_e2_eusb2_repeater {
> > vdd3-supply = <&vreg_l7b_e0_2p79>;
> > };
> >
> > +&tcsr {
> > + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
>
> l2c_e0
For COB, it is l2h_e0. L2c_e0 is used in SIP.
>
> > + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
>
> l2c_e0
>
> > + vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> > + vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
>
> l2c_e0
>
> > + vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
> > + vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
> > + vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
>
> l4c_e0
Same as l2c_e0
- Qiang Yu
>
> > + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> > + vdda-refgen3-0p9-supply = <&vreg_l2f_e0_0p82>;
> > + vdda-refgen3-1p2-supply = <&vreg_l4h_e0_1p2>;
>
> l4c_e0
>
> Konrad
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 13:23 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, dri-devel, robh, conor+dt, linux-phy,
olteanv, devicetree, wsa+renesas
In-Reply-To: <20260622101959.37DB41F00A3D@smtp.kernel.org>
On 22/06/2026 12:19, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Unintended replacement of BNF notation `::=` with `:=`.
> --
>
> commit a9fdd0b065eb5b6394a9c33ffba0fd5194e80115
> Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> dt-bindings: Drop incorrect usage of double '::'
>
> This commit cleans up device tree binding schemas by removing the redundant
> double colons at the end of descriptions inside YAML literal style blocks.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
>
>> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> index 9e2d78a78e409..769243a2bf046 100644
>> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> @@ -13,8 +13,8 @@ description: |
>> Mux controller consumers should specify a list of mux controllers that they
>> want to use with a property containing a 'mux-ctrl-list':
>>
>> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
>> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
>> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
>> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
>
> [Severity: Low]
> Does this unintentionally change the standard Backus-Naur Form (BNF) ::=
> operator to :=? It looks like a global search-and-replace for :: might
I wasn't sure about that... and indeed this should not be changed. I
will send a v2.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/8] ASoC: dt-bindings: qcom,apr: Add modem_apps GLINK channel for shikra
From: Krzysztof Kozlowski @ 2026-06-22 13:20 UTC (permalink / raw)
To: Mohammad Rafi Shaik
Cc: Srinivas Kandagatla, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260616201315.2565115-2-mohammad.rafi.shaik@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 01:43:08AM +0530, Mohammad Rafi Shaik wrote:
> Add support for the modem_apps GLINK channel on Shikra, as audio
> processing is handled through the modem DSP.
>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox