* Re: [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers
From: Mark Brown @ 2026-03-30 15:48 UTC (permalink / raw)
To: Herve Codina
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: <20260330173944.3fdc27ec@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support
From: Conor Dooley @ 2026-03-30 15:54 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, charles
In-Reply-To: <20260330102724.1012470-2-minachou@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 19678 bytes --]
On Mon, Mar 30, 2026 at 06:27:18PM +0800, Hui Min Mina Chou wrote:
> Andes cache driver is not only usable with the AX45MP CPU but can also be
> applied to other CPU within Andes platform (such as A27L2).
> To improve maintainability and support future SoCs, this patch performs a
> comprehensive refactoring to move away from model-specific naming.
>
> key changes include:
> - replaced AX45MP-specific Kconfig and function names with generic "ANDES"
> prefixes to support multiple CPU types
> - updated all L2-related identifiers, structs, and prefixes to "LLC"
> to accurately reflect its role as the system's last-level cache
> - moved UCCTL* CSR definitions to <linux/soc/andes/csr.h>
Why? There's no user outside of the driver.
> - standardized L1D and LLC macro prefixes (ANDES_L1D_* and ANDES_LLC_*)
> for better clarity
> - renamed compatible strings from ax45mp-cache to generic llcache
> - rename ax45mp_cache.c to andes_llcache.c
This patch is, quite frankly, unreviewable. There's various additions
and changes hidden in here alongside renames. Every bullet point here
should be a patch, and then maybe I see some of them as trivial and
squash them, but what's here is just too annoying to spot what is a
rename and what is a snuck-in change.
>
> This is a structural refactoring; no functional behavior is changed.
You broke all users by removing a compatible, so this is clearly false.
>
> Signed-off-by: charles <dminus@andestech.com>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
All patches in this series that have more than one signoff have a
problem. You're the last signoff and the author, what did any of these
other people do? Were they the real authors and authorship is screwed
up? Or should these people have Co-developed-by tags?
Thanks,
Conor.
> ---
> arch/riscv/Kconfig.errata | 2 +-
> drivers/cache/Kconfig | 6 +-
> drivers/cache/Makefile | 2 +-
> drivers/cache/andes_llcache.c | 224 ++++++++++++++++++++++++++++++++++
> drivers/cache/ax45mp_cache.c | 217 --------------------------------
> drivers/soc/renesas/Kconfig | 2 +-
> include/linux/soc/andes//Rcsr.h | 12 ++
> 7 files changed, 242 insertions(+), 223 deletions(-)
> create mode 100644 drivers/cache/andes_llcache.c
> delete mode 100644 drivers/cache/ax45mp_cache.c
> create mode 100644 include/linux/soc/andes/csr.h
>
> diff --git a/arch/riscv/Kconfig.errata b/arch/riscv/Kconfig.errata
> index 3c945d086c7d..e32f1563ce3a 100644
> --- a/arch/riscv/Kconfig.errata
> +++ b/arch/riscv/Kconfig.errata
> @@ -1,7 +1,7 @@
> menu "CPU errata selection"
>
> config ERRATA_ANDES
> - bool "Andes AX45MP errata"
> + bool "Andes errata"
> depends on RISCV_ALTERNATIVE && RISCV_SBI
> help
> All Andes errata Kconfig depend on this Kconfig. Disabling
> diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> index 1518449d47b5..78142189f45c 100644
> --- a/drivers/cache/Kconfig
> +++ b/drivers/cache/Kconfig
> @@ -10,11 +10,11 @@ menuconfig CACHEMAINT_FOR_DMA
>
> if CACHEMAINT_FOR_DMA
>
> -config AX45MP_L2_CACHE
> - bool "Andes Technology AX45MP L2 Cache controller"
> +config ANDES_CACHE
> + bool "Andes platform CPUs Cache controller"
> select RISCV_NONSTANDARD_CACHE_OPS
> help
> - Support for the L2 cache controller on Andes Technology AX45MP platforms.
> + Support for the L1 and LLC (last level cache) controller on Andes platform CPUs.
>
> config SIFIVE_CCACHE
> bool "Sifive Composable Cache controller"
> diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
> index b3362b15d6c1..4a218ad6cec0 100644
> --- a/drivers/cache/Makefile
> +++ b/drivers/cache/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -obj-$(CONFIG_AX45MP_L2_CACHE) += ax45mp_cache.o
> +obj-$(CONFIG_ANDES_CACHE) += andes_llcache.o
> obj-$(CONFIG_SIFIVE_CCACHE) += sifive_ccache.o
> obj-$(CONFIG_STARFIVE_STARLINK_CACHE) += starfive_starlink_cache.o
>
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> new file mode 100644
> index 000000000000..d5e382f3c801
> --- /dev/null
> +++ b/drivers/cache/andes_llcache.c
> @@ -0,0 +1,224 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * non-coherent cache operations for Andes Platform CPUs.
> + *
> + * Copyright (C) 2023 Renesas Electronics Corp.
> + */
> +
> +#include <linux/cacheflush.h>
> +#include <linux/cacheinfo.h>
> +#include <linux/dma-direction.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/soc/andes/csr.h>
> +
> +#include <asm/dma-noncoherent.h>
> +
> +/* L1 D-cache operation encoding */
> +#define ANDES_L1D_CCTL_VA_INVAL 0x0 /* Invalidate an L1D cacheline */
> +#define ANDES_L1D_CCTL_VA_WB 0x1 /* Write-back an L1D cacheline */
> +#define ANDES_L1D_CCTL_VA_WBINVAL 0x2 /* Flush an L1D cacheline */
> +#define ANDES_L1D_CCTL_WBINVAL_ALL 0x6 /* Flush the entire L1D cache */
> +
> +/* LLC registers */
> +#define ANDES_LLC_REG_CFG_OFFSET 0x0
> +#define ANDES_LLC_REG_CTRL_OFFSET 0x8
> +#define ANDES_LLC_REG_ASYNC_ERR_OFFSET 0x30
> +#define ANDES_LLC_REG_ERR_OFFSET 0x38
> +#define ANDES_LLC_REG_CCTL_CMD_OFFSET_C0 0x40
> +#define ANDES_LLC_REG_CCTL_ACC_OFFSET_C0 0x48
> +#define ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0 0x80
> +
> +/* LLC CCTL status encoding */
> +#define ANDES_LLC_CCTL_STATUS_IDLE 0x0
> +#define ANDES_LLC_CCTL_STATUS_RUNNING 0x1
> +#define ANDES_LLC_CCTL_STATUS_ILLEGAL 0x2
> +
> +/* LLC CCTL status core 0 mask */
> +#define ANDES_LLC_CCTL_STATUS_MASK_C0 GENMASK(3, 0)
> +
> +/* LLC operation encoding */
> +#define ANDES_LLC_CCTL_PA_INVAL 0x8 /* Invalidate an LLC cacheline */
> +#define ANDES_LLC_CCTL_PA_WB 0x9 /* Write-back an LLC cacheline */
> +#define ANDES_LLC_CCTL_PA_WBINVAL 0xa /* Flush an LLC cacheline */
> +#define ANDES_LLC_CCTL_WBINVAL_ALL 0x12 /* Flush the entire LLC cache */
> +
> +/* LLC CCTL registers and fields by core */
> +#define ANDES_LLC_REG_PER_CORE_OFFSET 0x10
> +#define ANDES_CCTL_LLC_STATUS_PER_CORE_OFFSET 0x4
> +
> +#define ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(n) \
> + (ANDES_LLC_REG_CCTL_CMD_OFFSET_C0 + ((n) * ANDES_LLC_REG_PER_CORE_OFFSET))
> +#define ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(n) \
> + (ANDES_LLC_REG_CCTL_ACC_OFFSET_C0 + ((n) * ANDES_LLC_REG_PER_CORE_OFFSET))
> +#define ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(n) \
> + (ANDES_LLC_CCTL_STATUS_MASK_C0 << ((n) * ANDES_CCTL_LLC_STATUS_PER_CORE_OFFSET))
> +
> +#define ANDES_CACHE_LINE_SIZE 64
> +
> +struct andes_priv {
> + void __iomem *llc_base;
> + u32 andes_cache_line_size;
> +};
> +
> +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);
> +}
> +
> +static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> + unsigned int l1_op, unsigned int llc_op)
> +{
> + 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;
> +
> + 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));
> + while ((andes_cpu_llc_get_cctl_status() &
> + ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
> + ANDES_LLC_CCTL_STATUS_IDLE)
> + ;
> +
> + start += line_size;
> + }
> +}
> +
> +/* Write-back L1 and LLC entry */
> +static inline void andes_cpu_dcache_wb_range(unsigned long start, unsigned long end)
> +{
> + andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_WB,
> + ANDES_LLC_CCTL_PA_WB);
> +}
> +
> +/* Invalidate the L1 and LLC entry */
> +static inline void andes_cpu_dcache_inval_range(unsigned long start, unsigned long end)
> +{
> + andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_INVAL,
> + ANDES_LLC_CCTL_PA_INVAL);
> +}
> +
> +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 flags;
> +
> + if (unlikely(start == end))
> + return;
> +
> + line_size = andes_priv.andes_cache_line_size;
> +
> + start = start & (~(line_size - 1));
> + end = ((end + line_size - 1) & (~(line_size - 1)));
> +
> + local_irq_save(flags);
> +
> + andes_cpu_dcache_inval_range(start, end);
> +
> + local_irq_restore(flags);
> +}
> +
> +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 flags;
> +
> + if (unlikely(start == end))
> + return;
> +
> + line_size = andes_priv.andes_cache_line_size;
> + start = start & (~(line_size - 1));
> + end = ((end + line_size - 1) & (~(line_size - 1)));
> + local_irq_save(flags);
> + andes_cpu_dcache_wb_range(start, end);
> + local_irq_restore(flags);
> +}
> +
> +static void andes_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
> +{
> + andes_dma_cache_wback(paddr, size);
> + andes_dma_cache_inv(paddr, size);
> +}
> +
> +static int andes_get_llc_line_size(struct device_node *np)
> +{
> + int ret;
> +
> + 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");
> + 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;
> + }
> +
> + return 0;
> +}
> +
> +static const struct riscv_nonstd_cache_ops andes_cmo_ops __initconst = {
> + .wback = &andes_dma_cache_wback,
> + .inv = &andes_dma_cache_inv,
> + .wback_inv = &andes_dma_cache_wback_inv,
> +};
> +
> +static const struct of_device_id andes_cache_ids[] = {
> + { .compatible = "andestech,llcache" },
> + { /* sentinel */ }
> +};
> +
> +static int __init andes_cache_init(void)
> +{
> + struct resource res;
> + int ret;
> +
> + struct device_node *np __free(device_node) =
> + of_find_matching_node(NULL, andes_cache_ids);
> + if (!of_device_is_available(np))
> + return -ENODEV;
> +
> + ret = of_address_to_resource(np, 0, &res);
> + if (ret)
> + return ret;
> +
> + /*
> + * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
> + * will be 0 for sure, so we can definitely rely on it. If
> + * riscv_cbom_block_size = 0 we don't need to handle CMO using SW any
> + * more so we just return success here and only if its being set we
> + * continue further in the probe path.
> + */
> + if (!riscv_cbom_block_size)
> + return 0;
> +
> + andes_priv.llc_base = ioremap(res.start, resource_size(&res));
> + if (!andes_priv.llc_base)
> + return -ENOMEM;
> +
> + ret = andes_get_llc_line_size(np);
> + if (ret) {
> + iounmap(andes_priv.llc_base);
> + return ret;
> + }
> +
> + riscv_noncoherent_register_cache_ops(&andes_cmo_ops);
> +
> + return 0;
> +}
> +early_initcall(andes_cache_init);
> diff --git a/drivers/cache/ax45mp_cache.c b/drivers/cache/ax45mp_cache.c
> deleted file mode 100644
> index 934c5087ec2b..000000000000
> --- a/drivers/cache/ax45mp_cache.c
> +++ /dev/null
> @@ -1,217 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * non-coherent cache functions for Andes AX45MP
> - *
> - * Copyright (C) 2023 Renesas Electronics Corp.
> - */
> -
> -#include <linux/cacheflush.h>
> -#include <linux/cacheinfo.h>
> -#include <linux/dma-direction.h>
> -#include <linux/of_address.h>
> -#include <linux/of_platform.h>
> -
> -#include <asm/dma-noncoherent.h>
> -
> -/* L2 cache registers */
> -#define AX45MP_L2C_REG_CTL_OFFSET 0x8
> -
> -#define AX45MP_L2C_REG_C0_CMD_OFFSET 0x40
> -#define AX45MP_L2C_REG_C0_ACC_OFFSET 0x48
> -#define AX45MP_L2C_REG_STATUS_OFFSET 0x80
> -
> -/* D-cache operation */
> -#define AX45MP_CCTL_L1D_VA_INVAL 0 /* Invalidate an L1 cache entry */
> -#define AX45MP_CCTL_L1D_VA_WB 1 /* Write-back an L1 cache entry */
> -
> -/* L2 CCTL status */
> -#define AX45MP_CCTL_L2_STATUS_IDLE 0
> -
> -/* L2 CCTL status cores mask */
> -#define AX45MP_CCTL_L2_STATUS_C0_MASK 0xf
> -
> -/* L2 cache operation */
> -#define AX45MP_CCTL_L2_PA_INVAL 0x8 /* Invalidate an L2 cache entry */
> -#define AX45MP_CCTL_L2_PA_WB 0x9 /* Write-back an L2 cache entry */
> -
> -#define AX45MP_L2C_REG_PER_CORE_OFFSET 0x10
> -#define AX45MP_CCTL_L2_STATUS_PER_CORE_OFFSET 4
> -
> -#define AX45MP_L2C_REG_CN_CMD_OFFSET(n) \
> - (AX45MP_L2C_REG_C0_CMD_OFFSET + ((n) * AX45MP_L2C_REG_PER_CORE_OFFSET))
> -#define AX45MP_L2C_REG_CN_ACC_OFFSET(n) \
> - (AX45MP_L2C_REG_C0_ACC_OFFSET + ((n) * AX45MP_L2C_REG_PER_CORE_OFFSET))
> -#define AX45MP_CCTL_L2_STATUS_CN_MASK(n) \
> - (AX45MP_CCTL_L2_STATUS_C0_MASK << ((n) * AX45MP_CCTL_L2_STATUS_PER_CORE_OFFSET))
> -
> -#define AX45MP_CCTL_REG_UCCTLBEGINADDR_NUM 0x80b
> -#define AX45MP_CCTL_REG_UCCTLCOMMAND_NUM 0x80c
> -
> -#define AX45MP_CACHE_LINE_SIZE 64
> -
> -struct ax45mp_priv {
> - void __iomem *l2c_base;
> - u32 ax45mp_cache_line_size;
> -};
> -
> -static struct ax45mp_priv ax45mp_priv;
> -
> -/* L2 Cache operations */
> -static inline uint32_t ax45mp_cpu_l2c_get_cctl_status(void)
> -{
> - return readl(ax45mp_priv.l2c_base + AX45MP_L2C_REG_STATUS_OFFSET);
> -}
> -
> -static void ax45mp_cpu_cache_operation(unsigned long start, unsigned long end,
> - unsigned int l1_op, unsigned int l2_op)
> -{
> - unsigned long line_size = ax45mp_priv.ax45mp_cache_line_size;
> - void __iomem *base = ax45mp_priv.l2c_base;
> - int mhartid = smp_processor_id();
> - unsigned long pa;
> -
> - while (end > start) {
> - csr_write(AX45MP_CCTL_REG_UCCTLBEGINADDR_NUM, start);
> - csr_write(AX45MP_CCTL_REG_UCCTLCOMMAND_NUM, l1_op);
> -
> - pa = virt_to_phys((void *)start);
> - writel(pa, base + AX45MP_L2C_REG_CN_ACC_OFFSET(mhartid));
> - writel(l2_op, base + AX45MP_L2C_REG_CN_CMD_OFFSET(mhartid));
> - while ((ax45mp_cpu_l2c_get_cctl_status() &
> - AX45MP_CCTL_L2_STATUS_CN_MASK(mhartid)) !=
> - AX45MP_CCTL_L2_STATUS_IDLE)
> - ;
> -
> - start += line_size;
> - }
> -}
> -
> -/* Write-back L1 and L2 cache entry */
> -static inline void ax45mp_cpu_dcache_wb_range(unsigned long start, unsigned long end)
> -{
> - ax45mp_cpu_cache_operation(start, end, AX45MP_CCTL_L1D_VA_WB,
> - AX45MP_CCTL_L2_PA_WB);
> -}
> -
> -/* Invalidate the L1 and L2 cache entry */
> -static inline void ax45mp_cpu_dcache_inval_range(unsigned long start, unsigned long end)
> -{
> - ax45mp_cpu_cache_operation(start, end, AX45MP_CCTL_L1D_VA_INVAL,
> - AX45MP_CCTL_L2_PA_INVAL);
> -}
> -
> -static void ax45mp_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 flags;
> -
> - if (unlikely(start == end))
> - return;
> -
> - line_size = ax45mp_priv.ax45mp_cache_line_size;
> -
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> -
> - local_irq_save(flags);
> -
> - ax45mp_cpu_dcache_inval_range(start, end);
> -
> - local_irq_restore(flags);
> -}
> -
> -static void ax45mp_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 flags;
> -
> - if (unlikely(start == end))
> - return;
> -
> - line_size = ax45mp_priv.ax45mp_cache_line_size;
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> - local_irq_save(flags);
> - ax45mp_cpu_dcache_wb_range(start, end);
> - local_irq_restore(flags);
> -}
> -
> -static void ax45mp_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
> -{
> - ax45mp_dma_cache_wback(paddr, size);
> - ax45mp_dma_cache_inv(paddr, size);
> -}
> -
> -static int ax45mp_get_l2_line_size(struct device_node *np)
> -{
> - int ret;
> -
> - ret = of_property_read_u32(np, "cache-line-size", &ax45mp_priv.ax45mp_cache_line_size);
> - if (ret) {
> - pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
> - return ret;
> - }
> -
> - if (ax45mp_priv.ax45mp_cache_line_size != AX45MP_CACHE_LINE_SIZE) {
> - pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
> - ax45mp_priv.ax45mp_cache_line_size);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> -static const struct riscv_nonstd_cache_ops ax45mp_cmo_ops __initdata = {
> - .wback = &ax45mp_dma_cache_wback,
> - .inv = &ax45mp_dma_cache_inv,
> - .wback_inv = &ax45mp_dma_cache_wback_inv,
> -};
> -
> -static const struct of_device_id ax45mp_cache_ids[] = {
> - { .compatible = "andestech,ax45mp-cache" },
> - { /* sentinel */ }
> -};
> -
> -static int __init ax45mp_cache_init(void)
> -{
> - struct resource res;
> - int ret;
> -
> - struct device_node *np __free(device_node) =
> - of_find_matching_node(NULL, ax45mp_cache_ids);
> - if (!of_device_is_available(np))
> - return -ENODEV;
> -
> - ret = of_address_to_resource(np, 0, &res);
> - if (ret)
> - return ret;
> -
> - /*
> - * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
> - * will be 0 for sure, so we can definitely rely on it. If
> - * riscv_cbom_block_size = 0 we don't need to handle CMO using SW any
> - * more so we just return success here and only if its being set we
> - * continue further in the probe path.
> - */
> - if (!riscv_cbom_block_size)
> - return 0;
> -
> - ax45mp_priv.l2c_base = ioremap(res.start, resource_size(&res));
> - if (!ax45mp_priv.l2c_base)
> - return -ENOMEM;
> -
> - ret = ax45mp_get_l2_line_size(np);
> - if (ret) {
> - iounmap(ax45mp_priv.l2c_base);
> - return ret;
> - }
> -
> - riscv_noncoherent_register_cache_ops(&ax45mp_cmo_ops);
> -
> - return 0;
> -}
> -early_initcall(ax45mp_cache_init);
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> index 1e50dc7c31cd..e0319c8236ee 100644
> --- a/drivers/soc/renesas/Kconfig
> +++ b/drivers/soc/renesas/Kconfig
> @@ -447,7 +447,7 @@ config ARCH_R9A07G043
> depends on !RISCV_ISA_ZICBOM
> depends on RISCV_SBI
> select ARCH_RZG2L
> - select AX45MP_L2_CACHE
> + select ANDES_CACHE
> select CACHEMAINT_FOR_DMA
> select DMA_GLOBAL_POOL
> select ERRATA_ANDES
> diff --git a/include/linux/soc/andes/csr.h b/include/linux/soc/andes/csr.h
> new file mode 100644
> index 000000000000..3214b4b08a46
> --- /dev/null
> +++ b/include/linux/soc/andes/csr.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2026 Andes Technology Corporation.
> + */
> +#ifndef __LINUX_SOC_ANDES_CSR_H
> +#define __LINUX_SOC_ANDES_CSR_H
> +
> +/* User mode control registers */
> +#define CSR_UCCTLBEGINADDR 0x80b
> +#define CSR_UCCTLCOMMAND 0x80c
> +
> +#endif /* !__LINUX_SOC_ANDES_CSR_H */
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/5] dmaengine: xilinx_dma: Move descriptors to done list based on completion bit
From: Frank Li @ 2026-03-30 15:54 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-3-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:30AM +0530, Srinivas Neeli wrote:
> In AXIMCDMA scatter-gather mode, the hardware sets the completion bit when
> a transfer finishes. The driver now checks this bit to free descriptors
> from the active list and move them to the done list.
Add check complete bit because irq may be triggered before a configured
threshold is reached when interrupt delay timeout Dly_IrqEn is enabled.
Frank
> This is required when interrupt delay timeout Dly_IrqEn is enabled,
> as interrupts may be triggered before the configured threshold is reached,
> even if not all descriptors have completed.
>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 4a83492f2435..00200b4c2372 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1762,6 +1762,18 @@ static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
> struct xilinx_axidma_tx_segment, node);
> if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
> break;
> + } else if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> + struct xilinx_aximcdma_tx_segment *seg;
> + bool completed;
> +
> + seg = list_last_entry(&desc->segments,
> + struct xilinx_aximcdma_tx_segment,
> + node);
> + completed = (chan->direction == DMA_DEV_TO_MEM) ?
> + (seg->hw.s2mm_status & XILINX_DMA_BD_COMP_MASK) :
> + (seg->hw.mm2s_status & XILINX_DMA_BD_COMP_MASK);
> + if (!completed)
> + break;
> }
> if (chan->has_sg && chan->xdev->dma_config->dmatype !=
> XDMA_TYPE_VDMA)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH V2 3/5] dmaengine: xilinx_dma: Extend metadata handling for AXI MCDMA
From: Frank Li @ 2026-03-30 15:58 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-4-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:31AM +0530, Srinivas Neeli wrote:
> From: Suraj Gupta <suraj.gupta2@amd.com>
>
> Extend probe logic to detect AXI Stream connections for MCDMA. When
> an AXI Stream interface is present, metadata operations are enabled for
> the MCDMA channel. The xilinx_dma_get_metadata_ptr() is enhanced to
> retrieve metadata directly from MCDMA descriptors.
Need extra empty line between paragraph
> Add corresponding channel reference in struct xilinx_dma_tx_descriptor to
> retrieve associated channel.
> These changes ensure proper metadata handling and accurate transfer
> size reporting for MCDMA transfers.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 00200b4c2372..52203d44e7a4 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -222,6 +222,8 @@
> #define XILINX_MCDMA_BD_EOP BIT(30)
> #define XILINX_MCDMA_BD_SOP BIT(31)
>
> +struct xilinx_dma_chan;
> +
> /**
> * struct xilinx_vdma_desc_hw - Hardware Descriptor
> * @next_desc: Next Descriptor Pointer @0x00
> @@ -371,6 +373,7 @@ struct xilinx_cdma_tx_segment {
>
> /**
> * struct xilinx_dma_tx_descriptor - Per Transaction structure
> + * @chan: DMA channel for which this descriptor is allocated
> * @async_tx: Async transaction descriptor
> * @segments: TX segments list
> * @node: Node in the channel descriptors list
> @@ -379,6 +382,7 @@ struct xilinx_cdma_tx_segment {
> * @residue: Residue of the completed descriptor
> */
> struct xilinx_dma_tx_descriptor {
> + struct xilinx_dma_chan *chan;
async_tx already include dma_chan's information.
Frank
^ permalink raw reply
* Re: [PATCH v10 2/2] hwmon: add support for MCP998X
From: Guenter Roeck @ 2026-03-30 16:00 UTC (permalink / raw)
To: Victor.Duicu
Cc: corbet, linux-hwmon, devicetree, robh, linux-kernel, krzk+dt,
linux-doc, conor+dt, Marius.Cristea
In-Reply-To: <2d3955f5b906018fd7670ed5b8d37eaffa0ec207.camel@microchip.com>
On 3/30/26 05:01, Victor.Duicu@microchip.com wrote:
> Hi Guenter,
>
> ...
>
>>> + }
>>> +
>>> + switch (type) {
>>> + case hwmon_temp:
>>> + switch (attr) {
>>> + case hwmon_temp_input:
>>> + /* Block reading from addresses 0x00->0x09 is
>>> not allowed. */
>>> + ret = regmap_read(priv->regmap,
>>> MCP9982_HIGH_BYTE_ADDR(channel), ®_high);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = regmap_read(priv->regmap,
>>> MCP9982_HIGH_BYTE_ADDR(channel) + 1,
>>> + ®_low);
>>> + if (ret)
>>> + return ret;
>>
>> Reading the 11-bit temperature value involves two separate 8-bit
>> register reads.
>> If the chip updates the temperature between these two reads, the
>> resulting value
>> may be torn. While some chips latch the low byte upon reading the
>> high byte,
>> the driver does not explicitly rely on or document this behavior, and
>> it's safer
>> to use regmap_bulk_read if supported, or at least ensure the correct
>> order and
>> atomicity if possible.
>>
>> Note: Maybe the low temperature is latched, but there is no
>> indication in the
>> datasheet that this would be the case. Even if it is, the code above
>> is
>> inefficient.
>
> The low temperature register is latched. In the documentation at
> page 32 it is described that when reading the high byte register,
> the value from the low byte register is copied into a 'shadow'
> register. In this way it is guaranteed that when we read the low byte,
> it will correspond to the high byte.
>
> Regarding the bulk read, the chip has a number of design quirks and
> because of that different commands are supported only on some
> particular memory regions.
>
> According to the documentation page 26, the only areas of memory that
> support SMBus block read are 80h->89h(temperature memory block) and
> 90h->97h(status memory block). In order to block read the temperatures,
> the area of memory targeted has to be the temperature memory block. In
> this context the read operation uses SMBus protocol and the first value
> returned will be the number of addresses that can be read (in our
> particular case a max value of 10 bytes).
>
> In v8 of the driver
> https://lore.kernel.org/all/20251120071248.3767-1-victor.duicu@microchip.com/
> ,
> the temperature values were read with regmap_bulk_read(). In that
> version, regmap_bulk_read() was also used to read the temperature
> limits, without returning count (this is an undocumented feature of the
> chip and because of that we could assume is not supported).
> In order to avoid this behaviour and avoid mixing the SMBus and I2C
> protocols all block readings were removed.
>
> In the hopes of bypassing a long chain of replies, I tested the
> behaviour of the chip with different read instructions.
> Regmap_bulk_read() when applied to the temperature memory block
> (80h->89h) returns count and the high and low bytes. When it is applied
> to the 00h->09h memory, it uses I2C. It returns one temperature byte,
> but all other bytes are returned as 0xFF. The chip behaves as if
> it is at the last register location in the temperature block while the
> host continues to ACK.(behaviour described at page 26).
> If we set use_single_read in regmap_config and apply regmap_bulk_read()
> to the 00h->09h register area the high and low temperature bytes are
> read successfully without count.
>
> Regmap_multi_reg_read() reads a number of registers one by one. When
> applied to the 00h->09h area, I2C is used and it returns only the high
> and low temperature bytes. When applied to the temperature memory block
> (80h->89h), because it is not a bulk function, returns the count till
> the end of the temperature memory block (aka SMBus count).
>
> I2c_smbus_read_block_data() when applied to the temperature block (80h-
> 89h) returns the count, the driver replies with an NACK and the
> communication is stopped. In our case, the board we are using to test
> the driver has an AT91 adapter and supports
> I2C_FUNC_SMBUS_READ_BLOCK_DATA. It seems that the I2C driver for AT91
> does not modify the buff length of the message, leaving it 1.
>
> I2c_smbus_read_i2c_block_data() when applied to the temperature block
> (80h-89h) returns count and the temperature values.
>
> If you are of the opinion that block reading the temperatures is worth
> introducing (even in case we need to skip count) then I can add it, but
> we should come to an agreement on which function to use.
> Please let me know your thoughts.
>
It is your chip, so I'll let you decide. Please include all the above
as comments into the code.
Thanks,
Guenter
^ permalink raw reply
* Re: (subset) [PATCH 0/2] arm64: dts: qcom: milos: Add missing CX power domain to GCC
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luca Weiss, Taniya Das, Konrad Dybcio,
Dmitry Baryshkov, Abel Vesa
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260327-dt-fix-milos-eliza-gcc-power-domains-v1-0-f14a22c73fe9@oss.qualcomm.com>
On Fri, 27 Mar 2026 14:13:39 +0200, Abel Vesa wrote:
> Recently, on Eliza, the CX has been tied up to the GCC.
> This leads to dt-bindings check failing.
>
> So the schema needs to be fixed. But the schema is same
> for Milos. So instead of adding an if-clause for Eliza only,
> tie the CX power domain to the GCC on Milos as well, for the
> same exact reasons as on Eliza.
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: milos: Add missing CX power domain to GCC
commit: e46b48b853122626806d989d5db4ce97eaaac2ca
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov, Thara Gopinath, Alexander Koskovich
Cc: linux-arm-msm, devicetree, linux-kernel, Alexander Koskovich
In-Reply-To: <20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me>
On Sun, 08 Mar 2026 04:26:37 +0000, Alexander Koskovich wrote:
> This resolves the following error seen on the ASUS ROG Phone 3:
>
> cpu cpu7: Voltage update failed freq=3091200
> cpu cpu7: failed to update OPP for freq=3091200
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP
commit: b683730e27ba4f91986c4c92f5cb7297f1e01a6d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/4] clk: qcom: ipq-cmn-pll: Add IPQ6018/IPQ8074 SoC support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luo Jie, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Christian Marangi
In-Reply-To: <20260311183942.10134-1-ansuelsmth@gmail.com>
On Wed, 11 Mar 2026 19:39:37 +0100, Christian Marangi wrote:
> Simple series that adds support for the common PLL for
> IPQ6018/IPQ8074 SoC support.
>
> This is an initial effort to try to support the Ethernet Switch
> present on the QualcommAX platform upstream.
>
> John Crispin (4):
> dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
> clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
> dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
> clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
>
> [...]
Applied, thanks!
[1/4] dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
commit: a57666004f49fa5031d6bf388834213e6f961922
[2/4] clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
commit: 97eb2ac52726fbb702ced40d552a3f6f2683b664
[3/4] dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
commit: 7156c65030006e6930dd99c5b8c5e84e69ca5f0b
[4/4] clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
commit: 4e36f8ab45c406420f2c2ce6ee3988e0d13ba1c9
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260323-rb3gen2-upd-gl3590-v2-1-073514bf9ed5@oss.qualcomm.com>
On Mon, 23 Mar 2026 21:32:39 -0500, Bjorn Andersson wrote:
> The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
> the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
> two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
> interface.
>
> The Renesas chip is powered by two regulators controlled through PM7250B
> GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
> The Genesys chip power is always-on, but the reset pin is controlled
> through TLMM GPIO 162.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590
commit: cde64269eeb8099b4405aef8b19b90892a05352e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: qcom: enable UARTs for robot expansion board
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, Canfeng Zhuang
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-1-canfeng.zhuang@oss.qualcomm.com>
On Fri, 27 Mar 2026 16:30:59 +0800, Canfeng Zhuang wrote:
> The Qualcomm Lemans EVK and Monaco EVK boards expose a mezzanine
> connector used by a motor control expansion board.
>
> This expansion board hosts an MCU running NuttX and communicates with
> Linux over UART, with all protocol handling done in userspace.
>
> This series enables the required UARTs and assigns stable serial aliases
> to ensure consistent device enumeration across platforms.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
commit: 0be638f326c2015ae9406f4238d9bc54b5b7a584
[2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
commit: 74620bf0c3c6091ecd7972075f5ddeba29994407
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8996: fix indentation in sdhc2 node
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329-wip-obbardc-msm8996-whitespace-v1-1-ba3a278f043c@linaro.org>
On Sun, 29 Mar 2026 14:12:26 +0100, Christopher Obbard wrote:
> Drop stray leading whitespace from sdhc2 node.
>
> No functional change.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8996: fix indentation in sdhc2 node
commit: 25e7cc37cff444030250abea1ba875c26ff59e9a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 0/2] sdm845: describe the Wi-Fi hardware properly
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327-wcn3990-pwrctl-sdm845-v1-0-3f5c34e3fdd0@ixit.cz>
On Fri, 27 Mar 2026 14:07:07 +0100, David Heidelberg wrote:
> Question here is, if the most of the wcn3990-pmu shouldn't rather go to
> sdm845.dtsi? At least the regulators seems to be same.
>
> When agreed, I'll sent include all other sdm845 phones in the patchset.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: sdm845-google: Describe Wi-Fi/BT properly
commit: 0a9c8715663998dc4d8eaa8f1a40440214906d96
[2/2] arm64: dts: qcom: sdm845-oneplus: Describe Wi-Fi/BT properly
commit: 7a4790b1a2c9ff66bd7a95d8761d5e9fc9334ba9
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jingyi Wang
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260330-knp-space-cleanup-v1-1-0995302f7557@oss.qualcomm.com>
On Mon, 30 Mar 2026 02:39:42 -0700, Jingyi Wang wrote:
> Exactly one space is expected before '{' characters, clean
> up duplicate whitespaces.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
commit: 45ac3ced1b79fe25e135a0c5e5ad063166b8fd51
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: firmware: qcom,scm: Document ipq9650 SCM
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robert Marko, Guru Das Srinagesh, Kathiravan Thirumoorthy
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260325-ipq9650_scm-v1-1-ad6a3fe53f38@oss.qualcomm.com>
On Wed, 25 Mar 2026 17:09:43 +0530, Kathiravan Thirumoorthy wrote:
> Document the scm compatible for ipq9650 SoC.
>
>
Applied, thanks!
[1/1] dt-bindings: firmware: qcom,scm: Document ipq9650 SCM
commit: dc67808832d3a1d337c314a2c950f9bf774a21b2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260327101225.382493-2-krzysztof.kozlowski@oss.qualcomm.com>
On Fri, 27 Mar 2026 11:12:26 +0100, Krzysztof Kozlowski wrote:
> Add TSENS thermal sensors to Qualcomm Eliza SoC among with thermal
> zones. The TSENS is compatible with previous generations.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: eliza: Add thermal sensors
commit: 7f390d6ccbaa3313758b172fd8cbadc6c652c48a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Loic Poulain, Sumit Garg,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260325122209.147128-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, 25 Mar 2026 13:22:10 +0100, Krzysztof Kozlowski wrote:
> Device node has children with MMIO addressing, so must have ranges:
>
> msm/qcom,qcm2290-mdss.example.dtb: display-subsystem@5e00000 (qcom,qcm2290-mdss): 'ranges' is a required property
>
>
Applied, thanks!
[1/1] dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
commit: 88bdac5443e5269bb39c4968d5ee0becbffe3f82
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: hamoa-evk: Add DP0/DP1 audio playback support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Le Qi
Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20260210024037.3719191-1-le.qi@oss.qualcomm.com>
On Tue, 10 Feb 2026 10:40:37 +0800, Le Qi wrote:
> The hamoa-evk DTS currently lacks DAI links for DP0 and DP1, preventing
> the sound card from exposing these playback paths. Add the missing links
> to enable audio output on both DP interfaces.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: hamoa-evk: Add DP0/DP1 audio playback support
commit: 20eb0aa76f7ceebbf897019e3eeeca0a1d24e3f5
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] Add CCI support for Milos, enable on Fairphone (Gen. 6)
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-i2c, linux-arm-msm,
devicetree, linux-kernel, Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <20260320-milos-cci-v2-0-1947fc83f756@fairphone.com>
On Fri, 20 Mar 2026 09:09:48 +0100, Luca Weiss wrote:
> Add the compatible strings for the CCI busses on Milos, and the EEPROMs
> found on the Fairphone (Gen. 6) camera modules, and add them to the
> milos dtsi and device dts.
>
> This series soft-depends on https://lore.kernel.org/linux-arm-msm/20260116-milos-camcc-icc-v1-0-400b7fcd156a@fairphone.com/T/
>
> The patches can be applied without the dependency, but the final dts
> patches should probably only land once the other series has been fully
> applied, otherwise the CCI busses cannot actually be used (unless some
> other component turns on the mmss_noc) and you get a kernel warning like
> the following:
>
> [...]
Applied, thanks!
[2/3] arm64: dts: qcom: milos: Add CCI busses
commit: e9e75b3e622bccefe3ccc7e167e36f58369a388d
[3/3] arm64: dts: qcom: milos-fairphone-fp6: Add camera EEPROMs on CCI busses
commit: 924d734960062b0665d551c82489ad2cb4d96e80
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/2] Front camera enablement on Fairphone 5
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vladimir Zapolskiy, Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <20260319-fp5-s5kjn1-v3-0-9cf4b8c09567@fairphone.com>
On Thu, 19 Mar 2026 16:36:27 +0100, Luca Weiss wrote:
> Since the Samsung S5KJN1 driver was upstreamed recently, we can enable
> the camera upstream by adding a few bits to dts.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Sort pinctrl nodes by pins
commit: e7fc3c46dc09c1c5f901f1a627d9bffc6321081c
[2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add front camera support
commit: 1d44de258d34f33aadda67d69dae5a8427b9d2c7
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 0/3] SDM670 cache controller support
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Conor Dooley, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, linux-arm-msm, devicetree, Richard Acayan
In-Reply-To: <20260210021957.13357-1-mailingradian@gmail.com>
On Mon, 09 Feb 2026 21:19:54 -0500, Richard Acayan wrote:
> This adds support for the Low-Level Cache Controller (LLCC) on SDM670.
>
> Richard Acayan (3):
> dt-bindings: cache: qcom,llcc: Add SDM670 compatible
> soc: qcom: llcc: Add configuration data for SDM670
> arm64: dts: qcom: sdm670: add llcc
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: sdm670: add llcc
commit: 3aa997129993135ff1e11128e216af814e72f0a0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] Add DSI display support for SC8280XP
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Krishna Manikandan, Jonathan Marek, Pengyu Luo
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Tianyu Gao, White Lewis
In-Reply-To: <20260308064835.479356-1-mitltlatltl@gmail.com>
On Sun, 08 Mar 2026 14:48:31 +0800, Pengyu Luo wrote:
> Add DSI display support for SC8280XP.
>
Applied, thanks!
[4/4] arm64: dts: qcom: sc8280xp: Add dsi nodes on SC8280XP
commit: 2f4c5dea9a285cc24a80e9fef8d7014bffce967b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: purwa-iot-evk: Enable UFS
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Dmitry Baryshkov, Pradeep P V K
Cc: linux-arm-msm, devicetree, linux-kernel, nitin.rawat
In-Reply-To: <20260323-purwa-ufs-v2-1-58fb2c168786@oss.qualcomm.com>
On Mon, 23 Mar 2026 18:17:53 +0530, Pradeep P V K wrote:
> Enable UFS for purwa-iot-evk board.
>
> This patch depends on [PATCH V5 2/3] arm64: dts: qcom: hamoa: Add UFS
> nodes for x1e80100 SoC
> https://lore.kernel.org/all/20260211132926.3716716-3-pradeep.pragallapati@oss.qualcomm.com/
>
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: purwa-iot-evk: Enable UFS
commit: 7658e9b94849ca861ded82d641f52fcec303210d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add Qualcomm SA8650P SoC to socinfo
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, devicetree, Radu Rendec
Cc: Lei wang, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260321152307.9131-1-rrendec@redhat.com>
On Sat, 21 Mar 2026 11:23:05 -0400, Radu Rendec wrote:
> Add SoC ID for SA8650P to socinfo.
>
> Minor edits to commit messages for better clarity and to match previous
> submissions that add a SoC to socinfo.
>
Applied, thanks!
[1/2] dt-bindings: arm: qcom,ids: Add SoC ID for SA8650P
commit: a559a742c95c55ae3b347f2b57d26830c0cdd566
[2/2] soc: qcom: socinfo: Add SoC ID for SA8650P
commit: f55fa3e3dcd8f766266fdf878994f0ec09459a7d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* 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
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