* [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
From: Rosen Penev @ 2026-06-28 23:11 UTC (permalink / raw)
To: devicetree
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Broadcom internal kernel review list, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list
These addresses overlap with DRAM on BCM5301X/BCM470X SoCs, causing the OF
address translation code to route PCIe MMIO accesses through the AXI bus
space instead of directly to memory, breaking PCIe. Remove the extra
ranges to restore the original single-entry mapping that only covers the
AXI peripheral register space.
Assisted-by: opencode:big-pickle
Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/broadcom/bcm-ns.dtsi | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
index bd52de0faa3e..27a97c8122de 100644
--- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
@@ -95,10 +95,7 @@ L2: cache-controller@22000 {
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
- ranges = <0x00000000 0x18000000 0x00100000>,
- <0x08000000 0x08000000 0x08000000>,
- <0x20000000 0x20000000 0x08000000>,
- <0x28000000 0x28000000 0x08000000>;
+ ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size
From: Rosen Penev @ 2026-06-28 23:10 UTC (permalink / raw)
To: devicetree
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Broadcom internal kernel review list, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list
Fixes:
[ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
[ 0.182159] Unexpected (big) NVRAM size: 1056112 B
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
index af411679a14a..37593e7582ba 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
@@ -26,7 +26,7 @@ memory@0 {
nvram@1c080000 {
compatible = "brcm,nvram";
- reg = <0x1c080000 0x180000>;
+ reg = <0x1c080000 0x100000>;
et2macaddr: et2macaddr {
#nvmem-cell-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rc v6 1/7] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
From: Pranjal Shrivastava @ 2026-06-28 23:00 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <f3d1f938a9b4d540f67d9c1ff394bd62735a4f5c.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:18AM -0700, Nicolin Chen wrote:
Hi Nicolin,
> When transitioning to a kdump kernel, the primary kernel might have crashed
> while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> and setting the Global Bypass Attribute (GBPA) to ABORT.
>
> In a kdump scenario, this aggressive reset is highly destructive:
> a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> PCIe AER or SErrors that may panic the kdump kernel
> b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
>
> To safely absorb in-flight DMAs, a kdump kernel will have to leave SMMUEN=1
> intact and avoid modifying STRTAB_BASE, allowing HW to continue translating
> in-flight DMAs reusing the crashed kernel's page tables until the endpoint
> device drivers probe and quiesce their respective hardware.
>
> However, the ARM SMMUv3 architecture specification states that updating the
> SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
>
> This leaves a kdump kernel no choice but to adopt the stream table from the
> crashed kernel.
>
> Introduce ARM_SMMU_OPT_KDUMP_ADOPT and adopt functions memremapping all the
> stream tables extracted from STRTAB_BASE and STRTAB_BASE_CFG.
>
> Note that the adoption of the crashed kernel's stream table follows certain
> strict rules, since the old stream table might be compromised. Thus, apply
> some basic validations against the values read from the registers. If tests
> fail, it means the stream table cannot be trusted, so toss it entirely. To
> avoid OOM due to a potentially corrupted stream table, the memremap for l2
> tables is done on the kdump kernel's demand.
>
> The new option will be set in a following change.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 254 +++++++++++++++++++-
> 2 files changed, 252 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index ef42df4753ec4..cd60b692c3901 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -861,6 +861,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_OPT_MSIPOLL (1 << 2)
> #define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
> #define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
> +#define ARM_SMMU_OPT_KDUMP_ADOPT (1 << 5)
> u32 options;
>
> struct arm_smmu_cmdq cmdq;
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f03..aa6837a5daa88 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2040,16 +2040,70 @@ static void arm_smmu_init_initial_stes(struct arm_smmu_ste *strtab,
> }
> }
>
> +static int arm_smmu_kdump_adopt_l2_strtab(struct arm_smmu_device *smmu, u32 sid,
> + phys_addr_t base, u32 span,
> + struct arm_smmu_strtab_l2 **l2table)
> +{
> + struct arm_smmu_strtab_l2 *table;
> + size_t size;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
We already checked this in arm_smmu_kdump_adopt_strtab_2lvl() can it
change since?
> +
> + /*
> + * Retest the span in case the L1 descriptor has been overwritten since
> + * the adopt. Reject this master's insert; panic or SMMU-disable would
> + * either lose the vmcore or cascade aborts. Do not try to fix it, as it
> + * would break all other SIDs in the same bus (PCI case). The corruption
> + * blast radius is already bounded to that bus range.
> + */
> + if (span != STRTAB_SPLIT + 1) {
> + dev_err(smmu->dev,
> + "kdump: L1[%u] span %u changed since adopt (was %u)\n",
> + arm_smmu_strtab_l1_idx(sid), span, STRTAB_SPLIT + 1);
> + return -EINVAL;
> + }
> +
> + size = (1UL << (span - 1)) * sizeof(struct arm_smmu_ste);
> +
> + table = devm_memremap(smmu->dev, base, size, MEMREMAP_WB);
Why do we use devm_memremap() here but memremap() in the rest of the
functions (even for the L1 ptr)?
> + if (IS_ERR(table)) {
> + dev_err(smmu->dev,
> + "kdump: failed to adopt l2 stream table for SID %u\n",
> + sid);
> + return PTR_ERR(table);
> + }
> +
> + *l2table = table;
> + return 0;
> +}
> +
> static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
> {
> dma_addr_t l2ptr_dma;
> struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> struct arm_smmu_strtab_l2 **l2table;
> + u32 l1_idx = arm_smmu_strtab_l1_idx(sid);
>
> - l2table = &cfg->l2.l2ptrs[arm_smmu_strtab_l1_idx(sid)];
> + l2table = &cfg->l2.l2ptrs[l1_idx];
> if (*l2table)
> return 0;
>
> + /* Deferred adoption of the crashed kernel's L2 table */
> + if (smmu->options & ARM_SMMU_OPT_KDUMP_ADOPT) {
> + u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[l1_idx].l2ptr);
> + phys_addr_t base = l2ptr & STRTAB_L1_DESC_L2PTR_MASK;
> + u32 span = FIELD_GET(STRTAB_L1_DESC_SPAN, l2ptr);
> +
> + if (span && base)
> + return arm_smmu_kdump_adopt_l2_strtab(smmu, sid, base,
> + span, l2table);
> + }
> +
> *l2table = dmam_alloc_coherent(smmu->dev, sizeof(**l2table),
> &l2ptr_dma, GFP_KERNEL);
> if (!*l2table) {
> @@ -2061,8 +2115,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
>
> arm_smmu_init_initial_stes((*l2table)->stes,
> ARRAY_SIZE((*l2table)->stes));
> - arm_smmu_write_strtab_l1_desc(&cfg->l2.l1tab[arm_smmu_strtab_l1_idx(sid)],
> - l2ptr_dma);
> + arm_smmu_write_strtab_l1_desc(&cfg->l2.l1tab[l1_idx], l2ptr_dma);
> return 0;
> }
>
> @@ -4556,10 +4609,204 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> return 0;
> }
>
> +static int arm_smmu_kdump_adopt_strtab_2lvl(struct arm_smmu_device *smmu,
> + u32 cfg_reg, phys_addr_t base)
> +{
> + u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
> + u32 split = FIELD_GET(STRTAB_BASE_CFG_SPLIT, cfg_reg);
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + u32 num_l1_ents;
> + size_t size;
> + int i;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
> +
> + if (log2size < split || log2size > smmu->sid_bits) {
> + dev_err(smmu->dev, "kdump: log2size %u out of range [%u, %u]\n",
> + log2size, split, smmu->sid_bits);
> + return -EINVAL;
> + }
> + if (split != STRTAB_SPLIT) {
> + dev_err(smmu->dev,
> + "kdump: unsupported STRTAB_SPLIT %u (expected %u)\n",
> + split, STRTAB_SPLIT);
> + return -EINVAL;
> + }
> +
> + num_l1_ents = 1U << (log2size - split);
> + if (num_l1_ents > STRTAB_MAX_L1_ENTRIES) {
> + dev_err(smmu->dev, "kdump: l1 entries %u exceeds max %u\n",
> + num_l1_ents, STRTAB_MAX_L1_ENTRIES);
> + return -EINVAL;
> + }
> +
> + cfg->l2.num_l1_ents = num_l1_ents;
> +
> + size = num_l1_ents * sizeof(struct arm_smmu_strtab_l1);
> + cfg->l2.l1tab = memremap(base, size, MEMREMAP_WB);
> + if (!cfg->l2.l1tab)
> + return -ENOMEM;
Same here (as below, sorry reviewing it as the code flows), we should
populate cfg->l2.l1_dma here to be consistent.
> +
> + cfg->l2.l2ptrs =
> + kcalloc(num_l1_ents, sizeof(*cfg->l2.l2ptrs), GFP_KERNEL);
> + if (!cfg->l2.l2ptrs)
> + return -ENOMEM;
We shuold ummap cfg->l2.l1tab before returning -ENOMEM here
> +
> + for (i = 0; i < num_l1_ents; i++) {
> + u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[i].l2ptr);
> + phys_addr_t l2_base = l2ptr & STRTAB_L1_DESC_L2PTR_MASK;
> + u32 span = FIELD_GET(STRTAB_L1_DESC_SPAN, l2ptr);
> +
> + if (!span || !l2_base)
> + continue;
> +
> + if (span != STRTAB_SPLIT + 1) {
> + dev_err(smmu->dev,
> + "kdump: L1[%u] unsupported span %u (vs %u)\n",
> + i, span, STRTAB_SPLIT + 1);
> + return -EINVAL;
We leak kcalloc'd mem (l2.l2ptrs) here, also we should unmap cfg->l2.l1tab
> + }
> +
> + /*
> + * If the crashed kernel's l1 descriptors are deeply corrupted,
> + * blindly memremapping every l2 table here could lead to OOM.
> + *
> + * Defer the l2 memremap to arm_smmu_init_l2_strtab(), so peak
> + * memory is bounded by the kdump kernel's actual demand.
> + */
> + }
> +
> + return 0;
> +}
> +
> +static int arm_smmu_kdump_adopt_strtab_linear(struct arm_smmu_device *smmu,
> + u32 cfg_reg, phys_addr_t base)
> +{
> + u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + unsigned int max_log2size;
> + size_t size;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
> +
> + /* Cap the size at what the kdump kernel itself would have allocated */
> + if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
> + max_log2size =
> + ilog2(STRTAB_MAX_L1_ENTRIES * STRTAB_NUM_L2_STES);
Looks like we'd never hit this if condition because we'd never support a
"linear" strtab if the HW supports ARM_SMMU_FEAT_2_LVL_STRTAB. Please
see arm_smmu_init_strtab:
static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
{
int ret;
if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
ret = arm_smmu_init_strtab_2lvl(smmu);
else
ret = arm_smmu_init_strtab_linear(smmu);
if (ret)
return ret;
ida_init(&smmu->vmid_map);
return 0;
}
> + else
> + max_log2size = smmu->sid_bits;
> +
> + /* cfg->linear.num_ents is unsigned int, so cap log2size at 31 */
> + max_log2size = min(max_log2size, 31U);
> + if (log2size > max_log2size) {
> + dev_err(smmu->dev, "kdump: unsupported log2size %u (> %u)\n",
> + log2size, max_log2size);
> + return -EINVAL;
> + }
> +
> + /*
> + * We might end up with a num_ents != sid_bits, which is fine. In the
> + * ARM_SMMU_OPT_KDUMP_ADOPT case, arm_smmu_write_strtab() is bypassed.
> + */
> + cfg->linear.num_ents = 1U << log2size;
> +
> + size = cfg->linear.num_ents * sizeof(struct arm_smmu_ste);
> + cfg->linear.table = memremap(base, size, MEMREMAP_WB);
> + if (!cfg->linear.table)
> + return -ENOMEM;
We seem to skips initializing cfg->linear.ste_dma (it is populated in
arm_smmu_init_strtab_linear)
While the comment notes that arm_smmu_write_strtab() is bypassed in the
kdump case, leaving cfg->linear.ste_dma uninitialized seems like a
ticking time bomb if any other part of the driver ever uses it.
> + return 0;
> +}
> +
> +static void arm_smmu_kdump_adopt_cleanup(void *data)
> +{
> + struct arm_smmu_device *smmu = data;
> + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
I'm worried about reading the HW register here, since this is a devres action, it
can run after arm_smmu_device_remove() or arm_smmu_device_shutdown()
(which would call rpm_put()). Please see __device_release_driver[1]:
pm_runtime_put_sync(dev); <--- HW turned off
device_remove(dev);
if (dev->bus && dev->bus->dma_cleanup)
dev->bus->dma_cleanup(dev);
device_unbind_cleanup(dev); <--- This is where devm_release runs
device_links_driver_cleanup(dev);
Thus, even if we call rpm_get() here it would make no sense as the
register contents would've been lost. Can we rely on some SW state
here? smmu->features & 2LVL or maybe add an fmt in cfg?
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> +
> + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> + kfree(cfg->l2.l2ptrs);
> + if (cfg->l2.l1tab)
> + memunmap(cfg->l2.l1tab);
> + } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> + if (cfg->linear.table)
> + memunmap(cfg->linear.table);
> + }
> +}
> +
> +static int arm_smmu_kdump_adopt_strtab(struct arm_smmu_device *smmu)
> +{
> + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
> + u64 base_reg = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> + phys_addr_t base = base_reg & STRTAB_BASE_ADDR_MASK;
> + int ret;
> +
> + dev_info(smmu->dev, "kdump: adopting crashed kernel's stream table\n");
Nit: Should this be dev_info? If everything goes right, the user doesn't
need to know. dev_dbg seems more appropriate. It should only be a warn or
err if adoption fails (which is in place).
> +
> + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> + /*
> + * Both kernels run on the same hardware, so it's impossible for
> + * kdump kernel to see the support for linear stream table only.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)))
> + ret = -EINVAL;
> + else
> + ret = arm_smmu_kdump_adopt_strtab_2lvl(smmu, cfg_reg,
> + base);
> + } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> + /*
> + * In case that the old kernel for some reason used the linear
Nit: This sounds a little judgemental, what if the HW only supports
linear table? Let's drop the "for some reason" part.
> + * format, enforce the same format to match the adopted table.
> + */
> + ret = arm_smmu_kdump_adopt_strtab_linear(smmu, cfg_reg, base);
> + if (!ret)
> + smmu->features &= ~ARM_SMMU_FEAT_2_LVL_STRTAB;
IIRC, this should NOT be set if we selected the linear format.
Looking at arm_smmu_init_strtab(), if the HW supports 2-level tables,
the driver unconditionally selects it. What is the expected scenario
where the previous kernel would have allocated a linear table on 2-level
capable hardware? IMO, it is a bug if we see linear fmt with this
feature set. Am I missing something?
> + } else {
> + dev_err(smmu->dev, "kdump: invalid STRTAB format %u\n", fmt);
> + ret = -EINVAL;
> + }
> +
> + if (ret) {
> + arm_smmu_kdump_adopt_cleanup(smmu);
> + goto err;
> + }
> +
> + ret = devm_add_action_or_reset(smmu->dev, arm_smmu_kdump_adopt_cleanup,
> + smmu);
> + /* devm_add_action_or_reset ran the cleanup upon failure */
> + if (ret) {
> + dev_warn(smmu->dev, "kdump: failed to set up cleanup action\n");
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + dev_warn(smmu->dev, "kdump: falling back to full reset\n");
> + memset(&smmu->strtab_cfg, 0, sizeof(smmu->strtab_cfg));
> + smmu->options &= ~ARM_SMMU_OPT_KDUMP_ADOPT;
> + return ret;
> +}
> +
> static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
> {
> int ret;
>
> + if ((smmu->options & ARM_SMMU_OPT_KDUMP_ADOPT) &&
> + !arm_smmu_kdump_adopt_strtab(smmu))
> + goto out;
> +
> if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
> ret = arm_smmu_init_strtab_2lvl(smmu);
> else
> @@ -4567,6 +4814,7 @@ static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
> if (ret)
> return ret;
>
> +out:
> ida_init(&smmu->vmid_map);
>
> return 0;
> --
> 2.43.0
>
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.1.2/source/drivers/base/dd.c#L1350
^ permalink raw reply
* [PATCH 3/4] ARM: dts: helios4: add SATA regulator supplies
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The ahci-mvebu driver and libahci_platform request three supplies
on SATA controller and port nodes:
- ahci-supply (controller power)
- phy-supply (PHY power)
- target-supply (disk power per port)
Without them the regulator core prints notices at boot, e.g.:
supply ahci not found, using dummy regulator
supply phy not found, using dummy regulator
supply target not found, using dummy regulator
The SATA controller and PHY inside the Armada 388 SoC are powered
by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD
rail. Wire the existing fixed regulators accordingly.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index cf0432a0e71a..626a7339a5d0 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -222,13 +222,17 @@ sata@a8000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+ ahci-supply = <®_3p3v>;
+ phy-supply = <®_3p3v>;
sata0: sata-port@0 {
reg = <0>;
+ target-supply = <®_5p0v_hdd>;
};
sata1: sata-port@1 {
reg = <1>;
+ target-supply = <®_5p0v_hdd>;
};
};
@@ -236,13 +240,17 @@ sata@e0000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+ ahci-supply = <®_3p3v>;
+ phy-supply = <®_3p3v>;
sata2: sata-port@0 {
reg = <0>;
+ target-supply = <®_5p0v_hdd>;
};
sata3: sata-port@1 {
reg = <1>;
+ target-supply = <®_5p0v_hdd>;
};
};
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: helios4: add vcc-supply to GPIO expander
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The pca953x driver requests a 'vcc' supply, producing:
pca953x 0-0020: supply vcc not found, using dummy regulator
The PCA9655 (PCA9555-compatible) expander is powered by the same
always-on 3.3V rail as the other I2C devices on the bus. Add
vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 05540b8012c2..cf0432a0e71a 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -169,6 +169,7 @@ expander0: gpio-expander@20 {
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
+ vcc-supply = <®_3p3v>;
pinctrl-names = "default";
pinctrl-0 = <&pca0_pins>;
interrupt-parent = <&gpio0>;
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: helios4: wire LM75 into a thermal zone with fan cooling
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The LM75 temperature sensor on i2c0 creates a hwmon interface but was
not referenced by any thermal zone, producing:
hwmon hwmon0: temp1_input not attached to any thermal zone
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
.../boot/dts/marvell/armada-388-helios4.dts | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 626a7339a5d0..6e0452217265 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -8,6 +8,7 @@
*/
/dts-v1/;
+#include <dt-bindings/thermal/thermal.h>
#include "armada-388.dtsi"
#include "armada-38x-solidrun-microsom.dtsi"
@@ -68,6 +69,35 @@ reg_5p0v_usb: regulator-5v-usb {
vin-supply = <®_12v>;
};
+ thermal-zones {
+ board-thermal {
+ polling-delay-passive = <2000>;
+ polling-delay = <10000>;
+ thermal-sensors = <&temp_sensor>;
+
+ trips {
+ board_alert: board-alert {
+ temperature = <55000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ board_crit: board-crit {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&board_alert>;
+ cooling-device = <&fan1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&fan2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
system-leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -129,6 +159,7 @@ fan1: j10-pwm {
pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
pinctrl-names = "default";
pinctrl-0 = <&helios_fan1_pins>;
+ #cooling-cells = <2>;
};
fan2: j17-pwm {
@@ -136,6 +167,7 @@ fan2: j17-pwm {
pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
pinctrl-names = "default";
pinctrl-0 = <&helios_fan2_pins>;
+ #cooling-cells = <2>;
};
usb2_phy: usb2-phy {
@@ -201,6 +233,7 @@ temp_sensor: temp@4c {
compatible = "ti,lm75";
reg = <0x4c>;
vcc-supply = <®_3p3v>;
+ #thermal-sensor-cells = <0>;
};
eeprom@53 {
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: helios4: add vcc-supply to EEPROM
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The at24 driver requests a 'vcc' supply for the EEPROM, producing
'supply vcc not found, using dummy regulator' at boot when the
property is missing.
The EEPROM sits on the Helios 4 and is powered by the
same always-on 3.3V rail used by other on-board I2C devices.
Add vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 390e98df49c9..05540b8012c2 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -201,6 +201,10 @@ temp_sensor: temp@4c {
reg = <0x4c>;
vcc-supply = <®_3p3v>;
};
+
+ eeprom@53 {
+ vcc-supply = <®_3p3v>;
+ };
};
i2c@11100 {
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] ARM: dts: helios4: add regulator supplies and thermal cooling
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
This series adds missing vcc-supply properties to the EEPROM and GPIO
expander on the Helios4, adds SATA regulator supplies, and wires the
on-board LM75 temperature sensor into a thermal zone with active fan
cooling.
Rosen Penev (4):
ARM: dts: helios4: add vcc-supply to EEPROM
ARM: dts: helios4: add vcc-supply to GPIO expander
ARM: dts: helios4: add SATA regulator supplies
ARM: dts: helios4: wire LM75 into a thermal zone with fan cooling
.../boot/dts/marvell/armada-388-helios4.dts | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
--
2.54.0
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: am62p5-var-som-symphony: add touchscreen support
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add support for the capacitive touchscreen on the Symphony carrier
board.
Describe the FT5x06 touchscreen controller, configure its interrupt,
and mark it as a wakeup source.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fix commit message
.../dts/ti/k3-am62p5-var-som-symphony.dts | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
index 5ba4ed56755b..5c41647ff43f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
@@ -293,6 +293,21 @@ &main_i2c1 {
clock-frequency = <400000>;
status = "okay";
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch_pins>;
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
rtc@68 {
compatible = "dallas,ds1337";
reg = <0x68>;
@@ -307,6 +322,12 @@ &main_mcan0 {
};
&main_pmx0 {
+ pinctrl_captouch_pins: main-captouch-default-pins {
+ pinctrl-single,pins = <
+ AM62PX_IOPAD(0x01b8, PIN_INPUT, 7) /* (E20) SPI0_CS1.GPIO1_16 */
+ >;
+ };
+
pinctrl_extcon: main-extcon-pins {
pinctrl-single,pins = <
AM62PX_IOPAD(0x01a8, PIN_INPUT, 7) /* (F25) MCASP0_AFSX.GPIO1_12 */
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 7/8] arm64: dts: qcom: shikra-cqs-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-7-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:54:00PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra CQS EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 6/8] arm64: dts: qcom: shikra-cqm-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-6-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:53:59PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra CQM EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 5/8] arm64: dts: qcom: shikra: Add A704 GPU support
From: Dmitry Baryshkov @ 2026-06-28 22:50 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-5-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:53:58PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Add the A704 GPU and GMU wrapper nodes with register maps, clocks,
> interconnects, IOMMU, OPP table and the zap-shader region.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 98 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 4/8] arm64: dts: qcom: shikra: Add Adreno SMMU node
From: Dmitry Baryshkov @ 2026-06-28 22:49 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Imran Shaik,
Komal Bajaj
In-Reply-To: <20260628-shikra-gpu-v3-4-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:53:57PM +0530, Akhil P Oommen wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> Add the Adreno GPU IOMMU (adreno_smmu) node for the Shikra SoC.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/5] dmaengine: sun6i-dma: Refactor to support A733 interrupt and register handling
From: Andre Przywara @ 2026-06-28 22:35 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel, Frank Li
In-Reply-To: <20260622-sun60i-a733-dma-v3-1-f697ef296cbc@gmail.com>
On Mon, 22 Jun 2026 01:36:23 +0000
Yuanshen Cao <alex.caoys@gmail.com> wrote:
Hi,
first, many thanks for sending this, also for structuring the changes
nicely, so that they remain reviewable!
> Refactor to support the Allwinner A733 DMA controller. Currently, the
> `sun6i-dma` driver has several functions related to interrupt handling
> (reading/writing interrupt enable and status registers) and register
> dumping that are hardcoded.
>
> To support the A733, which has different register layouts and interrupt
> handling logic, these functions are being moved into the
> `sun6i_dma_config` structure as function pointers.
So I see that this driver already makes use of per-device function
pointer, though personally I don't like this approach very much, as it
decreases the readability, and suggests significant differences between
the SoC generations that are not really there: each function just reads
or write an MMIO register, it's just the offset that differs.
So I think it's better to express the differences through data
entries in the config struct, for the IRQ enable/stat functions I think
this should be something like this:
struct sun6i_dma_config {
...
u32 irq_stride;
u32 irq_en_offset;
u32 irq_stat_offset;
...
};
- irq_val = readl(sdev->base + DMA_IRQ_EN(irq_reg));
+ irq_val = readl(sdev->base + sdev->cfg->irq_en_offset + irq_reg * sdev->cfg->irq_stride);
the existing configs set .stride to 0x04, and .en_offset to 0x0, the
A733 later uses .stride = 0x40 and .en_offset = 0x134.
Maybe we still move that now longish line into a helper function, but
not a config specific one.
I think that's more readable, and avoids unnecessary redirections and
potential pipeline stalls.
dump_com_regs is a different story, since the two instances of that
function are significantly different.
What do you think?
> This allows the
> driver to use a polymorphic approach where the specific implementation
> is determined by the hardware configuration assigned during device
> probing.
>
> Changes:
> - Added function pointers to `struct sun6i_dma_config` for:
By the way: the preferred style to list changes in commit messages in
imperative mood [1], not in past tense. Think about you ask the
code base what to change:
Add function pointers to ...
Implement generic functions ...
Cheers,
Andre
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n94
> - `dump_com_regs`
> - `read_irq_en`
> - `write_irq_en`
> - `read_irq_stat`
> - `write_irq_stat`
> - Implemented generic `sun6i_read/write_irq_*` functions for existing
> hardware.
> - Added a macro and updated existing `sun6i_dma_config` instances (A31,
> A23, H3, A64, A100, H6, V3S) to use these new function pointers.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 50 ++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb..ef3052c4ab36 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -138,6 +138,11 @@ struct sun6i_dma_config {
> void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
> void (*set_drq)(u32 *p_cfg, s8 src_drq, s8 dst_drq);
> void (*set_mode)(u32 *p_cfg, s8 src_mode, s8 dst_mode);
> + void (*dump_com_regs)(struct sun6i_dma_dev *sdev);
> + u32 (*read_irq_en)(struct sun6i_dma_dev *sdev, u32 irq_reg);
> + void (*write_irq_en)(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val);
> + u32 (*read_irq_stat)(struct sun6i_dma_dev *sdev, u32 irq_reg);
> + void (*write_irq_stat)(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status);
> u32 src_burst_lengths;
> u32 dst_burst_lengths;
> u32 src_addr_widths;
> @@ -347,6 +352,26 @@ static void sun6i_set_mode_h6(u32 *p_cfg, s8 src_mode, s8 dst_mode)
> DMA_CHAN_CFG_DST_MODE_H6(dst_mode);
> }
>
> +static u32 sun6i_read_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_EN(irq_reg));
> +}
> +
> +static void sun6i_write_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> +{
> + writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> +}
> +
> +static u32 sun6i_read_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_STAT(irq_reg));
> +}
> +
> +static void sun6i_write_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> +{
> + writel(status, sdev->base + DMA_IRQ_STAT(irq_reg));
> +}
> +
> static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
> {
> struct sun6i_desc *txd = pchan->desc;
> @@ -460,16 +485,16 @@ static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
>
> vchan->irq_type = vchan->cyclic ? DMA_IRQ_PKG : DMA_IRQ_QUEUE;
>
> - irq_val = readl(sdev->base + DMA_IRQ_EN(irq_reg));
> + irq_val = sdev->cfg->read_irq_en(sdev, irq_reg);
> irq_val &= ~((DMA_IRQ_HALF | DMA_IRQ_PKG | DMA_IRQ_QUEUE) <<
> (irq_offset * DMA_IRQ_CHAN_WIDTH));
> irq_val |= vchan->irq_type << (irq_offset * DMA_IRQ_CHAN_WIDTH);
> - writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> + sdev->cfg->write_irq_en(sdev, irq_reg, irq_val);
>
> writel(pchan->desc->p_lli, pchan->base + DMA_CHAN_LLI_ADDR);
> writel(DMA_CHAN_ENABLE_START, pchan->base + DMA_CHAN_ENABLE);
>
> - sun6i_dma_dump_com_regs(sdev);
> + sdev->cfg->dump_com_regs(sdev);
> sun6i_dma_dump_chan_regs(sdev, pchan);
>
> return 0;
> @@ -549,14 +574,14 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void *dev_id)
> u32 status;
>
> for (i = 0; i < sdev->num_pchans / DMA_IRQ_CHAN_NR; i++) {
> - status = readl(sdev->base + DMA_IRQ_STAT(i));
> + status = sdev->cfg->read_irq_stat(sdev, i);
> if (!status)
> continue;
>
> dev_dbg(sdev->slave.dev, "DMA irq status %s: 0x%x\n",
> str_high_low(i), status);
>
> - writel(status, sdev->base + DMA_IRQ_STAT(i));
> + sdev->cfg->write_irq_stat(sdev, i, status);
>
> for (j = 0; (j < DMA_IRQ_CHAN_NR) && status; j++) {
> pchan = sdev->pchans + j;
> @@ -1101,6 +1126,13 @@ static inline void sun6i_dma_free(struct sun6i_dma_dev *sdev)
> }
> }
>
> +#define SUN6I_DMA_IRQ_A31_COMMON_OPS \
> + .dump_com_regs = sun6i_dma_dump_com_regs, \
> + .read_irq_en = sun6i_read_irq_en, \
> + .write_irq_en = sun6i_write_irq_en, \
> + .read_irq_stat = sun6i_read_irq_stat, \
> + .write_irq_stat = sun6i_write_irq_stat,
> +
> /*
> * For A31:
> *
> @@ -1132,6 +1164,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
> .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1155,6 +1188,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
> .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> @@ -1173,6 +1207,7 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1200,6 +1235,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1221,6 +1257,7 @@ static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1244,6 +1281,7 @@ static struct sun6i_dma_config sun50i_a100_dma_cfg = {
> BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> .has_high_addr = true,
> .has_mbus_clk = true,
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1266,6 +1304,7 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> .has_mbus_clk = true,
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> /*
> @@ -1289,6 +1328,7 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
> .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> static const struct of_device_id sun6i_dma_match[] = {
>
^ permalink raw reply
* [PATCH v3] irqchip/gic-v3-its: Fix OF node reference leak
From: Yuho Choi @ 2026-06-28 22:07 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner; +Cc: linux-arm-kernel, Yuho Choi
of_get_cpu_node() returns a referenced device node. In
its_cpu_init_collection(), the Cavium 23144 workaround only uses the
node to compare the CPU NUMA node, but the reference is never dropped.
Use the device_node cleanup helper for the CPU node reference so it is
released when leaving the workaround block, including the NUMA mismatch
return path.
Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Acked-by: Marc Zyngier <maz@kernel.org>
---
Changes in v3:
- Keep the __free(device_node) assignment on a single line.
- Fix indentation in the Cavium 23144 workaround block.
- Add Marc's Acked-by.
Changes in v2:
- Use __free(device_node) for the CPU node reference.
- Correct the Fixes tag to fbf8f40e1658.
drivers/irqchip/irq-gic-v3-its.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index b57d81ad33a0..6f5811aae59c 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3290,11 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
/* avoid cross node collections and its mapping */
if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
- struct device_node *cpu_node;
+ struct device_node *cpu_node __free(device_node) = of_get_cpu_node(cpu, NULL);
- cpu_node = of_get_cpu_node(cpu, NULL);
- if (its->numa_node != NUMA_NO_NODE &&
- its->numa_node != of_node_to_nid(cpu_node))
+ if (its->numa_node != NUMA_NO_NODE && its->numa_node != of_node_to_nid(cpu_node))
return;
}
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v5 07/12] clk: zte: Add regmap based clocks
From: Stefan Dösinger @ 2026-06-28 19:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
This is based on meson/clk-regmap.c, although slightly simplified. I
have kept the copyright lines at the top of the file to indicate its
origin.
I see that numerous clock drivers have their own incarnation of regmap
based mux/div/gate clocks. If there is any version of it that is likely
to be elevated to shared code liks clk-gate.c I'll copy that and try to
use it as unmodified as possible.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 5: Use regmap_test_bits in zte_clk_regmap_gate_is_enabled
---
drivers/clk/zte/clk-regmap.c | 221 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 218 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/zte/clk-regmap.c b/drivers/clk/zte/clk-regmap.c
index 7908f1562f63..903998ca9508 100644
--- a/drivers/clk/zte/clk-regmap.c
+++ b/drivers/clk/zte/clk-regmap.c
@@ -6,25 +6,240 @@
* Author: Stefan Dösinger <stefandoesinger@gmail.com>
*/
+#include <linux/clk-provider.h>
+#include <linux/regmap.h>
+#include <linux/device.h>
+
#include "clk-zx.h"
+struct zte_clk_regmap {
+ struct clk_hw hw;
+ struct regmap *map;
+ u16 reg;
+ u8 shift;
+ u8 size;
+};
+
+static inline struct zte_clk_regmap *to_zte_clk_regmap(struct clk_hw *hw)
+{
+ return container_of(hw, struct zte_clk_regmap, hw);
+}
+
+static int zte_clk_regmap_gate_enable(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ return regmap_set_bits(clk->map, clk->reg, BIT(clk->shift));
+}
+
+static void zte_clk_regmap_gate_disable(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ regmap_clear_bits(clk->map, clk->reg, BIT(clk->shift));
+}
+
+static int zte_clk_regmap_gate_is_enabled(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ return regmap_test_bits(clk->map, clk->reg, BIT(clk->shift));
+}
+
+static const struct clk_ops zte_clk_regmap_gate_ops = {
+ .enable = zte_clk_regmap_gate_enable,
+ .disable = zte_clk_regmap_gate_disable,
+ .is_enabled = zte_clk_regmap_gate_is_enabled,
+};
+
int zx_clk_register_gates(struct device *dev, struct regmap *regmap,
const struct zx_gate_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_gate_ops;
+ init.parent_names = &desc[i].parent;
+ init.num_parents = 1;
+ init.flags = CLK_SET_RATE_PARENT | desc[i].flags;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = 1;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
+}
+
+static unsigned long zte_clk_regmap_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, clk->reg, &val);
+ if (ret)
+ /* Gives a hint that something is wrong */
+ return 0;
+
+ val >>= clk->shift;
+ val &= clk_div_mask(clk->size);
+ return divider_recalc_rate(hw, prate, val, NULL, 0, clk->size);
}
+static int zte_clk_regmap_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+
+ return divider_determine_rate(hw, req, NULL, clk->size, 0);
+}
+
+static int zte_clk_regmap_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = divider_get_val(rate, parent_rate, NULL, clk->size, 0);
+ if (ret < 0)
+ return ret;
+
+ val = (unsigned int)ret << clk->shift;
+ return regmap_update_bits(clk->map, clk->reg, clk_div_mask(clk->size) << clk->shift, val);
+};
+
+static const struct clk_ops zte_clk_regmap_divider_ops = {
+ .recalc_rate = zte_clk_regmap_div_recalc_rate,
+ .determine_rate = zte_clk_regmap_div_determine_rate,
+ .set_rate = zte_clk_regmap_div_set_rate,
+};
+
int zx_clk_register_dividers(struct device *dev, struct regmap *regmap,
const struct zx_div_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_divider_ops;
+ init.parent_names = &desc[i].parent;
+ init.num_parents = 1;
+ init.flags = CLK_SET_RATE_PARENT;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = desc[i].size;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
}
+static u8 zte_clk_regmap_mux_get_parent(struct clk_hw *hw)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, clk->reg, &val);
+ if (ret)
+ return 0xff;
+
+ val >>= clk->shift;
+ val &= GENMASK(clk->size - 1, 0);
+ return clk_mux_val_to_index(hw, NULL, 0, val);
+}
+
+static int zte_clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
+ unsigned int val = clk_mux_index_to_val(NULL, 0, index);
+
+ return regmap_update_bits(clk->map, clk->reg,
+ GENMASK(clk->size - 1, 0) << clk->shift,
+ val << clk->shift);
+}
+
+static int zte_clk_regmap_mux_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+ return clk_mux_determine_rate_flags(hw, req, 0);
+}
+
+static const struct clk_ops zte_clk_regmap_mux_ops = {
+ .get_parent = zte_clk_regmap_mux_get_parent,
+ .set_parent = zte_clk_regmap_mux_set_parent,
+ .determine_rate = zte_clk_regmap_mux_determine_rate,
+};
+
int zx_clk_register_muxes(struct device *dev, struct regmap *regmap,
const struct zx_mux_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zte_clk_regmap *clk;
+ unsigned int i;
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ clk = devm_kzalloc(dev, sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zte_clk_regmap_mux_ops;
+ init.parent_names = desc[i].parents;
+ init.num_parents = desc[i].num_parents;
+ clk->hw.init = &init;
+ clk->map = regmap;
+ clk->reg = desc[i].reg;
+ clk->shift = desc[i].shift;
+ clk->size = desc[i].size;
+
+ res = devm_clk_hw_register(dev, &clk->hw);
+ if (res)
+ return dev_err_probe(dev, res, "Failed to register clk %s\n", desc[i].name);
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id] = &clk->hw;
+ }
+
+ return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v5 06/12] clk: zte: Add zx PLL support infrastructure
From: Stefan Dösinger @ 2026-06-28 19:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
I am guessing how much of this is reusable among other zx chips or even
differently named ZTE platforms (if there are any). From reading the old
zx2967 code, I think the PLL code would be reusable there, maybe with
platform specific bitmasks but otherwise the same logic.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 5: Fix Some issues pointed out by Sashiko: NULL dev,
zx29_pll_recalc_rate error handling, disable PLL again on enable error.
I am not sure how to deal with best_parent_rate I added a FIXME and I'm
hoping for human suggestions.
---
drivers/clk/zte/pll-zx.c | 468 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 467 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
index c0475d5441fb..1482caeea999 100644
--- a/drivers/clk/zte/pll-zx.c
+++ b/drivers/clk/zte/pll-zx.c
@@ -11,9 +11,475 @@
#include "clk-zx.h"
+/* This code has only been tested with zx297520v3 PLLs, but from reading the zx296718 clock code it
+ * looks like PLL registers are similar. ZTE's sources explain the PLL register contents only in a
+ * .cmm file (A Lauterback TRACE32 script) and some unused headers in their U-Boot code dump, which
+ * may not be accurate. When calculating the frequencies from the default PLL configuration the
+ * results match the fixed rate clocks from their clock driver.
+ *
+ * The 26mhz and 32khz clocks can be easily observed with the timers. The 104mhz output can be
+ * observed through the UART. One 122.88 PLL can be observed through the TDM device. All others can
+ * only be indirectly infered, e.g. by comparing CPU speed or SDIO transfer rate between the fixed
+ * 26 MHz oscillator and the provided PLL frequency.
+ *
+ * The formula to calculate the clock is ((ref / refdiv) * fbdiv) / postdiv1 / postdiv2. The masks
+ * are given below. There are a few control flags:
+ *
+ * Bit 31: Disables the PLL, but passes the reference through unmodified. If POSTDIV_OUT_DISABLE
+ * still matters is different between PLLs.
+ * Bit 30: Returns if the PLL is locked
+ * Bit 29: Not named in ZTE's code, but can be set. There is no obvious impact. Lock times are
+ * unchanged, so it doesn't influence or bypass lock detection. It doesn't raise any IRQs or
+ * influence GPIOs.
+ * Bit 27: Given its name it likely disables the Delta-Sigma Modulator, if one exists at all. The
+ * boot ROM sets it on every PLL. Unsetting it marginally decreases the time it takes to
+ * lock to the reference clock (from ~400us to ~300us). Regardless of this bit I could not
+ * make the supposed fractional part in register 2 work.
+ * Bit 24: Bypasses the VCO, but still applies refdiv and postdiv. Doesn't matter if PLL_DISABLE=1.
+ */
+
+#define ZX29_PLL_DISABLE BIT(31)
+#define ZX29_PLL_LOCKED BIT(30)
+#define ZX29_PLL_LOCK_FILTER BIT(29)
+#define ZX29_PLL_DSM_DISABLE BIT(27)
+#define ZX29_PLL_PARENT_MASK GENMASK(26, 25)
+#define ZX29_PLL_PARENT_SHIFT 25
+#define ZX29_PLL_BYPASS BIT(24)
+#define ZX29_PLL_REFDIV_MASK GENMASK(23, 18)
+#define ZX29_PLL_REFDIV_SHIFT 18
+#define ZX29_PLL_FBDIV_MASK GENMASK(17, 6)
+#define ZX29_PLL_FBDIV_SHIFT 6
+#define ZX29_PLL_POSTDIV1_MASK GENMASK(5, 3)
+#define ZX29_PLL_POSTDIV1_SHIFT 3
+#define ZX29_PLL_POSTDIV2_MASK GENMASK(2, 0)
+#define ZX29_PLL_POSTDIV2_SHIFT 0
+
+/* The second register is supposed to have another 24 bit value that gets added to fbdiv but it is
+ * always 0 in the preconfigured values. I could not observe any effect from setting it to something
+ * other than 0, regardless of the DSM disable bit. It is possible that it is only supported by
+ * dpll, which is a possible parent for i2s.
+ *
+ * Bits 28:25 contain more flags:
+ *
+ * Bit 27: Setting ZX29_PLL_DACAP slows down the lock time and obivates the speed gained from
+ * !DSM_DISABLE. No other effect observed.
+ *
+ * Bit 26: ZX29_PLL_4PHASE_OUT_DISABLE is set on some PLLs on boot but not on others. It is set on
+ * boot on mpll and upll, but not gpll, dpll or unknownpll. I am not sure what it does
+ * either. The SDIO devices break if they are fed from gpll with this flag set, but they
+ * work ok if they are fed from mpll without this flag set.
+ *
+ * Bit 25: ZX29_PLL_POSTDIV_OUT_DISABLE seems to disable the PLL output entirely. Whether it is
+ * bypassed by PLL_DISABLE differs between PLLs. gpll still produces an output clock if
+ * PLL_DISABLE = 1 and POSTDIV_DISABLE = 1, but produces no output if PLL_DISABLE = 0 and
+ * POSTDIV_DISABLE = 1. The dpll feeder ("unknownpll") at 0x100 produces no output clock
+ * if both PLL_DISABLE and POSTDIV_DISABLE are set to 1.
+ *
+ * Bit 24: ZX29_PLL_VCO_OUT_DISABLE probably disables the output of the VCO clock without
+ * post-VCO-dividers, but the raw VCO output is not a possible parent of any consumer clock,
+ * so I could not confirm this. It does not disable the VCO entirely - that's what
+ * PLL_DISABLE does.
+ *
+ * A spinlock should not be needed. PLLs don't share their registers with anything else and the
+ * global prepare mutex and enable spinlock should be enough. Beware of conflicts in reg2 between
+ * POSTDIV_OUT_DISABLE and the fractional value in case you find out how fractional dividers work
+ * and add support for them.
+ */
+#define ZX29_PLL_REG2_OFFSET 4
+#define ZX29_PLL_DACAP BIT(27)
+#define ZX29_PLL_4PHASE_OUT_DISABLE BIT(26)
+#define ZX29_PLL_POSTDIV_OUT_DISABLE BIT(25)
+#define ZX29_PLL_VCO_OUT_DISABLE BIT(24)
+
+/* The VCO's frequency range is limited. The stock settings run the VCO between 960 and 1248 MHz.
+ * Ad-hoc testing with gpll suggests that at least this PLL remains stable down to about 7 MHz and
+ * up to 2 GHz and produces a clock that can be used by the SDIO controller. Attempting to run the
+ * mpll VCO at 624 MHz and setting postdiv1 = postdiv2 = 1 - which should result in the same output
+ * frequency - or running it at 1872 MHz with an effective post divider of 3 crashes the CPU. Most
+ * likely the PLLs become unstable outside their core range and the SDIO controller is much more
+ * forgiving than CPU and DRAM are.
+ */
+#define ZX29_PLL_VCO_MAX_FREQ (1300*HZ_PER_MHZ)
+#define ZX29_PLL_VCO_MIN_FREQ (900*HZ_PER_MHZ)
+
+struct zx29_clk_pll {
+ struct clk_hw hw;
+ struct device *dev;
+ struct regmap *map;
+ u16 reg;
+};
+
+static inline struct zx29_clk_pll *to_zx29_clk_pll(struct clk_hw *hw)
+{
+ return container_of(hw, struct zx29_clk_pll, hw);
+}
+
+static int zx29_pll_is_prepared(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res;
+
+ res = regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+ if (res < 0)
+ return res;
+
+ return !res;
+}
+
+static int zx29_pll_prepare(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+ if (res < 0)
+ return res;
+
+ /* Lock duration is usually between 300us to 500us */
+ res = regmap_read_poll_timeout(pll->map, pll->reg, val, val & ZX29_PLL_LOCKED, 50, 2000);
+ if (res) {
+ regmap_set_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+ dev_err(pll->dev, "%s: PLL enable failed: %d\n", clk_hw_get_name(&pll->hw), val);
+ }
+ return res;
+}
+
+static void zx29_pll_unprepare(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ regmap_set_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
+}
+
+static int zx29_pll_is_enabled(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res;
+
+ res = regmap_test_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+ if (res < 0)
+ return res;
+
+ return !res;
+}
+
+static int zx29_pll_enable(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ return regmap_clear_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+}
+
+static void zx29_pll_disable(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+
+ regmap_set_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+}
+
+static unsigned long zx29_pll_get_rate(const struct zx29_clk_pll *pll, unsigned long parent_rate,
+ u32 setting)
+{
+ unsigned long refdiv, fbdiv, postdiv1, postdiv2, freq;
+ const char *name = clk_hw_get_name(&pll->hw);
+ u64 vco;
+
+ refdiv = (setting & ZX29_PLL_REFDIV_MASK) >> ZX29_PLL_REFDIV_SHIFT;
+ fbdiv = (setting & ZX29_PLL_FBDIV_MASK) >> ZX29_PLL_FBDIV_SHIFT;
+ postdiv1 = (setting & ZX29_PLL_POSTDIV1_MASK) >> ZX29_PLL_POSTDIV1_SHIFT;
+ postdiv2 = (setting & ZX29_PLL_POSTDIV2_MASK) >> ZX29_PLL_POSTDIV2_SHIFT;
+ dev_dbg(pll->dev, "%s: reference clock %lu HZ, PLL setting 0x%08x\n",
+ name, parent_rate, setting);
+
+ if (!refdiv || !postdiv1 || !postdiv2) {
+ dev_err(pll->dev, "%s: divide by zero (%lu, %lu, %lu)\n", name, refdiv, postdiv1,
+ postdiv2);
+ return 0;
+ }
+
+ vco = div_u64((u64)parent_rate * fbdiv, refdiv);
+ freq = div_u64(div_u64(vco, postdiv1), postdiv2);
+ dev_dbg(pll->dev, "%s: refdiv %lu fbdiv %lu\n", name, refdiv, fbdiv);
+ dev_dbg(pll->dev, "%s: postdiv1 %lu postdiv2 %lu\n", name, postdiv1, postdiv2);
+
+ dev_dbg(pll->dev, "%s: %lu MHZ\n", name, freq / HZ_PER_MHZ);
+
+ return freq;
+}
+
+static unsigned long zx29_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0) {
+ dev_err(pll->dev, "%s: Failed to read PLL settings\n", clk_hw_get_name(&pll->hw));
+ return 0;
+ }
+
+ return zx29_pll_get_rate(pll, parent_rate, val);
+}
+
+static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
+ unsigned long rate)
+{
+ const unsigned int postdiv1_max = (1 << hweight32(ZX29_PLL_POSTDIV1_MASK)) - 1;
+ const unsigned int postdiv2_max = (1 << hweight32(ZX29_PLL_POSTDIV2_MASK)) - 1;
+ unsigned long fbdiv, refdiv, best_fbdiv = 0, best_refdiv = 0;
+ u32 postdiv1 = 0, postdiv2 = 0, i, j, setting;
+ const char *name = clk_hw_get_name(&pll->hw);
+ long best = LONG_MAX;
+
+ /* This code produces the same VCO settings that the boot loader and stock firmware use for
+ * the standard frequencies. It has seen only very little manual testing beyond that.
+ *
+ * The goal is to find a VCO setting that gets us as close as possible to the desired output
+ * rate, while being within the VCO's operating limits and achievable with the input value
+ * range. It is iterating over possible post-VCO diver values (1-7)*(1-7) to look for valid
+ * VCO target frequencies and then looks for refdiv and fbdiv values to achieve the VCO
+ * frequency from the reference frequency.
+ */
+ for (j = 1; j <= postdiv2_max; j++) {
+ for (i = 1; i <= postdiv1_max; i++) {
+ u64 vco = (u64)rate * i * j;
+ long out;
+
+ if (vco > ZX29_PLL_VCO_MAX_FREQ || vco < ZX29_PLL_VCO_MIN_FREQ)
+ continue;
+
+ rational_best_approximation(vco, parent_rate,
+ (1 << hweight32(ZX29_PLL_FBDIV_MASK)) - 1,
+ (1 << hweight32(ZX29_PLL_REFDIV_MASK)) - 1,
+ &fbdiv, &refdiv);
+ setting = fbdiv << ZX29_PLL_FBDIV_SHIFT;
+ setting |= refdiv << ZX29_PLL_REFDIV_SHIFT;
+ setting |= i << ZX29_PLL_POSTDIV1_SHIFT;
+ setting |= j << ZX29_PLL_POSTDIV2_SHIFT;
+ out = zx29_pll_get_rate(pll, parent_rate, setting);
+
+ if (abs(out - rate) > best)
+ continue;
+
+ if (abs(out - rate) < best) {
+ postdiv1 = i;
+ postdiv2 = j;
+ best_fbdiv = fbdiv;
+ best_refdiv = refdiv;
+ best = abs(out - rate);
+
+ if (!best)
+ goto search_done;
+ }
+ }
+ }
+search_done:
+
+ if (!postdiv1) {
+ dev_err(pll->dev, "Did not find a setting for %lu Hz, parent %lu Hz\n",
+ rate, parent_rate);
+ return 0;
+ }
+
+ dev_dbg(pll->dev, "%s: parent rate %lu\n", name, parent_rate);
+ dev_dbg(pll->dev, "%s: found VCO dividers %u and %u\n", name, postdiv1, postdiv2);
+ dev_dbg(pll->dev, "%s: VCO target rate %lu\n", name, rate * postdiv1 * postdiv2);
+
+ dev_dbg(pll->dev, "%s: Got fbdiv = %lu refdiv = %lu\n", name, best_fbdiv, best_refdiv);
+
+ setting = best_fbdiv << ZX29_PLL_FBDIV_SHIFT;
+ setting |= best_refdiv << ZX29_PLL_REFDIV_SHIFT;
+ setting |= postdiv1 << ZX29_PLL_POSTDIV1_SHIFT;
+ setting |= postdiv2 << ZX29_PLL_POSTDIV2_SHIFT;
+ dev_dbg(pll->dev, "%s: Final setting 0x%08x\n", name, setting);
+
+ return setting;
+}
+
+static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ unsigned long new_rate, parent_rate = clk_hw_get_rate(clk_hw_get_parent(&pll->hw));
+ u32 setting;
+
+ setting = zx29_pll_calc_values(pll, parent_rate, req->rate);
+ if (!setting)
+ return -EINVAL;
+
+ new_rate = zx29_pll_get_rate(pll, parent_rate, setting);
+ if (new_rate != req->rate) {
+ dev_warn(pll->dev, "Did not find an exact match. Want %lu, got %lu\n",
+ req->rate, new_rate);
+ req->rate = new_rate;
+ }
+
+ return 0;
+}
+
+static int zx29_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ int res = -EINVAL;
+ u32 setting;
+
+ setting = zx29_pll_calc_values(pll, parent_rate, rate);
+ if (zx29_pll_get_rate(pll, parent_rate, setting) == rate) {
+ res = regmap_update_bits(pll->map, pll->reg, 0x00ffffff, setting);
+ dev_info(pll->dev, "%s: Setting rate: 0x%08x\n", clk_hw_get_name(hw), setting);
+ }
+
+ return res;
+}
+
+static u8 zx29_pll_get_parent(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 val;
+ int res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0)
+ return 0xff;
+
+ val = (val & ZX29_PLL_PARENT_MASK) >> ZX29_PLL_PARENT_SHIFT;
+ dev_dbg(pll->dev, "%s: Parent 0x%x\n", clk_hw_get_name(hw), val);
+
+ return val;
+}
+
+static int zx29_pll_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ u32 idx_shift = index << ZX29_PLL_PARENT_SHIFT;
+ int res;
+ u32 val;
+
+ res = regmap_update_bits(pll->map, pll->reg, ZX29_PLL_PARENT_MASK, idx_shift);
+ if (res < 0)
+ return res;
+
+ res = regmap_read(pll->map, pll->reg, &val);
+ if (res < 0)
+ return res;
+
+ if ((val & ZX29_PLL_PARENT_MASK) != idx_shift) {
+ dev_err(pll->dev, "Hardware rejected PLL parent %u\n", index);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int zx29_pll_init(struct clk_hw *hw)
+{
+ struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
+ const char *name = clk_hw_get_name(hw);
+ int res;
+
+ dev_dbg(pll->dev, "%s: initializing\n", name);
+
+ /* Remove the bypass flag so we don't have to bother with it in enable/disable. I have
+ * never seen it set by the earlier boot stages anyhow.
+ */
+ res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_BYPASS);
+ if (res < 0)
+ return res;
+
+ if (regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE) > 0) {
+ /* Set ZX29_PLL_POSTDIV_OUT_DISABLE for PLLs that have ZX29_PLL_DISABLE for
+ * consistency with .enable and .prepare. This ensures that .prepare doesn't
+ * inadvertedly enable PLLs without .enable being called.
+ */
+ res = regmap_set_bits(pll->map, pll->reg + ZX29_PLL_REG2_OFFSET,
+ ZX29_PLL_POSTDIV_OUT_DISABLE);
+ if (res < 0)
+ return res;
+ }
+
+ return 0;
+}
+
+const struct clk_ops zx29_pll_ops = {
+ .init = zx29_pll_init,
+ .is_prepared = zx29_pll_is_prepared,
+ .prepare = zx29_pll_prepare,
+ .unprepare = zx29_pll_unprepare,
+ .is_enabled = zx29_pll_is_enabled,
+ .enable = zx29_pll_enable,
+ .disable = zx29_pll_disable,
+ .recalc_rate = zx29_pll_recalc_rate,
+ .determine_rate = zx29_pll_determine_rate,
+ .get_parent = zx29_pll_get_parent,
+ .set_parent = zx29_pll_set_parent,
+ .set_rate = zx29_pll_set_rate,
+};
+
int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
const struct zx_pll_desc *desc, unsigned int num,
struct clk_hw_onecell_data *clocks)
{
- return -ENODEV;
+ struct zx29_clk_pll *pll;
+ unsigned int i, f;
+ struct clk_hw *hw;
+ char plldiv[32];
+ int res;
+
+ for (i = 0; i < num; ++i) {
+ struct clk_init_data init = {};
+
+ pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return -ENOMEM;
+
+ init.name = desc[i].name;
+ init.ops = &zx29_pll_ops;
+ init.parent_names = desc[i].parents;
+ init.num_parents = desc[i].num_parents;
+ pll->hw.init = &init;
+ pll->dev = dev;
+ pll->map = regmap;
+ pll->reg = desc[i].reg;
+
+ res = devm_clk_hw_register(dev, &pll->hw);
+ if (res)
+ return res;
+
+ /* Set the PLL rate only if the bootloader left it disabled. Keep the bootloader
+ * setup otherwise.
+ */
+ if (regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE) > 0 && desc[i].rate) {
+ dev_dbg(pll->dev, "%s: Setting to %lu Hz\n", desc[i].name, desc[i].rate);
+ res = clk_set_rate(pll->hw.clk, desc[i].rate);
+ if (res) {
+ dev_err(dev, "%s: Failed to set rate.\n", desc[i].name);
+ return res;
+ }
+ }
+
+ if (desc[i].id && desc[i].postdivs && desc[i].postdivs[0] == 1)
+ clocks->hws[desc[i].id] = &pll->hw;
+
+ for (f = 0; f < desc[i].num_postdivs; ++f) {
+ if (desc[i].postdivs[f] == 1)
+ continue;
+
+ snprintf(plldiv, sizeof(plldiv), "%s_d%u", desc[i].name,
+ desc[i].postdivs[f]);
+ hw = devm_clk_hw_register_fixed_factor(dev, plldiv, desc[i].name,
+ 0, 1, desc[i].postdivs[f]);
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ dev_dbg(pll->dev, "%s: %lu hz\n", clk_hw_get_name(hw), clk_hw_get_rate(hw));
+
+ if (desc[i].id)
+ clocks->hws[desc[i].id + f] = hw;
+ }
+ }
+
+ return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
From: Stefan Dösinger @ 2026-06-28 19:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
The next patches will implement the regmap clocks and PLL driver. The
actual hardware specific clock listing will live in a separate module.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 5:
*) Pass the static clk data instead of calling get_match_data to prepare
for operating as an MFD child.
*) Don't use devm_kzalloc to allocate the auxiliary_device
structure. I guess Sashiko is right, and that's what "Because once the
device is placed on the bus the parent driver can not tell what other
code may have a reference to this data" is trying to dell me.
*) Fix error check for device_node_to_regmap.
---
MAINTAINERS | 1 +
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/zte/Kconfig | 17 ++++
drivers/clk/zte/Makefile | 5 ++
drivers/clk/zte/clk-regmap.c | 30 +++++++
drivers/clk/zte/clk-zx.c | 192 +++++++++++++++++++++++++++++++++++++++++++
drivers/clk/zte/clk-zx.h | 81 ++++++++++++++++++
drivers/clk/zte/pll-zx.c | 19 +++++
9 files changed, 347 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57af566030db..297c15a2c860 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3871,6 +3871,7 @@ F: Documentation/devicetree/bindings/clock/zte,zx297520v3-lspcrm.yaml
F: Documentation/devicetree/bindings/soc/zte/
F: arch/arm/boot/dts/zte/
F: arch/arm/mach-zte/
+F: drivers/clk/zte/
F: drivers/soc/zte/
F: include/dt-bindings/clock/zte,zx297520v3-clk.h
F: include/dt-bindings/reset/zte,zx297520v3-reset.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 1717ce75a907..6f0a863951ca 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -545,6 +545,7 @@ source "drivers/clk/uniphier/Kconfig"
source "drivers/clk/visconti/Kconfig"
source "drivers/clk/x86/Kconfig"
source "drivers/clk/xilinx/Kconfig"
+source "drivers/clk/zte/Kconfig"
source "drivers/clk/zynqmp/Kconfig"
# Kunit test cases
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index cc108a75a900..13a5478f1112 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -167,5 +167,6 @@ ifeq ($(CONFIG_COMMON_CLK), y)
obj-$(CONFIG_X86) += x86/
endif
obj-y += xilinx/
+obj-$(CONFIG_COMMON_CLK_ZTE) += zte/
obj-$(CONFIG_ARCH_ZYNQ) += zynq/
obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
diff --git a/drivers/clk/zte/Kconfig b/drivers/clk/zte/Kconfig
new file mode 100644
index 000000000000..b7b65a2172a9
--- /dev/null
+++ b/drivers/clk/zte/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# ZTE Clock Drivers
+#
+
+config COMMON_CLK_ZTE
+ tristate "Clock driver for ZTE SoCs"
+ depends on ARCH_ZTE || COMPILE_TEST
+ default ARCH_ZTE
+ select AUXILIARY_BUS
+ select MFD_SYSCON
+ help
+ This option selects common clock infrastructure for ZTE based SoCs.
+ You will need to enable one or more SoC specific drivers to make use
+ of this.
+
+ Enable this if you are building a kernel for a ZTE designed board.
diff --git a/drivers/clk/zte/Makefile b/drivers/clk/zte/Makefile
new file mode 100644
index 000000000000..27db07293165
--- /dev/null
+++ b/drivers/clk/zte/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_COMMON_CLK_ZTE) += clk-zte.o
+
+clk-zte-y += clk-zx.o pll-zx.o clk-regmap.o
diff --git a/drivers/clk/zte/clk-regmap.c b/drivers/clk/zte/clk-regmap.c
new file mode 100644
index 000000000000..7908f1562f63
--- /dev/null
+++ b/drivers/clk/zte/clk-regmap.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Copyright (c) 2018 BayLibre, SAS.
+ * Copyright (c) 2026 Stefan Dösinger.
+ * Author: Stefan Dösinger <stefandoesinger@gmail.com>
+ */
+
+#include "clk-zx.h"
+
+int zx_clk_register_gates(struct device *dev, struct regmap *regmap,
+ const struct zx_gate_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks)
+{
+ return -ENODEV;
+}
+
+int zx_clk_register_dividers(struct device *dev, struct regmap *regmap,
+ const struct zx_div_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks)
+{
+ return -ENODEV;
+}
+
+int zx_clk_register_muxes(struct device *dev, struct regmap *regmap,
+ const struct zx_mux_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks)
+{
+ return -ENODEV;
+}
diff --git a/drivers/clk/zte/clk-zx.c b/drivers/clk/zte/clk-zx.c
new file mode 100644
index 000000000000..d098243145ce
--- /dev/null
+++ b/drivers/clk/zte/clk-zx.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+
+#include "clk-zx.h"
+
+static void zx_adev_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ kfree(adev);
+}
+
+static void zx_adev_unregister(void *data)
+{
+ struct auxiliary_device *adev = data;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+static void zx_delete_clk_provider(void *data)
+{
+ of_clk_del_provider(data);
+}
+
+static void zx_clk_disable_unprepare_put(void *data)
+{
+ clk_disable_unprepare(data);
+ clk_put(data);
+}
+
+int zx_clk_common_probe(struct device *dev, struct device_node *of_node,
+ const struct zx_clk_data *data)
+{
+ unsigned int public_clk_count = 1, highest_id = 0;
+ struct clk_hw_onecell_data *clocks;
+ struct auxiliary_device *adev;
+ struct regmap *map;
+ struct clk *clk;
+ unsigned int i;
+ int res;
+
+ map = device_node_to_regmap(of_node);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ for (i = 0; i < data->num_plls; ++i) {
+ if (data->plls[i].id) {
+ unsigned int last_idx = data->plls[i].id + data->plls[i].num_postdivs - 1;
+
+ if (last_idx > highest_id)
+ highest_id = last_idx;
+ public_clk_count += data->plls[i].num_postdivs;
+ }
+ }
+ for (i = 0; i < data->num_muxes; ++i) {
+ if (data->muxes[i].id) {
+ if (data->muxes[i].id > highest_id)
+ highest_id = data->muxes[i].id;
+ public_clk_count++;
+ }
+ }
+ for (i = 0; i < data->num_divs; ++i) {
+ if (data->divs[i].id) {
+ if (data->divs[i].id > highest_id)
+ highest_id = data->divs[i].id;
+ public_clk_count++;
+ }
+ }
+ for (i = 0; i < data->num_gates; ++i) {
+ if (data->gates[i].id) {
+ if (data->gates[i].id > highest_id)
+ highest_id = data->gates[i].id;
+ public_clk_count++;
+ }
+ }
+
+ if (WARN_ON(public_clk_count != highest_id + 1))
+ return -EINVAL;
+
+ clocks = devm_kzalloc(dev, struct_size(clocks, hws, public_clk_count), GFP_KERNEL);
+ if (!clocks)
+ return -ENOMEM;
+ clocks->num = public_clk_count;
+
+ for (i = 0; i < data->num_inputs_enable; ++i) {
+ clk = of_clk_get_by_name(of_node, data->inputs_enable[i]);
+ if (IS_ERR(clk)) {
+ return dev_err_probe(dev, PTR_ERR(clk), "Input clk %s failure\n",
+ data->inputs_enable[i]);
+ }
+
+ res = clk_prepare_enable(clk);
+ if (res) {
+ clk_put(clk);
+ return dev_err_probe(dev, PTR_ERR(clk), "Input clk %s enable failure\n",
+ data->inputs_enable[i]);
+ }
+ res = devm_add_action_or_reset(dev, zx_clk_disable_unprepare_put, clk);
+ if (res)
+ return res;
+ }
+ for (i = 0; i < data->num_inputs; ++i) {
+ /* FIXME: devm_get_clk_from_child doesn't do any tree traversal, so it works here
+ * whether "of_node" belongs to "dev" or a parent of "dev". Is it supposed to be
+ * used that way though?
+ */
+ clk = devm_get_clk_from_child(dev, of_node, data->inputs[i]);
+ if (IS_ERR(clk)) {
+ return dev_err_probe(dev, PTR_ERR(clk), "Input clk %s failure\n",
+ data->inputs[i]);
+ }
+ }
+
+ res = zx_clk_register_plls(dev, map, data->plls, data->num_plls, clocks);
+ if (res)
+ return res;
+
+ res = zx_clk_register_muxes(dev, map, data->muxes, data->num_muxes, clocks);
+ if (res)
+ return res;
+
+ res = zx_clk_register_dividers(dev, map, data->divs, data->num_divs, clocks);
+ if (res)
+ return res;
+
+ res = zx_clk_register_gates(dev, map, data->gates, data->num_gates, clocks);
+ if (res)
+ return res;
+
+ /* This is to catch holes in the tables rather than registration errors. The count vs
+ * highest ID should catch most static issues. This check here will trigger if an ID is
+ * reused by accident.
+ */
+ for (i = 1; i < public_clk_count; i++) {
+ if (WARN(!clocks->hws[i], "Clock %u not registered\n", i))
+ return -EINVAL;
+ }
+
+ res = of_clk_add_hw_provider(of_node, of_clk_hw_onecell_get, clocks);
+ if (res)
+ return res;
+ res = devm_add_action_or_reset(dev, zx_delete_clk_provider, of_node);
+ if (res)
+ return res;
+
+ if (!data->reset_auxdev_name)
+ return 0;
+
+ adev = kzalloc_obj(*adev);
+ if (!adev)
+ return -ENOMEM;
+
+ adev->name = data->reset_auxdev_name;
+ adev->dev.parent = dev;
+ adev->dev.release = zx_adev_release;
+ adev->dev.of_node = of_node;
+
+ res = auxiliary_device_init(adev);
+ if (res) {
+ dev_err_probe(dev, res, "Failed to init aux dev %s\n", adev->name);
+ goto adev_free;
+ }
+
+ res = auxiliary_device_add(adev);
+ if (res) {
+ dev_err_probe(dev, res, "Failed to add aux dev %s\n", adev->name);
+ goto adev_uninit;
+ }
+
+ return devm_add_action_or_reset(dev, zx_adev_unregister, adev);
+
+adev_uninit:
+ auxiliary_device_uninit(adev);
+adev_free:
+ kfree(adev);
+ return res;
+}
+EXPORT_SYMBOL_NS_GPL(zx_clk_common_probe, "ZTE_CLK");
+
+MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
+MODULE_DESCRIPTION("ZTE common clock driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/zte/clk-zx.h b/drivers/clk/zte/clk-zx.h
new file mode 100644
index 000000000000..dabb71f27c16
--- /dev/null
+++ b/drivers/clk/zte/clk-zx.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+
+#ifndef __DRV_CLK_ZX_H
+#define __DRV_CLK_ZX_H
+
+#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+struct zx_pll_desc {
+ unsigned int id;
+ const char *name;
+ const char * const *parents;
+ unsigned int num_parents;
+ unsigned long rate;
+ const unsigned int *postdivs;
+ unsigned int num_postdivs;
+ u16 reg;
+};
+
+struct zx_mux_desc {
+ unsigned int id;
+ const char *name;
+ const char * const *parents;
+ unsigned int num_parents;
+ u16 reg;
+ u8 shift, size;
+};
+
+struct zx_div_desc {
+ unsigned int id;
+ const char *name, *parent;
+ u16 reg;
+ u8 shift, size;
+};
+
+struct zx_gate_desc {
+ unsigned int id;
+ const char *name, *parent;
+ unsigned long flags;
+ u16 reg;
+ u8 shift;
+};
+
+int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
+ const struct zx_pll_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks);
+int zx_clk_register_muxes(struct device *dev, struct regmap *regmap,
+ const struct zx_mux_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks);
+int zx_clk_register_dividers(struct device *dev, struct regmap *regmap,
+ const struct zx_div_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks);
+int zx_clk_register_gates(struct device *dev, struct regmap *regmap,
+ const struct zx_gate_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks);
+
+struct zx_clk_data {
+ const char * const *inputs_enable;
+ unsigned int num_inputs_enable;
+ const char * const *inputs;
+ unsigned int num_inputs;
+ const struct zx_pll_desc *plls;
+ unsigned int num_plls;
+ const struct zx_mux_desc *muxes;
+ unsigned int num_muxes;
+ const struct zx_div_desc *divs;
+ unsigned int num_divs;
+ const struct zx_gate_desc *gates;
+ unsigned int num_gates;
+ const char *reset_auxdev_name;
+};
+
+int zx_clk_common_probe(struct device *dev, struct device_node *of_node,
+ const struct zx_clk_data *data);
+
+#endif /* __DRV_CLK_ZX_H */
diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
new file mode 100644
index 000000000000..c0475d5441fb
--- /dev/null
+++ b/drivers/clk/zte/pll-zx.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+#include <linux/clk-provider.h>
+#include <linux/rational.h>
+#include <linux/device.h>
+#include <linux/regmap.h>
+#include <linux/units.h>
+#include <linux/clk.h>
+
+#include "clk-zx.h"
+
+int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
+ const struct zx_pll_desc *desc, unsigned int num,
+ struct clk_hw_onecell_data *clocks)
+{
+ return -ENODEV;
+}
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v5 09/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks
From: Stefan Dösinger @ 2026-06-28 19:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
This clock controller controls high speed devices: CPU, DMA, RAM, SDIO,
Ethernet. The only non-clock, non-reset registers I have spotted here
are hardware spinlocks.
I put the entire set of PLL generated frequencies as consumed clocks in
the binding. Due to lack of a data sheet I can't rule out that the any
of the PLL subdivions are used.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 5:
Make it an MFD child device, remove aux device
Fix zx297529 -> zx297520 typos
Fix AHB_wclk -> ahb_wclk. That was a leftover of my old composite structs
Add SRAM0 and GSM_CFG clocks
---
drivers/clk/zte/clk-zx297520v3.c | 186 +++++++++++++++++++++++++++++++++++++++
1 file changed, 186 insertions(+)
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
index bb3d64eff909..17e1f741b48c 100644
--- a/drivers/clk/zte/clk-zx297520v3.c
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -431,8 +431,194 @@ static struct platform_driver clk_zx297520v3_top = {
},
};
+static const char * const cpu_sel[] = {
+ "osc26m",
+ "mpll", /* 624 MHz */
+ "mpll_d2", /* 312 MHz */
+ "mpll_d4", /* 156 MHz */
+};
+
+static const char * const sd0_sel[] = {
+ "osc26m",
+ "mpll_d4", /* 156 MHz */
+ "gpll_d2", /* 100 MHz */
+ "mpll_d8", /* 78 MHz */
+ "gpll_d4", /* 50 MHz */
+ "gpll_d8", /* 25 MHz */
+};
+
+static const char * const sd1_sel[] = {
+ "osc26m",
+ "gpll_d2", /* 100 MHz */
+ "mpll_d8", /* 78 MHz */
+ "gpll_d4", /* 50 MHz */
+ "mpll_d16", /* 39 MHz */
+ "gpll_d8", /* 25 MHz */
+};
+
+static const char * const nand_sel[] = {
+ "mpll_d4", /* 156 MHz */
+ "osc26m",
+};
+
+static const char * const edcp_sel[] = {
+ "osc26m",
+ "mpll_d4", /* 156 MHz */
+ "mpll_d5", /* 124.8 MHz */
+ "mpll_d6", /* 104 MHz */
+};
+
+static const char * const tdm_sel[] = {
+ "osc26m",
+ "dpll_d4", /* 122.88 MHz */
+ "mpll_d6", /* 104 MHz */
+};
+
+static const struct zx_mux_desc zx297520v3_matrix_muxes[] = {
+ MUX(0, "cpu_mux", cpu_sel, 0x20, 0, 2),
+ MUX(0, "sd0_mux", sd0_sel, 0x50, 4, 3),
+ MUX(0, "sd1_mux", sd1_sel, 0x50, 8, 3),
+ MUX(0, "nand_mux", nand_sel, 0x50, 12, 2),
+ MUX(0, "edcp_mux", edcp_sel, 0x50, 16, 2),
+ MUX(0, "tdm_mux", tdm_sel, 0x50, 24, 2),
+};
+
+static const struct zx_gate_desc zx297520v3_matrix_gates[] = {
+ /* Both 0x24 and 0x28 bits 1 and 2 stop the CPU. There is also a bit in topclk+0x138, which
+ * ZTE's uboot calls "A53 reset", which also stops the CPU. I can't really tell the
+ * difference between matrix+28 and top+138. The clock (maxtrix+0x24) can be disabled and
+ * enabled from the Cortex M0 and it will nicely stop and restart the A53, retaining all
+ * state.
+ *
+ * 0x50, bits 0-3 have the DDR clock. A lot of DDR gates and resets are in 0x100.
+ */
+ GATE(ZX297520V3_CPU_WCLK, "cpu_wclk", "cpu_mux", 0x24, 1,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_CPU_PCLK, "cpu_pclk", clk_main[0], 0x24, 2,
+ CLK_IS_CRITICAL),
+
+ /* ZSP aka LTE DSP clock. I think there is a mux at matrix+0x30, but I have no idea
+ * about the frequencies it selects.
+ */
+ GATE(ZX297520V3_ZSP_WCLK, "zsp_wclk", clk_unknown[0], 0x3c, 0, 0),
+
+ GATE(ZX297520V3_SD0_WCLK, "sd0_wclk", "sd0_mux", 0x54, 12, 0),
+ GATE(ZX297520V3_SD0_PCLK, "sd0_pclk", clk_main[0], 0x54, 13, 0),
+ GATE(ZX297520V3_SD0_CDET, "sd0_cdet", "osc32k", 0x54, 14, 0),
+ GATE(ZX297520V3_SD1_WCLK, "sd1_wclk", "sd1_mux", 0x54, 4, 0),
+ GATE(ZX297520V3_SD1_PCLK, "sd1_pclk", clk_main[0], 0x54, 5, 0),
+ /* I don't know how the cdet clock works. Card detection in the way the dwc,mmc driver uses
+ * it appears broken no matter this clock's setting.
+ */
+ GATE(ZX297520V3_SD1_CDET, "sd1_cdet", "osc32k", 0x54, 6, 0),
+
+ /* This is some "denali" NAND, not the qspi connected one */
+ GATE(ZX297520V3_NAND_WCLK, "nand_wclk", "nand_mux", 0x54, 20, 0),
+ GATE(ZX297520V3_NAND_PCLK, "nand_pclk", clk_main[0], 0x54, 21, 0),
+ GATE(ZX297520V3_SSC_WCLK, "ssc_wclk", clk_unknown[0], 0x84, 1, 0),
+ GATE(ZX297520V3_SSC_PCLK, "ssc_pclk", clk_main[0], 0x84, 2, 0),
+
+ /* Yes, WCLK bit > PCLK bit for EDCP */
+ GATE(ZX297520V3_EDCP_WCLK, "edcp_wclk", "edcp_mux", 0x64, 2, 0),
+ GATE(ZX297520V3_EDCP_PCLK, "edcp_pclk", clk_main[0], 0x64, 1, 0),
+
+ /* There are a lot more VOU related controls in these registers, but turning off the main
+ * clock seems to shut off the entire VOU MMIO range.
+ */
+ GATE(ZX297520V3_VOU_WCLK, "vou_wclk", clk_unknown[0], 0x168, 0, 0),
+ GATE(ZX297520V3_VOU_PCLK, "vou_pclk", clk_main[0], 0x168, 1, 0),
+
+ /* PDCFG. Like PMM, either clock bit will allow the device to function. */
+ GATE(ZX297520V3_PDCFG_WCLK, "pdcfg_wclk", clk_unknown[0], 0x88, 0,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_PDCFG_PCLK, "pdcfg_pclk", clk_main[0], 0x88, 1,
+ CLK_IS_CRITICAL),
+
+ /* ZTE's driver has a statemt to the effect of *(top->base+0x11c) = 5, with a comment
+ * suggesting that this sets a 50 mhz clock. The clock code itself lists gmac clocks in
+ * matrix+110 and lists the parents of these clock as 50mhz gpll output, but the GMAC
+ * driver never enables the clocks. It turns out ZTE's code is highly misleading.
+ *
+ * The GMAC's work clock is definitly not any gpll output because it keeps working fine with
+ * gpll disabled. The MDIO speed is mostly unaffected by mpll speed changes, so it is most
+ * likely not fed by mpll either. All other PLLs can be disabled without breaking GMAC, so
+ * osc26m is the only possible remaining parent.
+ *
+ * The GMAC Gates are left enabled by the boot loader and are required for the GMAC to work.
+ *
+ * As for the 50 MHz comment: See rmiiphy_wclk.
+ */
+ GATE(ZX297520V3_GMAC_WCLK, "gmac_wclk", clk_main[0], 0x110, 0, 0),
+ GATE(ZX297520V3_GMAC_PCLK, "gmac_pclk", clk_main[0], 0x110, 1, 0),
+ GATE(ZX297520V3_GMAC_AHB, "gmac_ahb", "ahb_wclk", 0x110, 2, 0),
+
+ GATE(ZX297520V3_MBOX_PCLK, "mbox_pclk", clk_main[0], 0x88, 2, 0),
+ GATE(ZX297520V3_SRAM0_PCLK, "sram0_pclk", clk_main[0], 0x88, 4, 0),
+ GATE(ZX297520V3_GSM_CFG_PCLK, "gsm_cfg_pclk", clk_main[0], 0x88, 8, 0),
+ GATE(ZX297520V3_DMA_PCLK, "dma_pclk", clk_main[0], 0x94, 3, 0),
+
+ /* LSP uplink clocks. The PCLK is fairly obvious (disabling it shuts off the entire LSP
+ * register area). The WCLK speeds were deduced by setting timers and qspi muxes to a
+ * specific speed and seeing which bit in matrix+0x7c needs to be enabled for the device
+ * to work.
+ *
+ * Due to the timers I am certain about the 26mhz and 32khz clocks. I cannot directly
+ * observe the qspi mux frequency, so the clock rates depend on ZTE's qspi mux selection
+ * being correct.
+ *
+ * Two additional bits are specific to sound components - the mux for the LSP's TDM IP is
+ * in matrixclk and gets passed down. I2S has a mux in LSP, which can select the dpll_d4
+ * clock.
+ */
+ GATE(ZX297520V3_LSP_MPLL_D5_WCLK, "lsp_mpll_d5", "mpll_d5", 0x7c, 0, 0),
+ GATE(ZX297520V3_LSP_MPLL_D4_WCLK, "lsp_mpll_d4", "mpll_d4", 0x7c, 1, 0),
+ GATE(ZX297520V3_LSP_MPLL_D6_WCLK, "lsp_mpll_d6", "mpll_d6", 0x7c, 2, 0),
+ GATE(ZX297520V3_LSP_MPLL_D8_WCLK, "lsp_mpll_d8", "mpll_d8", 0x7c, 3, 0),
+ GATE(ZX297520V3_LSP_MPLL_D12_WCLK, "lsp_mpll_d12", "mpll_d12", 0x7c, 4, 0),
+ GATE(ZX297520V3_LSP_OSC26M_WCLK, "lsp_osc26m", clk_main[0], 0x7c, 5, 0),
+ GATE(ZX297520V3_LSP_OSC32K_WCLK, "lsp_osc32k", "osc32k", 0x7c, 6, 0),
+ GATE(ZX297520V3_LSP_PCLK, "lsp_pclk", clk_main[0], 0x7c, 7, 0),
+ GATE(ZX297520V3_LSP_TDM_WCLK, "lsp_tdm_wclk", "tdm_mux", 0x7c, 8, 0),
+ GATE(ZX297520V3_LSP_DPLL_D4_WCLK, "lsp_dpll_d4", "dpll_d4", 0x7c, 9, 0),
+};
+
+static const char * const zx297520v3_matrix_inputs[] = {
+ "osc26m", "osc32k",
+ "mpll", "mpll_d2", "mpll_d3", "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
+ "mpll_d16", "mpll_d26",
+ "upll", "upll_d2", "upll_d3", "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
+ "upll_d16",
+ "dpll", "dpll_d2", "dpll_d3", "dpll_d4", "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12",
+ "dpll_d16",
+ "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5", "gpll_d6", "gpll_d8", "gpll_d12",
+ "gpll_d16",
+};
+
+static const struct zx_clk_data zx297520v3_matrixclk_data = {
+ .inputs = zx297520v3_matrix_inputs,
+ .num_inputs = ARRAY_SIZE(zx297520v3_matrix_inputs),
+ .muxes = zx297520v3_matrix_muxes,
+ .num_muxes = ARRAY_SIZE(zx297520v3_matrix_muxes),
+ .gates = zx297520v3_matrix_gates,
+ .num_gates = ARRAY_SIZE(zx297520v3_matrix_gates),
+};
+
+static int zx297520v3_matrixclk_probe(struct platform_device *pdev)
+{
+ return zx_clk_common_probe(&pdev->dev, pdev->dev.parent->of_node,
+ &zx297520v3_matrixclk_data);
+}
+
+static struct platform_driver clk_zx297520v3_matrix = {
+ .probe = zx297520v3_matrixclk_probe,
+ .driver = {
+ .name = "zx297520v3-matrixclk",
+ },
+};
+
static struct platform_driver * const clk_zx297520v3_drivers[] = {
&clk_zx297520v3_top,
+ &clk_zx297520v3_matrix,
};
static int __init clk_zx297520v3_init(void)
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v5 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks
From: Stefan Dösinger @ 2026-06-28 19:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel,
Stefan Dösinger
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
This register space controls core devices: PLLs, the AHB bus, a lot of
timers, the USB controller, the Cortex M0 processor that boots the board
and a few other devices. For some reason the LTE coprocessor is also
partially controlled by it. The main application processor and DDR
memory are not found here though.
The register to reboot the board is found here, as well as a register to
control of watchdog expiries cause a board reset.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Version 5:
*) Make it a MFD child driver instead of binding to the node directly
*) Correct parents for dpll
*) Correct HSIC work clock parent
---
drivers/clk/zte/Kconfig | 11 +
drivers/clk/zte/Makefile | 1 +
drivers/clk/zte/clk-zx297520v3.c | 454 +++++++++++++++++++++++++++++++++++++++
3 files changed, 466 insertions(+)
diff --git a/drivers/clk/zte/Kconfig b/drivers/clk/zte/Kconfig
index b7b65a2172a9..12906212ec1e 100644
--- a/drivers/clk/zte/Kconfig
+++ b/drivers/clk/zte/Kconfig
@@ -15,3 +15,14 @@ config COMMON_CLK_ZTE
of this.
Enable this if you are building a kernel for a ZTE designed board.
+
+config CLK_ZTE_ZX297520V3
+ tristate "Clock driver for ZTE zx297520v3 based SoCs"
+ depends on COMMON_CLK_ZTE
+ default SOC_ZX297520V3
+ help
+ This driver supports ZTE zx297520v3 basic clocks.
+
+ Enable this if you want to build a kernel that is able to run on
+ boards based on this SoC. You can safely enable multiple clock
+ drivers. The one(s) matching the device tree will be used.
diff --git a/drivers/clk/zte/Makefile b/drivers/clk/zte/Makefile
index 27db07293165..2c073512e919 100644
--- a/drivers/clk/zte/Makefile
+++ b/drivers/clk/zte/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_COMMON_CLK_ZTE) += clk-zte.o
+obj-$(CONFIG_CLK_ZTE_ZX297520V3) += clk-zx297520v3.o
clk-zte-y += clk-zx.o pll-zx.o clk-regmap.o
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
new file mode 100644
index 000000000000..bb3d64eff909
--- /dev/null
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -0,0 +1,454 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Stefan Dösinger
+ */
+#include <dt-bindings/clock/zte,zx297520v3-clk.h>
+#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+
+#include "clk-zx.h"
+
+MODULE_IMPORT_NS("ZTE_CLK");
+
+/* Used for gates where we don't know the parent input(s). Assume general bus clock. */
+static const char * const clk_unknown[] = {
+ "osc26m",
+};
+
+/* Used for gates where we know it is using the 26 mhz main clock. */
+static const char * const clk_main[] = {
+ "osc26m",
+};
+
+static const char * const dpll_parents[] = {
+ "unknownpll_d2",
+ "osc26m",
+};
+
+static const char * const zx297520v3_top_inputs[] = {
+ "osc26m",
+ "osc32k"
+};
+
+/* Top and matrix clocks are chaotic - I haven't found a consistent pattern behind their register
+ * and bit locations. Generally there are two gates (pclk, wclk), one mux, two resets and sometimes
+ * one divider, but exceptions apply. For some devices there is only a reset and some general
+ * (parent) clocks need setup. This structure plus macro handles the somewhat regular parts.
+ *
+ * There are some patterns that can be observed.
+ * mux 0x3c, div 0x48, gate 0x54
+ * mux 0x40, div 0x4c, gate 0x5c
+ * mux 0x44, div 0x50, gate 0x60
+ *
+ * For a 0 - 0xc - 0x18 pattern. Muxes from 0x3c to 0x44, dividers from 0x48 to 0x50, gates 0x54 to
+ * 0x60. The pattern is broken for timer t17 though.
+ *
+ * Gates have 4 bits per clock - bit 0 for wclk, bit 1 for pclk, bit 2 for something the ZTE kernel
+ * calls "gate" (the bits we use here are called "en"), which I don't know what it does, and bit 3
+ * seems unused. E.g. offset 0x54 accepts all bits in 0xF77F7F7F - suggesting RTC, I2C0 have an
+ * extra gate bit.
+ *
+ * The default mpll settings multiply the 26 MHz reference clock times 24. A mux selection of 26 MHz
+ * could mean using the 26 MHz oscillator directly, or passing it through the PLL and divide by 24.
+ *
+ * If a UART is set to mpl_d6 (default 104 MHz), changing the mpll multipliers does affect UART
+ * timing as it should. This does not happen when the UART is set to 26 MHz input or timers that
+ * read 26 MHz input. This suggests 26 MHz clocks use the reference clock directly.
+ */
+
+/* AHB: The clock mux works and impact can be tested e.g. with iperf speed testing of the USB
+ * network connection. Values 2 and 3 give the same speed.
+ */
+static const char * const ahb_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+ "mpll_d8", /* 78 mhz */
+ "mpll_d8", /* 78 mhz */
+};
+
+static const char * const timer_top_sel[] = {
+ "osc32k",
+ "osc26m",
+};
+
+static const char * const uart_top_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+};
+
+/* The Cortex M0 coprocessor. It is responsible for booting the board and runs some power management
+ * helper code on the stock firmware, but isn't critical. We can run custom code on it but currently
+ * do not. These bits control the speed and the values are mentioned in ZTE's uboot. It isn't clear
+ * to me if this is directly responsible for the m0 clock, or if it is the input to another clock.
+ * Most likely it is the latter - setting it to osc32k slows down GPIO reads done on the Cortex A53
+ * a lot, although the speed of the A53 and DRAM access remains unaffected.
+ *
+ * I also haven't found a gate that shuts the m0 off and allows restarting. There don't seem to be
+ * resets either.
+ */
+static const char * const m0_sel[] = {
+ "osc26m",
+ "mpll_d6", /* 104 mhz */
+ "mpll_d8", /* 78 mhz */
+ "osc32k", /* Yes, tested. It is SLLLLOOOOOWWW. */
+};
+
+/* Clk_out0/1/2/32k: These clocks are exposed on GPIOs 15, 16, 17 and 18 respectively. They are used
+ * in ZTE's camera and sound code, by directly poking into the clock registers from the device
+ * drivers. Until the respective devices are supported they can safely be switched off.
+ *
+ * For clk_out1 ZTE's camera code says the following:
+ *
+ * 0 -> 20 MHz
+ * 1 -> 40 MHz
+ * 2 -> 13 MHz
+ * 3 -> 26 MHz
+ *
+ * 0 and 1 read from upll. I confirmed their rates (upll_d24 and upll_d12) by setting upll to a very
+ * low frequency and sampling the clock by GPIO reads. The outputs of 2 and 3 are way too high to
+ * test that way. Both are not reading from any PLL. I am fairly sure that 3 is just direct osc26m
+ * because it perfectly matches what out2 is showing in its 26 MHz setting. Setting 2 is an enigma.
+ * It is not from any PLL (disable postdiv_out on all of them and the clock will keep oscillating).
+ *
+ * Probably the best way us to model this as a mux (bit 7) and divider (bit 6), but since this is
+ * not a plain val+1 divider like the rest of the divs I am leaving the divider out until an actual
+ * hardware user is found. It would need support for divider tables or flags in the regmap div
+ * clocks.
+ *
+ * Clk_out2 is similar, but it has only one control bit in top 0x34 bit 8. Neither setting selects
+ * a PLL output. When setting *0x34 = 0x080, clk_out1 and clk_out2 are in lockstep, presumably
+ * running at 13 MHz (clk_out1 mux select 26m, both have their divider set to 2). 0x1c0 also runs in
+ * lockstep (clk_out1 select 26m, both div 1).
+ *
+ * clk_out0 has a mux in bit 5. Value 0 most likely selects osc26m. I am not entirely sure about
+ * value 1 (which is the default), but the m0 mux has an impact on it. It looks like a debug pin
+ * that exposes some core clock.
+ */
+
+static const char * const out0_sel[] = {
+ "osc26m",
+ "m0_wclk",
+};
+
+static const char * const out1_sel[] = {
+ "upll_d12", /* 40 MHz */
+ "osc26m",
+};
+
+/* Clk_o is similar to clk_out*, providing a clock on GPIO 20, presumably for driving a (R)MII phy.
+ * The 50 MHz value is documented in a stray comment in ZTE's GMAC driver. I tested it similarly to
+ * the above pins. Mux setting 0 gives half the count as setting 1 and setting 1 gives gpll divided
+ * by 4 - matching the 50 MHz suggested by the ZTE comment at the default gpll settings. Gating gpll
+ * stops the clock for values 0 and 1.
+ *
+ * Settings 2 and 3 are possible, but seem to return garbage. It is generally pulsing up and down,
+ * except if both gpll and upll are stopped. I suspect it just reads random electrical fluctuation
+ * from other places in the board. Yes, I had a pull-down enabled when testing this.
+ *
+ * This could also be a case of mux + inverse div, but since the settings we might possibly need are
+ * standard gpll outputs just model it as a mux.
+ *
+ * I am not aware of any board that uses this though. The Ethernet equipped ones I have all run the
+ * phy with its own oscillator.
+ */
+static const char * const rmii_sel[] = {
+ "gpll_d8", /* 25 MHz */
+ "gpll_d4", /* 50 MHz */
+};
+
+static const unsigned int mpll_postdivs[] = {1, 2, 3, 4, 5, 6, 8, 12, 16, 26};
+static const unsigned int pll_postdivs[] = {1, 2, 3, 4, 5, 6, 8, 12, 16};
+static const unsigned int unknownpll_postdivs[] = {2};
+
+static const struct zx_pll_desc zx297520v3_plls[] = {
+ /* Default setting: 0x48040c11. 624/312/156. Only a single possible parent. This is the
+ * PLL for pretty much everything, including CPU, RAM and USB.
+ *
+ * Changing this PLL makes it possible to overclock the CPU or do more fine grained
+ * underclocking than the CPU's mux allows. It does run into two problems though: The USB
+ * device uses this PLL's output directly and is *very* sensitive to differences. DRAM
+ * is also fed by this clock and needs to be re-trained on larger changes, which needs to
+ * be done by the stage 1 boot loader.
+ */
+ {
+ .id = ZX297520V3_MPLL,
+ .name = "mpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = mpll_postdivs,
+ .num_postdivs = ARRAY_SIZE(mpll_postdivs),
+ .reg = 0x8
+ },
+
+ /* ZTE's code calls this PLL "upll". The only possible consumers I found are clk_out1,
+ * which outputs this clock on GPIO 16 and HSIC. HSIC doesn't have anything connected to
+ * it on the devices I tested. The device that consumes clk_out1 seems to be an SPI
+ * camera, which I haven't seen in any device so far.
+ *
+ * Long story short, shut it off.
+ */
+ {
+ .id = ZX297520V3_UPLL,
+ .name = "upll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x10,
+ },
+
+ /* Default value 0x4834902d. Feeds dpll. 46.08 MHz. Bit 25 can be set, so two parents are
+ * possible. It looks like both values select the 26 MHz oscillator though.
+ */
+ {
+ .id = 0,
+ .name = "unknownpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = unknownpll_postdivs,
+ .num_postdivs = ARRAY_SIZE(unknownpll_postdivs),
+ .reg = 0x100,
+ },
+
+ /* The documentation says 491.52 MHz and measurement with the LSP TDM device supports this.
+ * The default value is 0x480c2011, but not all boot loaders set it up. To get to 491.52
+ * with these settings it needs a 23.04 MHz reference clock, which matches unknownpll_d2.
+ * If unknownpll is disabled, dpll loses its lock. We set the frequency on this PLL if we
+ * find it is not enabled by the boot loader.
+ *
+ * The proprietary LTE driver or coproc enables and disables it. TDM and I2S can use it.
+ *
+ * It accepts parent values 0, 1, 2 and 3. Parent 0 is unknownpll_d2. The others look like
+ * osc26m. With a parent != 0 dpll never loses its lock even when all other PLLs are off
+ * and the TDM counter register increases at a rate consistent with a 26.0/23.04 clock
+ * increase.
+ */
+ {
+ .id = ZX297520V3_DPLL,
+ .name = "dpll",
+ .parents = dpll_parents,
+ .num_parents = ARRAY_SIZE(dpll_parents),
+ .rate = 491520000,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x18,
+ },
+
+ /* "g" is either for "general" or "gigahertz". The VCO runs at 1GHz. Output clocks are 200,
+ * 100, 50, 25, ... MHz. It is used optionally by SDIO and QSPI and can drive a GPIO clock
+ * output for RMII, so it doesn't seem very general.
+ */
+ {
+ .id = ZX297520V3_GPLL,
+ .name = "gpll",
+ .parents = clk_main,
+ .num_parents = ARRAY_SIZE(clk_main),
+ .rate = 0,
+ .postdivs = pll_postdivs,
+ .num_postdivs = ARRAY_SIZE(pll_postdivs),
+ .reg = 0x110,
+ },
+};
+
+#define MUX(_id, _name, _parents, _reg, _shift, _size) { \
+ _id, _name, _parents, ARRAY_SIZE(_parents), _reg, _shift, _size}
+
+#define DIV(_id, _name, _parent, _reg, _shift, _size) { _id, _name, _parent, _reg, _shift, _size }
+
+#define GATE(_id, _name, _parent, _reg, _shift, _flags) { \
+ .id = _id, \
+ .name = _name, \
+ .parent = _parent, \
+ .flags = _flags, \
+ .reg = _reg, \
+ .shift = _shift, \
+}
+
+static const struct zx_mux_desc zx297520v3_top_muxes[] = {
+ MUX(ZX297520V3_M0_WCLK, "m0_wclk", m0_sel, 0x38, 0, 2),
+ MUX(0, "ahb_mux", ahb_sel, 0x3c, 4, 2),
+ MUX(0, "timer_t08_mux", timer_top_sel, 0x40, 1, 1),
+ MUX(0, "timer_t09_mux", timer_top_sel, 0x40, 0, 1),
+ MUX(0, "timer_t12_mux", timer_top_sel, 0x3c, 0, 1),
+ MUX(0, "timer_t13_mux", timer_top_sel, 0x44, 0, 1),
+ MUX(0, "timer_t14_mux", timer_top_sel, 0x44, 1, 1),
+ MUX(0, "timer_t15_mux", timer_top_sel, 0x3c, 3, 1),
+ MUX(0, "timer_t16_mux", timer_top_sel, 0x44, 2, 1),
+ MUX(0, "timer_t17_mux", timer_top_sel, 0x120, 0, 1),
+ MUX(0, "wdt_t18_mux", timer_top_sel, 0x3c, 6, 1),
+ MUX(0, "i2c0_mux", uart_top_sel, 0x3c, 1, 1),
+ MUX(0, "uart0_mux", uart_top_sel, 0x40, 2, 1),
+ MUX(0, "out0_mux", out0_sel, 0x34, 5, 1),
+ MUX(0, "out1_mux", out1_sel, 0x34, 7, 1),
+ MUX(0, "rmiiphy_mux", rmii_sel, 0x11c, 0, 2),
+};
+
+static const struct zx_div_desc zx297520v3_top_dividers[] = {
+ DIV(0, "timer_t08_div", "timer_t08_mux", 0x4c, 8, 4),
+ DIV(0, "timer_t09_div", "timer_t09_mux", 0x4c, 0, 4),
+ DIV(0, "timer_t12_div", "timer_t12_mux", 0x48, 0, 4),
+ DIV(0, "timer_t13_div", "timer_t13_mux", 0x50, 0, 4),
+ DIV(0, "timer_t14_div", "timer_t14_mux", 0x50, 4, 4),
+ DIV(0, "timer_t15_div", "timer_t15_mux", 0x48, 4, 4),
+ DIV(0, "timer_t16_div", "timer_t16_mux", 0x50, 8, 4),
+ DIV(0, "timer_t17_div", "timer_t17_mux", 0x124, 0, 4),
+ DIV(0, "wdt_t18_div", "wdt_t18_mux", 0x48, 8, 4),
+ DIV(0, "usim1_div", clk_main[0], 0x48, 12, 1),
+};
+
+static const struct zx_gate_desc zx297520v3_top_gates[] = {
+ /* Turning off this clock crashes the device. */
+ GATE(ZX297520V3_AHB_WCLK, "ahb_wclk", "ahb_mux", 0x54, 12,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_AHB_PCLK, "ahb_pclk", clk_main[0], 0x54, 13,
+ CLK_IS_CRITICAL),
+
+ /* SRAM1 and 2 clocks. Leave them on for now, as turning them off carelessly hangs the M0 */
+ GATE(ZX297520V3_SRAM1_PCLK, "sram1_pclk", clk_main[0], 0x54, 18,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_SRAM2_PCLK, "sram2_pclk", clk_main[0], 0x54, 16,
+ CLK_IS_CRITICAL),
+
+ /* Pinmux (AON, TOP, IOCFG but not PDCFG). Critical as well until we have a driver that
+ * consumes it. I don't think we'll realistically shut this off ever.
+ *
+ * Setting either bit 0 or 1 in register 0x58 makes the device work.
+ */
+ GATE(ZX297520V3_PMM_WCLK, "pmm_wclk", clk_main[0], 0x58, 0,
+ CLK_IS_CRITICAL),
+ GATE(ZX297520V3_PMM_PCLK, "pmm_pclk", clk_main[0], 0x58, 1,
+ CLK_IS_CRITICAL),
+
+ /* Timers. We don't use any of them, just shut them off. The timers are named and sorted
+ * by the IO address of the main timer controls. Some of the controls are documented in
+ * ZTE's kernel, the others I found by trial and error.
+ *
+ * Timer T17 is used by the ZSP firmware. The rproc driver will enable it as needed.
+ */
+ GATE(ZX297520V3_TIMER_T08_WCLK, "timer_t08_wclk", "timer_t08_div", 0x5c, 8, 0),
+ GATE(ZX297520V3_TIMER_T08_PCLK, "timer_t08_pclk", clk_main[0], 0x5c, 9, 0),
+ GATE(ZX297520V3_TIMER_T09_WCLK, "timer_t09_wclk", "timer_t09_div", 0x5c, 4, 0),
+ GATE(ZX297520V3_TIMER_T09_PCLK, "timer_t09_pclk", clk_main[0], 0x5c, 5, 0),
+ GATE(ZX297520V3_TIMER_T12_WCLK, "timer_t12_wclk", "timer_t12_div", 0x54, 4, 0),
+ GATE(ZX297520V3_TIMER_T12_PCLK, "timer_t12_pclk", clk_main[0], 0x54, 5, 0),
+ GATE(ZX297520V3_TIMER_T13_WCLK, "timer_t13_wclk", "timer_t13_div", 0x60, 0, 0),
+ GATE(ZX297520V3_TIMER_T13_PCLK, "timer_t13_pclk", clk_main[0], 0x60, 1, 0),
+ GATE(ZX297520V3_TIMER_T14_WCLK, "timer_t14_wclk", "timer_t14_div", 0x60, 4, 0),
+ GATE(ZX297520V3_TIMER_T14_PCLK, "timer_t14_pclk", clk_main[0], 0x60, 5, 0),
+ GATE(ZX297520V3_TIMER_T15_WCLK, "timer_t15_wclk", "timer_t15_div", 0x54, 20, 0),
+ GATE(ZX297520V3_TIMER_T15_PCLK, "timer_t15_pclk", clk_main[0], 0x54, 21, 0),
+ GATE(ZX297520V3_TIMER_T16_WCLK, "timer_t16_wclk", "timer_t16_div", 0x60, 8, 0),
+ GATE(ZX297520V3_TIMER_T16_PCLK, "timer_t16_pclk", clk_main[0], 0x60, 9, 0),
+ GATE(ZX297520V3_TIMER_T17_WCLK, "timer_t17_wclk", "timer_t17_div", 0x128, 0, 0),
+ GATE(ZX297520V3_TIMER_T17_PCLK, "timer_t17_pclk", clk_main[0], 0x128, 1, 0),
+ /* This watchdog is set up by the bootloader and in normal operation the m0 firmware will
+ * feed the dog. The m0 firmware in turn wants to be fed in its own way. Since we normally
+ * don't run any m0 firmware we shut it off by default and expose it to userspace via the
+ * watchdog driver.
+ */
+ GATE(ZX297520V3_WDT_T18_WCLK, "wdt_t18_wclk", "wdt_t18_div", 0x54, 24, 0),
+ GATE(ZX297520V3_WDT_T18_PCLK, "wdt_t18_pclk", clk_main[0], 0x54, 25, 0),
+
+ GATE(ZX297520V3_I2C0_WCLK, "i2c0_wclk", "i2c0_mux", 0x54, 8, 0),
+ GATE(ZX297520V3_I2C0_PCLK, "i2c0_pclk", clk_main[0], 0x54, 9, 0),
+ GATE(ZX297520V3_UART0_WCLK, "uart0_wclk", "uart0_mux", 0x5c, 12, 0),
+ GATE(ZX297520V3_UART0_PCLK, "uart0_pclk", clk_main[0], 0x5c, 13, 0),
+
+ /* ZTE says the USB input is a 24 MHz clock based on mpll. Testing shows that Upll is not
+ * involved. The USB register space can be accessed with ahb_pclk gated, but not with
+ * ahb_wclk gated. ZTE also lists ahb_wclk as parent for the second clock.
+ *
+ * There doesn't seem to be a separate PHY clock. usb_wclk stops controller registers from
+ * updating, but doesn't cause the USB device to disconnect like asserting the PHY reset
+ * does. Bit 0 in this register can't be set, so no PHY clock is hiding there either.
+ */
+ GATE(ZX297520V3_USB_WCLK, "usb_wclk", "mpll_d26", 0x6c, 3, 0),
+ GATE(ZX297520V3_USB_PCLK, "usb_pclk", "ahb_wclk", 0x6c, 4, 0),
+ /* The HSIC hardware is listed in ZTE's code with a physical address of 0x01600000. Unlike
+ * the USB controller, it does consume upll, presumably upll_d2 for 240 MHz.
+ */
+ GATE(ZX297520V3_HSIC_WCLK, "hsic_wclk", "upll_d2", 0x6c, 1, 0),
+ GATE(ZX297520V3_HSIC_PCLK, "hsic_pclk", "ahb_wclk", 0x6c, 2, 0),
+
+ /* How does this RTC work? I don't know, the ZTE kernel does not talk to it. The actual RTC
+ * is on the I2C connected PMIC.
+ */
+ GATE(ZX297520V3_RTC_WCLK, "rtc_wclk", clk_unknown[0], 0x54, 0, 0),
+ GATE(ZX297520V3_RTC_PCLK, "rtc_pclk", clk_main[0], 0x54, 1, 0),
+
+ GATE(ZX297520V3_USIM1_WCLK, "usim1_wclk", "usim1_div", 0x54, 28, 0),
+ GATE(ZX297520V3_USIM1_PCLK, "usim1_pclk", clk_main[0], 0x54, 29, 0),
+
+ /* LTE: gate only as far as I can see. I looked for resets and did not find any. There may
+ * be mux/div, but without understanding the behavior of this hardware it is impossible to
+ * tell. They are sorted by physical MMIO address of the devices, which happens to be the
+ * inverse order of the bits.
+ *
+ * I don't know what "LPM", "TD" and "W" mean. I copied them from ZTE's names.
+ */
+ GATE(ZX297520V3_LPM_GSM_WCLK, "lpm_gsm_wclk", clk_unknown[0], 0x58, 10, 0),
+ GATE(ZX297520V3_LPM_GSM_PCLK, "lpm_gsm_pclk", clk_unknown[0], 0x58, 11, 0),
+ GATE(ZX297520V3_LPM_LTE_WCLK, "lpm_lte_wclk", clk_unknown[0], 0x58, 8, 0),
+ GATE(ZX297520V3_LPM_LTE_PCLK, "lpm_lte_pclk", clk_unknown[0], 0x58, 9, 0),
+ GATE(ZX297520V3_LPM_TD_WCLK, "lpm_td_wclk", clk_unknown[0], 0x58, 6, 0),
+ GATE(ZX297520V3_LPM_TD_PCLK, "lpm_td_pclk", clk_unknown[0], 0x58, 7, 0),
+ GATE(ZX297520V3_LPM_W_WCLK, "lpm_w_wclk", clk_unknown[0], 0x58, 4, 0),
+ GATE(ZX297520V3_LPM_W_PCLK, "lpm_w_pclk", clk_unknown[0], 0x58, 5, 0),
+
+ GATE(ZX297520V3_OUT0_WCLK, "out0_wclk", "out0_mux", 0x34, 0, 0),
+ GATE(ZX297520V3_OUT1_WCLK, "out1_wclk", "out1_mux", 0x90, 2, 0),
+ GATE(ZX297520V3_OUT2_WCLK, "out2_wclk", clk_main[0], 0x94, 2, 0),
+ GATE(ZX297520V3_OUT32K_WCLK, "out32k_wclk", "osc32k", 0x34, 1, 0),
+ GATE(ZX297520V3_RMIIPHY_WCLK, "rmiiphy_wclk", "rmiiphy_mux", 0x11c, 2, 0),
+};
+
+static const struct zx_clk_data zx297520v3_topclk_data = {
+ .inputs = zx297520v3_top_inputs,
+ .num_inputs = ARRAY_SIZE(zx297520v3_top_inputs),
+ .plls = zx297520v3_plls,
+ .num_plls = ARRAY_SIZE(zx297520v3_plls),
+ .muxes = zx297520v3_top_muxes,
+ .num_muxes = ARRAY_SIZE(zx297520v3_top_muxes),
+ .divs = zx297520v3_top_dividers,
+ .num_divs = ARRAY_SIZE(zx297520v3_top_dividers),
+ .gates = zx297520v3_top_gates,
+ .num_gates = ARRAY_SIZE(zx297520v3_top_gates),
+};
+
+static int zx297520v3_topclk_probe(struct platform_device *pdev)
+{
+ return zx_clk_common_probe(&pdev->dev, pdev->dev.parent->of_node, &zx297520v3_topclk_data);
+}
+
+static struct platform_driver clk_zx297520v3_top = {
+ .probe = zx297520v3_topclk_probe,
+ .driver = {
+ .name = "zx297520v3-topclk",
+ },
+};
+
+static struct platform_driver * const clk_zx297520v3_drivers[] = {
+ &clk_zx297520v3_top,
+};
+
+static int __init clk_zx297520v3_init(void)
+{
+ return platform_register_drivers(clk_zx297520v3_drivers,
+ ARRAY_SIZE(clk_zx297520v3_drivers));
+}
+
+static void __exit clk_zx297520v3_exit(void)
+{
+ platform_unregister_drivers(clk_zx297520v3_drivers, ARRAY_SIZE(clk_zx297520v3_drivers));
+}
+
+module_init(clk_zx297520v3_init);
+module_exit(clk_zx297520v3_exit);
+
+MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
+MODULE_DESCRIPTION("ZTE zx297520v3 clock driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Add Radhey Shyam Pandey as ZynqMP PHY maintainer
From: Laurent Pinchart @ 2026-06-28 21:12 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: tomi.valkeinen, vkoul, michal.simek, linux-kernel, linux-phy,
linux-arm-kernel
In-Reply-To: <20260627162233.2803425-1-radhey.shyam.pandey@amd.com>
On Sat, Jun 27, 2026 at 09:52:33PM +0530, Radhey Shyam Pandey wrote:
> I am maintaining phy-zynqmp driver in xilinx tree and would like to
> maintain it in the mainline kernel as well. Hence adding myself as a
> maintainer.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thank you for volunteering.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1705eb823dd0..90dd86437c5c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -29645,6 +29645,7 @@ F: drivers/edac/zynqmp_edac.c
>
> XILINX ZYNQMP PSGTR PHY DRIVER
> M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> +M: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> L: linux-kernel@vger.kernel.org
> S: Supported
> T: git https://github.com/Xilinx/linux-xlnx.git
>
> base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: am62p5-var-som-symphony: add TPM support
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the ST33KTPM2XI2C TPM device on the Symphony carrier board.
The TPM reset signal is driven through a PCAL6408 GPIO expander, so add
the corresponding GPIO expander node. Configure the RGB_SEL board signal
through a GPIO hog to keep the board in the expected configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
.../dts/ti/k3-am62p5-var-som-symphony.dts | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
index 5c41647ff43f..8fe8ec903d3d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
@@ -293,6 +293,28 @@ &main_i2c1 {
clock-frequency = <400000>;
status = "okay";
+ pcal6408: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds_brg_en";
+ };
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ label = "tpm";
+ reg = <0x2e>;
+ reset-gpios = <&pcal6408 4 GPIO_ACTIVE_LOW>;
+ };
+
/* Capacitive touch controller */
ft5x06_ts: touchscreen@38 {
compatible = "edt,edt-ft5206";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/4] arm64: dts: ti: var-som-am62p: fix Ethernet PHY configuration
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Fix the Ethernet device tree description on the VAR-SOM-AM62P.
Enable the CPSW Ethernet controller and correct the Ethernet PHY
description by modelling the PHY power supply and adding the required
board-specific PHY properties.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Remove unused eth property
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
index fc5a3942cde0..ca2483a04b9d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
@@ -113,6 +113,15 @@ reg_3v3_phy: regulator-3v3-phy {
regulator-always-on;
};
+ reg_eth_phy_vdd: regulator-eth-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "reg_eth_phy_vdd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&main_gpio0 46 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,bitclock-master = <&codec_dai>;
@@ -149,6 +158,7 @@ &audio_refclk1 {
&cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgmii1>;
+ status = "okay";
};
&cpsw3g_mdio {
@@ -159,9 +169,9 @@ &cpsw3g_mdio {
cpsw3g_phy0: ethernet-phy@4 {
compatible = "ethernet-phy-id0283.bc30";
reg = <4>;
- reset-gpios = <&main_gpio0 46 GPIO_ACTIVE_LOW>;
- reset-assert-us = <10000>;
- reset-deassert-us = <100000>;
+ bootph-all;
+ enet-phy-lane-no-swap;
+ vdd-supply = <®_eth_phy_vdd>;
};
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: ti: var-som-am62p: update audio codec configuration
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Update the WM8904 audio codec configuration on the VAR-SOM-AM62P.
Set the audio reference clock rate to 12 MHz and add the codec DRC, GPIO
and DMIC configuration required by the board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Remove wrong dmic property
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
index ca2483a04b9d..8a8dec80cb30 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
@@ -152,7 +152,7 @@ simple-audio-card,cpu {
};
&audio_refclk1 {
- assigned-clock-rates = <100000000>;
+ assigned-clock-rates = <12000000>;
};
&cpsw3g {
@@ -203,6 +203,23 @@ wm8904: audio-codec@1a {
DBVDD-supply = <®_3v3>;
DCVDD-supply = <®_1v8>;
MICVDD-supply = <®_1v8>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
};
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/4] arm64: dts: am62p5-var-som-symphony: align DTS with hardware revision
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
This series updates the device tree description for the Variscite
VAR-SOM-AM62P and Symphony carrier board to better reflect the current
board configuration.
It aligns the Ethernet PHY description, updates the audio codec
configuration, and adds the touchscreen and TPM devices together with
their required board-level resources.
v1->v2:
- Remove unused eth property
- Remove wrong dmic property
- Fix commit message
Stefano Radaelli (4):
arm64: dts: ti: var-som-am62p: fix Ethernet PHY configuration
arm64: dts: ti: var-som-am62p: update audio codec configuration
arm64: dts: am62p5-var-som-symphony: add touchscreen support
arm64: dts: am62p5-var-som-symphony: add TPM support
.../dts/ti/k3-am62p5-var-som-symphony.dts | 43 +++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 35 +++++++++++++--
2 files changed, 74 insertions(+), 4 deletions(-)
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
2.47.3
^ 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