* Re: [PATCH v3 2/5] media: hi846: fix link frequency handling
From: Markus Elfring @ 2026-05-11 10:42 UTC (permalink / raw)
To: Pengyu Luo, linux-media, devicetree, linux-arm-kernel, imx,
kernel, Conor Dooley, Fabio Estevam, Frank Li, Hans Verkuil,
Krzysztof Kozlowski, Martin Kepplinger-Novakovic,
Mauro Carvalho Chehab, Rob Herring, Sakari Ailus, Sascha Hauer,
Sebastian Krzyszkowiak
Cc: LKML
In-Reply-To: <20260511090924.269106-3-mitltlatltl@gmail.com>
…
> configuration. To implement this, this commit did
…
See also once more:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.1-rc3#n94
Regards,
Markus
^ permalink raw reply
* [PATCH] rtc: msc313: fix NULL deref in shared IRQ handler at probe
From: Stepan Ionichev @ 2026-05-11 3:27 UTC (permalink / raw)
To: alexandre.belloni
Cc: daniel, romain.perier, linux-arm-kernel, linux-rtc, linux-kernel,
sozdayvek
msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and
&pdev->dev as the cookie, but platform_set_drvdata() is only called
later after the clock setup. With a shared IRQ line, another device
on the same line can trigger the handler in that window. The
handler does dev_get_drvdata() on the cookie, gets NULL, and
dereferences priv->rtc_base in interrupt context.
Pass priv as the cookie directly so the handler reads it from
dev_id without the lookup, removing the dependency on probe order.
Fixes: be7d9c9161b9 ("rtc: Add support for the MSTAR MSC313 RTC")
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
---
drivers/rtc/rtc-msc313.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-msc313.c b/drivers/rtc/rtc-msc313.c
index 8d7737e0e..6ef9c4efd 100644
--- a/drivers/rtc/rtc-msc313.c
+++ b/drivers/rtc/rtc-msc313.c
@@ -160,7 +160,7 @@ static const struct rtc_class_ops msc313_rtc_ops = {
static irqreturn_t msc313_rtc_interrupt(s32 irq, void *dev_id)
{
- struct msc313_rtc *priv = dev_get_drvdata(dev_id);
+ struct msc313_rtc *priv = dev_id;
u16 reg;
reg = readw(priv->rtc_base + REG_RTC_STATUS_INT);
@@ -206,7 +206,7 @@ static int msc313_rtc_probe(struct platform_device *pdev)
priv->rtc_dev->range_max = U32_MAX;
ret = devm_request_irq(dev, irq, msc313_rtc_interrupt, IRQF_SHARED,
- dev_name(&pdev->dev), &pdev->dev);
+ dev_name(&pdev->dev), priv);
if (ret) {
dev_err(dev, "Could not request IRQ\n");
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v10 01/30] arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06
From: Mark Rutland @ 2026-05-11 10:40 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <af6DH_j7pyEm4HyI@sirena.co.uk>
On Sat, May 09, 2026 at 09:43:11AM +0900, Mark Brown wrote:
> On Fri, May 08, 2026 at 06:12:01PM +0100, Mark Rutland wrote:
> > On Fri, Mar 06, 2026 at 05:00:53PM +0000, Mark Brown wrote:
>
> > > Update the definition of SMIDR_EL1 in the sysreg definition to reflect the
> > > information in DD0601 2025-06. This includes somewhat more generic ways of
> > > describing the sharing of SMCUs, more information on supported priorities
> > > and provides additional resolution for describing affinity groups.
>
> > FWIW, these are all in ARM DDI 0487 M.b:
>
> > https://developer.arm.com/documentation/ddi0487/mb/
>
> > Is anything later in the series going to depend on these fields, or
> > would everything behave correctly with the existing RES0 field
> > definitions?
>
> We're exposing the affinity fields so there's a build time issue.
What I'm asking is what is the rationale for updating these definitions?
e.g.
* Are we planning to use any of the fields in a specific way in the
*host*?
* Are we planning to use any of the fields in a specific way in the
*guest*?
* Is this updated just out of habit?
Knowing the rationale would help with review, even if that rationale is
just "it seemed nice to use the latest".
> > > +Field 55:52 HIP
>
> > Reading the ARM ARM, HIP is arguably a backwards-incompatible change.
>
> Yes, I belive people are aware.
Ok. Is that considered a problem, or accepted?
Which people are aware?
> > Do we expect to expose that to VMs, or just hide priorities entirely? I
> > suspect we probably want to require that the guest sees
> > SMIDR_EL1.SMPS==0, and not care about any of that.
>
> Currently we're not exposing priority support to guests so we don't need
> to worry about it yet.
Do we plan to in future?
Mark.
^ permalink raw reply
* Re: [PATCH 7/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
From: Pranjal Shrivastava @ 2026-05-11 10:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <20260509165401.GL9254@nvidia.com>
On Sat, May 09, 2026 at 01:54:01PM -0300, Jason Gunthorpe wrote:
> On Fri, May 08, 2026 at 11:46:39AM +0000, Pranjal Shrivastava wrote:
> > On Fri, May 01, 2026 at 11:29:16AM -0300, Jason Gunthorpe wrote:
> > > Add a new command make function and convert all the places using
> > > ATC_INV.
> > >
> > > Split out full invalidation to directly make the cmd instead of
> > > overloading size=0 to mean full invalidation.
> > >
> > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > > ---
> >
> > Nit: I guess it's worth mentioning that we remove CMDQ_ATC_0_GLOBAL as
> > we don't set ent->atc.global = true anywhere in the driver anymore.
>
> I added this:
>
> In section "3.9.1 ATS Interface" of F.b the specification says:
>
> When the SMMU returns an ATS Translation Completion for a request that
> had a PASID, the Global bit of the Translation Completion Data Entry
> must be zero.
>
> Even though it faithfully forwards the G bit through to the ATS
> invalidation command there is no way to create G mappings so there is
> never any need to send a G invalidation. Thus don't expose global in the
> new helpers and leave CMDQ_ATC_0_GLOBAL unused.
Ack. Sounds good. Should also add that the only other place we might need
G=1 is for a full ATC wipe. However, we don't since the PCIe Spec 10.3.8,
mentions issuing an invalidation without a PASID prefix (SSV=0) already
forces the device to invalidate all ATC entries for any PASID at all
addresses, e.g. arm_smmu_atc_inv_master(master, IOMMU_NO_PASID).
Although the comment in arm_smmu_enable_ats should suffice too.
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v10 04/30] arm64/fpsimd: Determine maximum virtualisable SME vector length
From: Mark Rutland @ 2026-05-11 10:32 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-4-43f7683a0fb7@kernel.org>
On Fri, Mar 06, 2026 at 05:00:56PM +0000, Mark Brown wrote:
> As with SVE we can only virtualise SME vector lengths that are supported by
> all CPUs in the system, implement similar checks to those for SVE.
So far so good.
> Since unlike SVE there are no specific vector lengths that are
> architecturally required the handling is subtly different, we report a
> system where this happens with a maximum vector length of
> SME_VQ_INVALID.
I think something went wrong during copyediting here.
A system where *what* happens?
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/fpsimd.h | 2 ++
> arch/arm64/kernel/fpsimd.c | 21 ++++++++++++++++++++-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index e97729aa3b2f..0cd8a866e844 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -69,6 +69,8 @@ static inline void cpacr_restore(unsigned long cpacr)
> #define ARCH_SVE_VQ_MAX ((ZCR_ELx_LEN_MASK >> ZCR_ELx_LEN_SHIFT) + 1)
> #define SME_VQ_MAX ((SMCR_ELx_LEN_MASK >> SMCR_ELx_LEN_SHIFT) + 1)
>
> +#define SME_VQ_INVALID (SME_VQ_MAX + 1)
Does using (SME_VQ_MAX + 1) for this make something easier than if we
used 0?
My thinking is that 0 will be easier/clearer overall, since we can write
checks of the form:
if (!info->max_virtualisable_vl) {
/* SME is not virtualisable */
}
... or:
if (some_vl <= max_virtualisable_vl) {
/* Check properties of a virtualisable VL */
}
... and there's less scope for error.
> +
> struct task_struct;
>
> extern void fpsimd_save_state(struct user_fpsimd_state *state);
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 2af0e0c5b9f4..49c050ef6db9 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -1218,7 +1218,8 @@ void cpu_enable_sme(const struct arm64_cpu_capabilities *__always_unused p)
> void __init sme_setup(void)
> {
> struct vl_info *info = &vl_info[ARM64_VEC_SME];
> - int min_bit, max_bit;
> + DECLARE_BITMAP(tmp_map, SVE_VQ_MAX);
> + int min_bit, max_bit, b;
>
> if (!system_supports_sme())
> return;
> @@ -1249,12 +1250,30 @@ void __init sme_setup(void)
> */
> set_sme_default_vl(find_supported_vector_length(ARM64_VEC_SME, 32));
>
> + bitmap_andnot(tmp_map, info->vq_partial_map, info->vq_map,
> + SVE_VQ_MAX);
> +
> + b = find_last_bit(tmp_map, SVE_VQ_MAX);
> + if (b >= SVE_VQ_MAX)
> + /* All VLs virtualisable */
> + info->max_virtualisable_vl = sve_vl_from_vq(ARCH_SVE_VQ_MAX);
I don't think this is right.
This test tells us that all VLs implemented by boot CPUs are
virtualisable. That set of VLs doesn't necessarily include the
architectural maximum VL.
IIUC that's not a problem for KVM, since KVM enforces that a guest's
maximum VL is an implemented VL. However, this is a problem for
vec_verify_vq_map().
Consider the case where all boot CPUs support only 128-bit, but later we
try to online a CPU that supports 128-bit and 256-bit. That CPU will be
rejected by vec_verify_vq_map().
Note that this isn't broken for SVE today as sve_setup() follows this up
with:
if (info->max_virtualisable_vl > info->max_vl)
info->max_virtualisable_vl = info->max_vl;
... but that won't be sufficient for streaming mode VLs given there's no
guarantee that smaller streaming VLs are implemented.
> + else if (b == SVE_VQ_MAX - 1)
> + /* No virtualisable VLs */
> + info->max_virtualisable_vl = sve_vl_from_vq(SME_VQ_INVALID);
Similarly, I think this is broken for vec_verify_vq_map(). Consider a
case with two boot CPUs, where one boot CPU only supports 128-bit, and
the other boot cpu only supports 256-bit. If either CPU is hotplugged
out and then back in, it will be rejected by vec_verify_vq_map().
We don't have a similar problem for SVE since that's not architecturally
possible.
> + else
> + info->max_virtualisable_vl = sve_vl_from_vq(__bit_to_vq(b + 1));
This looks suspicious.
At this point we know that 'b' represents the smallest VL which is
partially supported. The next bit is almost never a power of two, is not
guaranteed to be an implemented VL, and is not guaranteed to be larger
than an implemented VL.
Imagine you have two CPUs:
* CPU x supports 128-bit.
* CPU y supports 128-bit and 512-bit.
The algorithm above will find 512-bit as the smallest partically
supported VL. For that, VQ==4 and b==12.
If max_virtualisable_vl is chosen as b+1, then that's b==13 and VQ==3,
which corresponds to a (not architecturally supported) 384-bit VL, which
is bigger than the architecturally-valid 256 bit VL that neither CPU
supports.
As with the other cases above, that's broken for vec_verify_vq_map(),
but I think KVM will gracefully handle this.
To solve all of the above, I think what we actually want to do is find
the largest uniformly implemented VL which is smaller than the smallest
partially implemented VL.
> pr_info("SME: minimum available vector length %u bytes per vector\n",
> info->min_vl);
> pr_info("SME: maximum available vector length %u bytes per vector\n",
> info->max_vl);
> pr_info("SME: default vector length %u bytes per vector\n",
> get_sme_default_vl());
> +
> + /* KVM decides whether to support mismatched systems. Just warn here: */
> + if (info->max_virtualisable_vl < info->max_vl ||
> + info->max_virtualisable_vl == sve_vl_from_vq(SME_VQ_INVALID))
> + pr_warn("SME: unvirtualisable vector lengths present\n");
If we used 0 instead of (SME_VQ_MAX + 1), this would just be:
if (info->max_virtualisable_vl < info->max_vl)
pr_warn(...);
As above, I think using 0 would be preferable.
Mark.
> }
>
> void sme_suspend_exit(void)
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v3] coresight: fix missing error code when trace ID is invalid
From: Richard Cheng @ 2026-05-11 10:26 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
In-Reply-To: <146d34e9-caa3-4119-a3f3-79515b3f2c46@oss.qualcomm.com>
On Mon, May 11, 2026 at 05:27:10PM +0800, Jie Gan wrote:
>
>
> On 5/11/2026 5:19 PM, Richard Cheng wrote:
> > On Mon, May 11, 2026 at 04:36:18PM +0800, Jie Gan wrote:
> > > When coresight_path_assign_trace_id() cannot assign a valid trace ID,
> > > coresight_enable_sysfs() takes the err_path goto with ret still 0,
> > > returning success to the caller despite no trace session being started.
> > >
> > > Fix this by changing coresight_path_assign_trace_id() to return int.
> > > Move the IS_VALID_CS_TRACE_ID() check inside the function so it returns
> > > -EINVAL on failure and 0 on success. Update coresight_enable_sysfs() to
> > > check the return value directly instead of inspecting path->trace_id
> > > after the call.
> > >
> > > The other caller in coresight-etm-perf.c discards the return value and
> > > continues to check path->trace_id via IS_VALID_CS_TRACE_ID() directly.
> > > This is unaffected: on failure path->trace_id is no longer written, so
> > > it remains 0, which IS_VALID_CS_TRACE_ID() rejects the same as before.
> > >
> > > Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path")
> > > Reviewed-by: James Clark <james.clark@linaro.org>
> > > Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> > > ---
> > > Changes in v3:
> > > - directly return the value for clear expression.
> > > - Link to v2: https://lore.kernel.org/r/20260509-fix-trace-id-error-v2-1-c900bcbab3e9@oss.qualcomm.com
> > >
> > > Changes in v2:
> > > - Refactor the coresight_path_assign_trace_id function.
> > > - Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-v1-1-5f11a5456fdf@oss.qualcomm.com
> > > ---
> > > drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++----
> > > drivers/hwtracing/coresight/coresight-priv.h | 2 +-
> > > drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
> > > 3 files changed, 13 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> > > index 46f247f73cf6..254db91a8ac9 100644
> > > --- a/drivers/hwtracing/coresight/coresight-core.c
> > > +++ b/drivers/hwtracing/coresight/coresight-core.c
> > > @@ -739,8 +739,8 @@ static int coresight_get_trace_id(struct coresight_device *csdev,
> > > * Call this after creating the path and before enabling it. This leaves
> > > * the trace ID set on the path, or it remains 0 if it couldn't be assigned.
> > > */
> > > -void coresight_path_assign_trace_id(struct coresight_path *path,
> > > - enum cs_mode mode)
> > > +int coresight_path_assign_trace_id(struct coresight_path *path,
> > > + enum cs_mode mode)
> > > {
> > > struct coresight_device *sink = coresight_get_sink(path);
> > > struct coresight_node *nd;
> > > @@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
> > > * Non 0 is either success or fail.
> > > */
> > > if (trace_id != 0) {
> > > - path->trace_id = trace_id;
> > > - return;
> > > + if (IS_VALID_CS_TRACE_ID(trace_id)) {
> > > + path->trace_id = trace_id;
> > > + return 0;
> > > + }
> > > +
> > > + return -EINVAL;
> > > }
> > > }
> > > +
> > > + return -EINVAL;
> > > }
> > > /**
> > > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
> > > index 1ea882dffd70..34c7e792adbd 100644
> > > --- a/drivers/hwtracing/coresight/coresight-priv.h
> > > +++ b/drivers/hwtracing/coresight/coresight-priv.h
> > > @@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device *orig,
> > > void coresight_remove_links(struct coresight_device *orig,
> > > struct coresight_connection *conn);
> > > u32 coresight_get_sink_id(struct coresight_device *csdev);
> > > -void coresight_path_assign_trace_id(struct coresight_path *path,
> > > +int coresight_path_assign_trace_id(struct coresight_path *path,
> > > enum cs_mode mode);
> >
> > Hi Jie,
> >
> > Thanks for your patch,
> >
> > I'm thinking will "__must_check" should be added so in the future the next caller won't accidently
> > introduce this class of bug ?
> >
>
> Hi Richard,
>
> The return value has been ignored in perf mode. It will introduce noisy by
> adding __must_check. So I think its better without __must_check?
>
> Thanks,
> Jie
>
Hi Jie,
Ahh thanks for the head up, my intention was adding a compile-time check there
to be safe, no need for __must_check here then.
If any new callers were to appear in the future we'll see how it goes.
Thanks.
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Best regards,
Richard Cheng.
> > Best regards,
> > Richard Cheng.
> >
> > > #if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
> > > diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
> > > index d2a6ed8bcc74..b6a870399e83 100644
> > > --- a/drivers/hwtracing/coresight/coresight-sysfs.c
> > > +++ b/drivers/hwtracing/coresight/coresight-sysfs.c
> > > @@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
> > > goto out;
> > > }
> > > - coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
> > > - if (!IS_VALID_CS_TRACE_ID(path->trace_id))
> > > + ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
> > > + if (ret)
> > > goto err_path;
> > > ret = coresight_enable_path(path, CS_MODE_SYSFS);
> > >
> > > ---
> > > base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
> > > change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
> > >
> > > Best regards,
> > > --
> > > Jie Gan <jie.gan@oss.qualcomm.com>
> > >
> > >
>
^ permalink raw reply
* Re: [PATCH v3 06/13] pmdomain: core: Add initial fine grained sync_state support
From: Ulf Hansson @ 2026-05-11 10:24 UTC (permalink / raw)
To: Saravana Kannan
Cc: Danilo Krummrich, Rafael J . Wysocki, Greg Kroah-Hartman,
driver-core, linux-pm, Sudeep Holla, Cristian Marussi,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Geert Uytterhoeven,
Dmitry Baryshkov, linux-arm-kernel, linux-kernel
In-Reply-To: <CACRMN=cowCsGb3x=tPOWLYdittwLCsSb2N2SXVPyxBRHThGAVg@mail.gmail.com>
On Mon, 11 May 2026 at 07:09, Saravana Kannan <saravanak@kernel.org> wrote:
>
> On Fri, May 8, 2026 at 5:39 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > A onecell (#power-domain-cells = <1 or 2>; in DT) power domain provider
> > typically provides multiple independent power domains, each with their own
> > corresponding consumers. In these cases we have to wait for all consumers
> > for all the provided power domains before the ->sync_state() callback gets
> > called for the supplier.
> >
> > In a first step to improve this, let's implement support for fine grained
> > sync_state support a per genpd basis by using the ->queue_sync_state()
> > callback. To take step by step, let's initially limit the improvement to
> > the internal genpd provider driver and to its corresponding genpd devices
> > for onecell providers.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> >
> > Changes in v3:
> > - Addressed some cosmetic comments from Geert.
> >
> > ---
> > drivers/pmdomain/core.c | 124 ++++++++++++++++++++++++++++++++++++++
> > include/linux/pm_domain.h | 1 +
> > 2 files changed, 125 insertions(+)
> >
> > diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> > index ad57846f02a3..c01a9a96e5c2 100644
> > --- a/drivers/pmdomain/core.c
> > +++ b/drivers/pmdomain/core.c
> > @@ -2699,6 +2699,119 @@ static struct generic_pm_domain *genpd_get_from_provider(
> > return genpd;
> > }
> >
> > +static bool genpd_should_wait_for_consumer(struct device_node *np)
> > +{
> > + struct generic_pm_domain *genpd;
> > + bool should_wait = false;
> > +
> > + mutex_lock(&gpd_list_lock);
> > + list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
> > + if (genpd->provider == of_fwnode_handle(np)) {
> > + genpd_lock(genpd);
> > +
> > + /* Clear the previous state before reevaluating. */
> > + genpd->wait_for_consumer = false;
> > +
> > + /*
> > + * Unless there is at least one genpd for the provider
> > + * that is being kept powered-on, we don't have to care
> > + * about waiting for consumers.
> > + */
> > + if (genpd->stay_on)
> > + should_wait = true;
> > +
> > + genpd_unlock(genpd);
> > + }
> > + }
> > + mutex_unlock(&gpd_list_lock);
>
> I think I understand the intent of this function, but haven't dug into
> genpd code enough to comment on this yet. I'll come back to this
> later.
>
> > +
> > + return should_wait;
> > +}
> > +
> > +static void genpd_parse_for_consumer(struct device_node *sup,
> > + struct device_node *con)
> > +{
> > + struct generic_pm_domain *genpd;
> > +
> > + for (unsigned int i = 0; ; i++) {
> > + struct of_phandle_args pd_args;
> > +
> > + if (of_parse_phandle_with_args(con, "power-domains",
> > + "#power-domain-cells",
> > + i, &pd_args))
> > + break;
>
> Why not use a while or a do while() instead of this infinite for loop
> with a break?
I guess it's a matter of personal preference. I'm not sure the code
gets any nicer with a do/while, but if you really insist I can change
it.
>
> > +
> > + /*
> > + * The phandle must correspond to the supplier's genpd provider
> > + * to be relevant else let's move to the next index.
> > + */
> > + if (sup != pd_args.np) {
> > + of_node_put(pd_args.np);
> > + continue;
> > + }
> > +
> > + mutex_lock(&gpd_list_lock);
> > + genpd = genpd_get_from_provider(&pd_args);
> > + if (!IS_ERR(genpd)) {
> > + genpd_lock(genpd);
> > + genpd->wait_for_consumer = true;
> > + genpd_unlock(genpd);
> > + }
> > + mutex_unlock(&gpd_list_lock);
> > +
> > + of_node_put(pd_args.np);
> > + }
> > +}
> > +
> > +static void _genpd_queue_sync_state(struct device_node *np)
> > +{
> > + struct generic_pm_domain *genpd;
> > +
> > + mutex_lock(&gpd_list_lock);
> > + list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
> > + if (genpd->provider == of_fwnode_handle(np)) {
> > + genpd_lock(genpd);
> > + if (genpd->stay_on && !genpd->wait_for_consumer) {
> > + genpd->stay_on = false;
> > + genpd_queue_power_off_work(genpd);
> > + }
> > + genpd_unlock(genpd);
> > + }
> > + }
> > + mutex_unlock(&gpd_list_lock);
> > +}
> > +
> > +static void genpd_queue_sync_state(struct device *dev)
> > +{
> > + struct device_node *np = dev->of_node;
> > + struct device_link *link;
> > +
> > + if (!genpd_should_wait_for_consumer(np))
> > + return;
> > +
> > + list_for_each_entry(link, &dev->links.consumers, s_node) {
>
> Couple of issues:
> 1. I don't want the frameworks to be so deeply aware of driver core
> internals. I want the driver core maintainers to be able to change the
> devlink implementation without having to worry about going and fixing
> all the frameworks. So, please add a for_each_consumer_dev(supplier,
> callback) and for_each_supplier_dev(consumer, callback) helper
> functions.
I understand your concern and I like the idea. However, maybe it's
better to get this landed (the series is complicated as is) first and
then can continue to improve the code on top, with helper functions
etc.
>
> 2. This doesn't ignore "SYNC_STATE_ONLY" links and that's going to
> confuse the consumer count/check you might do or at the least waste
> parsing those.
I am not sure I understand how I should take SYNC_STATE_ONLY links
into account here.
At each call to the genpd_queue_sync_state(), we walk through all the
provided genpds for the provider. No previous state is cached to track
consumer counts.
>
> 3. **Device** links are not the complete list of consumers because
> they can only link consumer **devices** once the consumer **device**
> is created.
>
> 4. What you really need is a for_each_consumer_fwnode(supplier,
> callback) that first loops through all the consumer device links and
> calls the callback() on their fwnode and then the same function needs
> to loop through all the fwnode links and then pass those consumer
> fwnodes to the callback. And inside that callback you can do whatever
> you want.
The ->queue_sync_state() callback is invoked *after*
__device_links_queue_sync_state() has been called for the device,
which is also when the conditions for calling ->sync_state() is
checked.
If there are problems with not yet registered consumer device links,
why isn't that as problem for regular ->sync_state() in
__device_links_queue_sync_state()?
>
> 5. You might want to add a for_each_inactive_consumer(supplier,
> callback) too to simplify your need for checking if a fwnode has a
> device and then checking if it's probed.
>
> Thanks,
> Saravana
>
>
> > + struct device *consumer = link->consumer;
> > +
> > + if (!device_link_test(link, DL_FLAG_MANAGED))
> > + continue;
> > +
> > + if (link->status == DL_STATE_ACTIVE)
> > + continue;
> > +
> > + if (!consumer->of_node)
> > + continue;
> > +
> > + /*
> > + * A consumer device has not been probed yet. Let's parse its
> > + * device node for the power-domains property, to find out the
> > + * genpds it may belong to and then prevent sync state for them.
> > + */
> > + genpd_parse_for_consumer(np, consumer->of_node);
> > + }
> > +
> > + _genpd_queue_sync_state(np);
> > +}
> > +
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [RFC PATCH net-next 2/5] net: ti: icssg-stats: Move long delayed work on system_dfl_long_wq
From: Richard Cheng @ 2026-05-11 10:14 UTC (permalink / raw)
To: Marco Crivellari
Cc: linux-kernel, netdev, Tejun Heo, Lai Jiangshan,
Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, MD Danish Anwar, Roger Quadros, linux-arm-kernel
In-Reply-To: <20260511092846.120141-3-marco.crivellari@suse.com>
On Mon, May 11, 2026 at 11:28:37AM +0800, Marco Crivellari wrote:
> Currently the code enqueue work items using {queue|mod}_delayed_work(),
> using system_long_wq. This workqueue should be used when long works are
> expected and it is a per-cpu workqueue.
>
> The function(s) end up calling __queue_delayed_work(), which set a global
> timer that could fire anywhere, enqueuing the work where the timer fired.
>
> Unbound works could benefit from scheduler task placement, to optimize
> performance and power consumption. Long work shouldn't stick to a single
> CPU.
>
> Recently, a new unbound workqueue specific for long running work has
> been added:
>
> c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")
>
> Since the workqueue work doesn't rely on per-cpu variables, there is no
> obvious reason that justify the use of a per-cpu workqueue. So change
> system_long_wq with system_dfl_long_wq so that the work may benefit from
> scheduler task placement.
>
> Cc: MD Danish Anwar <danishanwar@ti.com>
> Cc: Roger Quadros <rogerq@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/net/ethernet/ti/icssg/icssg_stats.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.c b/drivers/net/ethernet/ti/icssg/icssg_stats.c
> index 7159baa0155c..7d6d6692d819 100644
> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.c
> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.c
> @@ -69,7 +69,7 @@ void icssg_stats_work_handler(struct work_struct *work)
> stats_work.work);
> emac_update_hardware_stats(emac);
>
> - queue_delayed_work(system_long_wq, &emac->stats_work,
> + queue_delayed_work(system_dfl_long_wq, &emac->stats_work,
> msecs_to_jiffies((STATS_TIME_LIMIT_1G_MS * 1000) / emac->speed));
> }
> EXPORT_SYMBOL_GPL(icssg_stats_work_handler);
> --
> 2.54.0
>
>
LGTM,
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Best regards,
Richard Cheng.
^ permalink raw reply
* [PATCH v12 4/5] dt-bindings: mfd: Add binding for MediaTek MT6363 series SPMI PMIC
From: AngeloGioacchino Del Regno @ 2026-05-11 10:13 UTC (permalink / raw)
To: linux-mediatek
Cc: lee, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, wenst,
Nícolas F. R. A. Prado
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
Add a binding for the MediaTek MT6363/6373 (and similar) multi
function PMICs connected over SPMI.
These PMICs are found on board designs using newer MediaTek SoCs,
such as the Dimensity 9400 Smartphone chip, or the Chromebook
MT8196 chip.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../bindings/mfd/mediatek,mt6363.yaml | 109 ++++++++++++++++++
1 file changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6363.yaml
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6363.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6363.yaml
new file mode 100644
index 000000000000..ee90d16053e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6363.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mediatek,mt6363.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6363 series SPMI PMICs multi-function device
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description: |
+ Some MediaTek Power Management ICs (PMICs) found in board designs with
+ the Helio, Dimensity and/or Kompanio series of SoCs are interfaced to
+ the chip via the System Power Management Interface (SPMI) bus.
+
+ These PMICs are multi-function devices with various sub modules.
+ For example, those may include one, or more of the following:
+ - Auxiliary ADC Controller
+ - Clock Controller
+ - eFuses
+ - GPIO Controller
+ - Interrupt Controller
+ - Keys
+ - LEDs Controller
+ - Regulators
+ - RTC
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6363
+ - mediatek,mt6373
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 3
+
+patternProperties:
+ "^adc@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
+
+ "^regulators@[0-9a-f]+$":
+ type: object
+ oneOf:
+ - $ref: /schemas/regulator/mediatek,mt6363-regulator.yaml#
+ - $ref: /schemas/regulator/mediatek,mt6373-regulator.yaml#
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@4 {
+ compatible = "mediatek,mt6363";
+ reg = <0x4 SPMI_USID>;
+ interrupts = <4 64 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #interrupt-cells = <3>;
+ #size-cells = <0>;
+
+ regulators@30 {
+ compatible = "mediatek,mt6363-regulator";
+ reg = <0x30>;
+
+ vio18 {
+ regulator-name = "pp1800-vio18-s3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <0 2>;
+ regulator-allow-set-load;
+ regulator-over-current-protection;
+ };
+ };
+
+ adc@1000 {
+ compatible = "mediatek,mt6363-auxadc";
+ reg = <0x1000>;
+ #io-channel-cells = <1>;
+ };
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v12 3/5] dt-bindings: iio: adc: mt6359: Allow reg for SPMI PMICs AuxADC
From: AngeloGioacchino Del Regno @ 2026-05-11 10:13 UTC (permalink / raw)
To: linux-mediatek
Cc: lee, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, wenst
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
When one or multiple Auxiliary ADC IPs are embedded in a SPMI PMIC
it is reachable at a specific address.
Allow specifying the `reg` property and make it a required one for
MediaTek MT6363/6373 PMICs as those communicate over SPMI and also
disallow it for the others (as it wouldn't be applicable).
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../iio/adc/mediatek,mt6359-auxadc.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..e685e5ee224a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -25,6 +25,9 @@ properties:
- mediatek,mt6363-auxadc
- mediatek,mt6373-auxadc
+ reg:
+ maxItems: 1
+
"#io-channel-cells":
const: 1
@@ -33,3 +36,17 @@ required:
- "#io-channel-cells"
additionalProperties: false
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt6363-auxadc
+ - mediatek,mt6373-auxadc
+then:
+ required:
+ - reg
+else:
+ properties:
+ reg: false
--
2.53.0
^ permalink raw reply related
* [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: AngeloGioacchino Del Regno @ 2026-05-11 10:13 UTC (permalink / raw)
To: linux-mediatek
Cc: lee, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, wenst
Changes in v12:
- This is a partial resend. MT6373 regulators and MFD patches were not picked.
- Rebased over next-20260508
Changes in v11:
- Removed unnecessary #address-cells in all mt6316 bindings
Changes in v10:
- Added "struct" prefix to structs kerneldoc
- Renamed struct mtk_spmi_pmic_pdata to mtk_spmi_pmic_variant
- Added "REG_" to MT6363/73 mfd register definitions to disambiguate
- Expanded MTK_SPMI_PMIC_IRQ_GROUP macro parameter names as suggested
- Some rewording of comments as suggested, addition of more comments
- Refactored IRQ domain handling due to deprecation of function
irq_domain_add_tree() to use the new irq_domain_create_tree()
- Fixed to use generic_handle_domain_irq_safe() to avoid races
- Added support for two interrupt cells in translation
- Removed .irq_lock() and .irq_unlock() in favor of lockdep classes
- Added support for handling PMICs without IRQ Group register for
upcoming MT6685 implementation
Changes in v9:
- Applied more bindings fixes as pointed out by Rob
- Changed irq fwspec to have 3 cells as the mfd driver handles 3
- Using intsize instead of fwspec.param_count in xlate (thanks Nicolas!)
Changes in v8:
- Added REGMAP_SPMI selection in Kconfig for all of MT6316/6363/6373
to satisfy __devm_regmap_init_spmi_ext() dependency in case they
are built with COMPILE_TEST (+randconfig) configuration
- Fixed indentation in Kconfig on help lines (some were using spaces
instead of tab + 2 spaces, don't know how that happened)
- Removed forgotten final blank line on mt63{6,7}3-regulator.h header
- Fixed error checks in mt6363-regulator, mt6373-regulator for call
to mt63{6,7}e_spmi_register_regmap()
- Tested again on MT8196 Chromebook.
Changes in v7:
- Removed unintentionally added, useless Link tags from all patches
- #size-cells is now required in mfd mt6363 binding
- Further fixes in mt6363/73 regulator bindings
- Mentioned weird 9-bits BE format and usage of undocumented set/clr
registers in commit description for the MT6316 regulator driver
- Refactored bindings for MT6316 PMIC (regulators):
- Added reg, #address-cells as required properties
- Added regulator-allowed-modes and its description
- Changed mt6316b/mt6316c to use patternProperties instead, as it
now makes sense to avoid duplication while keeping documentation
for the regulator-allowed-modes property in all vbuck entries
- Added decent examples that correctly describes the MT6316 PMICs
Changes in v6:
- Added missing bitfield.h header inclusion in mt6363-regulator.c
- Added commit "dt-bindings: iio: adc: mt6359: Allow reg for SPMI PMICs AuxADC"
to fix warnings on specifying reg property in adc node
- Added $ref in mt6363/73 regulator bindings to reduce duplication on LDOs
- Moved MT6363 regulators example to MFD binding
- Rebased on next-20250929
Changes in v5:
- This time the dt-bindings commits are the right ones... sorry again :-)
- Removed accidentally added Link: tags in all patches.
Changes in v4:
- Rewritten all register definitions for both MT6363 and MT6373
regulators to be register offsets instead
- Added the appropriate supply_name to all vregs in 6363 and 6373
- Simplified the macro parameters for all vregs in 6363 and 6373
- Added common definitions pattern in macros to avoid plain writing
register definitions in every macro call
- Added registration of SPMI sub-device in MT6363/73 and setup of
regmap reg_base based on `reg` parsed from devicetree
- Removed interrupts parsing from devicetree
- Moved (pmic-internal) IRQs to macros
- mtk-spmi-pmic: Added parsing if irqspec with param_count=2 for
easier irqs registration from regulator drivers
Changes in v3:
- Added buck and ldo supplies to mt6363 and mt6373 drivers and bindings;
- Removed interrupts from mt6363 and mt6373 bindings;
- Added registering interrupts in mt6363/73 drivers instead:
this avoids big arrays in the mfd driver, which will grow
uncontrollably (as it already happened in multiple MediaTek
drivers) and with each new(future) supported PMIC;
- Removed "ldo-" and "buck-" prefixes from mt6363 regulators
- Renamed "vbX" to "vbuckX", reflecting datasheet name
- Changed all LDOs in MT6363 and MT6373 to add VOCAL usage, both
increasing the number of voltage steps (2.5 or 10mV increments
depending on the LDO) and the accuracy of the reported voltages
- Tested again on MT8196 board
Changes in v2:
- Merged MFD and regulator in one series
- Split mediatek,mt6316-regulator.yaml in three files as
suggested by krzk
- Added interrupt-names list in MT6363/MT6373 bindings as
suggested by krzk
- Documented regulator modes in MT6363/73 as suggested by krzk
- Fixed interrupt and interrupt-names maxItems in both 6363/73
because, well... I miscounted them in v1 :-)
- Removed keys from mt6363 binding: the compatible was not yet
added to the keys binding and doing that will take quite a
while, as I have to find a way to test the code before that
as unfortunately my HW does not provide any way to test the
PMIC keys (thought it did, but then turns out it doesn't...)
- Completed the mt6363 MFD example with ADC as suggested by Rob
- Avoided applying regulator schemas multiple times as pointed
out by Rob (in mfd binding)
- Fixed MT6363/73 issues pointed out by lkp (eh, sorry, that
happened during a last minute cleanup... ugh!).
- Brewed some more coffee :-)
This series adds support for three new MediaTek PMICs: MT6316, MT6363
and MT6373 and their variants - used in board designs featuring the
MediaTek MT8196 Chromebook SoC, or the MT6991 Dimensity 9400 Smartphone
SoC.
In particular, MT6316 is a regulator, but the MT6363 and MT6373 PMICs
are multi-function devices, as they have and expose multiple sub-devices;
moreover, some of those also contain an interrupt controller, managing
internal IPs interrupts: for those, a chained interrupt handler is
registered, which parent is the SPMI controller itself.
This series adds support for all of the MT6316 regulator variants and
for MT6363, MT6373 SPMI PMICs and their interrupt controller.
AngeloGioacchino Del Regno (5):
dt-bindings: regulator: Document MediaTek MT6373 PMIC Regulators
regulator: Add support for MediaTek MT6373 SPMI PMIC Regulators
dt-bindings: iio: adc: mt6359: Allow reg for SPMI PMICs AuxADC
dt-bindings: mfd: Add binding for MediaTek MT6363 series SPMI PMIC
mfd: Add support for MediaTek SPMI PMICs and MT6363/73
.../iio/adc/mediatek,mt6359-auxadc.yaml | 17 +
.../bindings/mfd/mediatek,mt6363.yaml | 109 +++
.../regulator/mediatek,mt6373-regulator.yaml | 137 ++++
drivers/mfd/Kconfig | 16 +
drivers/mfd/Makefile | 1 +
drivers/mfd/mtk-spmi-pmic.c | 427 ++++++++++
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6373-regulator.c | 772 ++++++++++++++++++
include/linux/mfd/mt63x3_spmi/registers.h | 34 +
include/linux/regulator/mt6373-regulator.h | 161 ++++
11 files changed, 1685 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6363.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6373-regulator.yaml
create mode 100644 drivers/mfd/mtk-spmi-pmic.c
create mode 100644 drivers/regulator/mt6373-regulator.c
create mode 100644 include/linux/mfd/mt63x3_spmi/registers.h
create mode 100644 include/linux/regulator/mt6373-regulator.h
--
2.53.0
^ permalink raw reply
* [PATCH v12 1/5] dt-bindings: regulator: Document MediaTek MT6373 PMIC Regulators
From: AngeloGioacchino Del Regno @ 2026-05-11 10:13 UTC (permalink / raw)
To: linux-mediatek
Cc: lee, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, wenst
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
Add bindings for the regulators found in the MediaTek MT6363 PMIC,
usually found in board designs using the MT6991 Dimensity 9400 and
on MT8196 Kompanio SoC for Chromebooks, along with the MT6316 and
MT6363 PMICs.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../regulator/mediatek,mt6373-regulator.yaml | 137 ++++++++++++++++++
1 file changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6373-regulator.yaml
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6373-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6373-regulator.yaml
new file mode 100644
index 000000000000..4562f291fc0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6373-regulator.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6373-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6373 PMIC Regulators
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MT6373 SPMI PMIC provides 10 BUCK and 23 LDO (Low DropOut) regulators
+ and can optionally provide overcurrent warnings with one ocp interrupt
+ for each voltage regulator.
+
+properties:
+ compatible:
+ const: mediatek,mt6373-regulator
+
+ reg:
+ maxItems: 1
+
+ vsys-vbuck0-supply:
+ description: Input supply for vbuck0
+
+ vsys-vbuck1-supply:
+ description: Input supply for vbuck1
+
+ vsys-vbuck2-supply:
+ description: Input supply for vbuck2
+
+ vsys-vbuck3-supply:
+ description: Input supply for vbuck3
+
+ vsys-vbuck4-supply:
+ description: Input supply for vbuck4
+
+ vsys-vbuck5-supply:
+ description: Input supply for vbuck5
+
+ vsys-vbuck6-supply:
+ description: Input supply for vbuck6
+
+ vsys-vbuck7-supply:
+ description: Input supply for vbuck7
+
+ vsys-vbuck8-supply:
+ description: Input supply for vbuck8
+
+ vsys-vbuck9-supply:
+ description: Input supply for vbuck9
+
+ vs1-ldo1-supply:
+ description: Input supply for vant18, vaud18, vcn18io
+
+ vs2-ldo1-supply:
+ description: Input supply for vrf12-aif, vrf13-aif
+
+ vs3-ldo1-supply:
+ description: Input supply for vrf09-aif, vsram-digrf-aif
+
+ vsys-ldo1-supply:
+ description: Input supply for vcn33-1, vcn33-2, vmc
+
+ vsys-ldo2-supply:
+ description:
+ Input supply for vaux18, vcn33-3, vefuse, vfp, vibr, vio28, vtp, vusb
+
+ vsys-ldo3-supply:
+ description: Input supply for vmch, vmch-eint-high/low
+
+patternProperties:
+ "^v(ant|aud|aux)18$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vbuck[0-9]$":
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed Buck regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 1 - Forced Continuous Conduction mode (FCCM) for improved voltage
+ regulation accuracy with constant switching frequency but lower
+ regulator efficiency
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, does not limit the maximum out
+ current but unless only a light load is applied, there will be
+ regulation accuracy and efficiency losses.
+ 3 - Forced Ultra Low Power mode for ultra low load, this greatly
+ reduces the maximum output power, makes the regulator to be
+ efficient only for ultra light load, and greatly reduces the
+ quiescent current (Iq) of the buck.
+ maxItems: 3
+ items:
+ enum: [ 0, 1, 2, 3 ]
+ unevaluatedProperties: false
+
+ "^v(cn18io|cn33-[123]|efuse|fp|tp|ibr|io28|sram-digrf-aif|usb)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vmc(h)?$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vmch-eint-(low|high)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vrf(09|12|13|18|io18)-aif$":
+ $ref: "#/$defs/ldo-common"
+
+$defs:
+ ldo-common:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed LDO regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, does not limit the maximum out
+ current but unless only a light load is applied, there will be
+ regulation accuracy and efficiency losses.
+ maxItems: 2
+ items:
+ enum: [ 0, 2 ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-11 10:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer
In-Reply-To: <20260511-imx8dxl-sr-som-v4-0-64381b3bf80d@solid-run.com>
Add support for the SolidRun i.MX8DXL System-on-Module (revision 2.1)
and its corresponding evaluation carrier board, the HummingBoard
Telematics (revision 2.0).
The SoM features:
- eMMC
- GNSS with 1PPS
- V2X DSRC Radio
- Secure Element for V2X Applications
- Inertial Sensor
- Pressure Sensor
- Compass
The HummingBoard Telematics carrier board features:
- Cellular Modem
- WiFi & Bluetooth
- RTC with backup battery
- CAN
- 100Base-TX Ethernet
- 100Base-T1 Ethernet
- Multi-interface I/O connector
- Multi-interface add-on board connector
The multi-interface I/O connector supplies power and provides basic I/O
(Console UART, 100Base-TX, 100Base-T1, CAN, and power-supply logic level
GPIOs). The SolidRun Evaluation Kit includes a suitable cable and
adapter board that breaks these out into RJ45, USB Type-A, microUSB
Console, and Terminal Block connectors.
The multi-interface add-on board connector provides additional
interfaces (4x 100Base-T1, 2x SGMII, USB 2.0 shared with the cellular
modem, CAN, MDIO, SPI, UART, PCIe, I2C, and GPIO). These add-on
interfaces are disabled by default in the base device tree and are
intended to be enabled and extended via device tree overlays.
Note that a few components physically present on the SoM were omitted
from this description due to a lack of upstream bindings and drivers:
- Pressure Sensor
- V2X DSRC Radio
- Secure Element
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 523 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 ++++++++++++++++++
3 files changed, 983 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..7db459f666610 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -111,6 +111,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
imx8dxl-evk-pcie-ep-dtbs += imx8dxl-evk.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk-pcie-ep.dtb
+DTC_FLAGS_imx8dxl-hummingboard-telematics := -@
+dtb-$(CONFIG_ARCH_MXC) += imx8dxl-hummingboard-telematics.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdp-mba8xx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdps-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
new file mode 100644
index 0000000000000..7e822cbd7a528
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
@@ -0,0 +1,523 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "imx8dxl-sr-som.dtsi"
+
+/ {
+ compatible = "solidrun,imx8dxl-hummingboard-telematics",
+ "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL HummingBoard Telematics";
+
+ aliases {
+ /* override ethernet aliases from imx8dxl.dtsi */
+ ethernet0 = &eqos;
+ /delete-property/ ethernet1;
+ gpio8 = &tca6408_u2;
+ mmc2 = &usdhc3;
+ rtc0 = &carrier_rtc;
+ rtc1 = &rtc;
+ serial1 = &lpuart1;
+ };
+
+ v_1_1: regulator-1-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v1";
+ pinctrl-0 = <®ulator_1v1_pins>;
+ pinctrl-names = "default";
+ regulator-always-on;
+ regulator-max-microvolt = <1100000>;
+ regulator-min-microvolt = <1100000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio4 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_5_0: regulator-5-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ };
+
+ /* can transceiver builtin regulator (STBN1 pin) */
+ reg_flexcan1_stby: regulator-flexcan1-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan1-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ /* can transceiver builtin regulator (STBN2 pin) */
+ reg_flexcan2_stby: regulator-flexcan2-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan2-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ modem_vbat: regulator-modem-vbat {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ pinctrl-0 = <®ulator_modem_vbat_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3600000>;
+ regulator-min-microvolt = <3600000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio0 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vbus1: regulator-vbus-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus1";
+ pinctrl-0 = <®ulator_usb1_vbus_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&lsio_gpio0 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&lsio_gpio0 15 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&dma_apbh {
+ status = "disabled";
+};
+
+&eqos {
+ /* delays are added by connected ethernet-switch cpu port */
+ phy-mode = "rgmii";
+ pinctrl-0 = <&eqos_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+};
+
+&flexcan1 {
+ pinctrl-0 = <&flexcan1_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan1_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&flexcan2 {
+ pinctrl-0 = <&flexcan2_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan2_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&i2c2 {
+ /* routed to J14: SDA(51), SCL(53) */
+
+ /* regulator@18 */
+
+ tca6408_u2: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names = "DIG_IN1", "DIG_IN2", "CAN_STNB1", "CAN_STNB2",
+ "DIG_OUT1", "DIG_OUT2", "", "";
+ interrupts-extended = <&lsio_gpio0 20 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&tca6408_u2_int_pins>;
+ pinctrl-names = "default";
+ };
+
+ carrier_rtc: rtc@32 {
+ compatible = "epson,rx8111";
+ reg = <0x32>;
+ };
+};
+
+&iomuxc {
+ bluetooth_pins: pinctrl-bluetooth-grp {
+ fsl,pins = <
+ /* BT_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SCK_LSIO_GPIO0_IO13 0x0000061
+ >;
+ };
+
+ eqos_pins: pinctrl-eqos-grp {
+ fsl,pins = <
+ /* MDIO to Switch */
+ /* enet0 mdio pads supplied with 3.3v */
+ /* IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIOCT */
+ IMX8DXL_ENET0_MDC_CONN_EQOS_MDC 0x06000020
+ IMX8DXL_ENET0_MDIO_CONN_EQOS_MDIO 0x06000020
+ /* RGMII to Switch */
+ IMX8DXL_ENET1_RGMII_TX_CTL_CONN_EQOS_RGMII_TX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_TXC_CONN_EQOS_RGMII_TXC 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD0_CONN_EQOS_RGMII_TXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD1_CONN_EQOS_RGMII_TXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD2_CONN_EQOS_RGMII_TXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD3_CONN_EQOS_RGMII_TXD3 0x06000020
+ IMX8DXL_ENET1_RGMII_RXC_CONN_EQOS_RGMII_RXC 0x06000020
+ IMX8DXL_ENET1_RGMII_RX_CTL_CONN_EQOS_RGMII_RX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD0_CONN_EQOS_RGMII_RXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD1_CONN_EQOS_RGMII_RXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD2_CONN_EQOS_RGMII_RXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD3_CONN_EQOS_RGMII_RXD3 0x06000020
+ >;
+ };
+
+ flexcan1_pins: pinctrl-flexcan1-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN0_TX_ADMA_FLEXCAN0_TX 0x00000021
+ IMX8DXL_FLEXCAN0_RX_ADMA_FLEXCAN0_RX 0x00000021
+ >;
+ };
+
+ flexcan2_pins: pinctrl-flexcan2-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN1_TX_ADMA_FLEXCAN1_TX 0x00000021
+ IMX8DXL_FLEXCAN1_RX_ADMA_FLEXCAN1_RX 0x00000021
+ >;
+ };
+
+ lpspi0_pins: pinctrl-lpspi0-grp {
+ fsl,pins = <
+ IMX8DXL_SPI0_SCK_ADMA_SPI0_SCK 0x600004c
+ IMX8DXL_SPI0_SDO_ADMA_SPI0_SDO 0x600004c
+ IMX8DXL_SPI0_SDI_ADMA_SPI0_SDI 0x600004c
+ IMX8DXL_SPI0_CS0_LSIO_GPIO1_IO08 0x0000021
+ IMX8DXL_SPI0_CS1_LSIO_GPIO1_IO07 0x0000021
+ >;
+ };
+
+ lpuart1_pins: pinctrl-lpuart1-grp {
+ fsl,pins = <
+ IMX8DXL_UART1_RX_ADMA_UART1_RX 0x06000020
+ IMX8DXL_UART1_TX_ADMA_UART1_TX 0x06000020
+ IMX8DXL_UART1_CTS_B_ADMA_UART1_CTS_B 0x06000020
+ IMX8DXL_UART1_RTS_B_ADMA_UART1_RTS_B 0x06000020
+ >;
+ };
+
+ modem_pins: pinctrl-lte-grp {
+ fsl,pins = <
+ /* modem RESET_N: io open drain drive 2mA */
+ IMX8DXL_ADC_IN3_LSIO_GPIO1_IO11 0x2000061
+
+ /* modem PWRKEY: io open drain with pull-up, drive 2mA */
+ IMX8DXL_ADC_IN2_LSIO_GPIO1_IO12 0x2000021
+ >;
+ };
+
+ regulator_1v1_pins: pinctrl-regulator-1-1-grp {
+ fsl,pins = <
+ /* SW_PE: io without pull-up */
+ IMX8DXL_USB_SS3_TC2_LSIO_GPIO4_IO05 0x0000061
+ >;
+ };
+
+ regulator_modem_vbat_pins: pinctrl-regulator-modem-vbat-grp {
+ fsl,pins = <
+ /*
+ * RF_PWR: io without pull-up,
+ * has either external pull-up (R1117) or pull-down (R1118).
+ * With pull-up Modem will boot at system power-up,
+ * with pull-down modem will enter power-down mode once
+ * vbat is enabled -> toggle pwrkey to boot modem.
+ * Hence pull-up (R1117) is preferred.
+ */
+ IMX8DXL_SPI3_SDO_LSIO_GPIO0_IO14 0x0000061
+ >;
+ };
+
+ regulator_usb1_vbus_pins: pinctrl-regulator-usb1-vbus-grp {
+ fsl,pins = <
+ /* regulator enable: open-drain with pull-up & low drive strength */
+ IMX8DXL_SPI3_CS0_LSIO_GPIO0_IO16 0x2000021
+ >;
+ };
+
+ switch_pins: pinctrl-switch-grp {
+ fsl,pins = <
+ /* SW_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC0_LSIO_GPIO4_IO03 0x0000021
+
+ /* SW_CORE_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC1_LSIO_GPIO4_IO04 0x0000021
+
+ /* INT_N: io without pull-up */
+ IMX8DXL_USB_SS3_TC3_LSIO_GPIO4_IO06 0x0000021
+ >;
+ };
+
+ tca6408_u2_int_pins: pinctrl-tca6408-u2-int-grp {
+ fsl,pins = <
+ /* gpio-expander interrupt: io with pull-up */
+ IMX8DXL_MCLK_OUT0_LSIO_GPIO0_IO20 0x0000021
+ >;
+ };
+
+ usdhc3_pins: pinctrl-usdhc3-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_TXC_CONN_USDHC2_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_TX_CTL_CONN_USDHC2_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC2_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD1_CONN_USDHC2_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD2_CONN_USDHC2_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD3_CONN_USDHC2_DATA3 0x00000021
+ >;
+ };
+
+ wifi_pins: pinctrl-wifi-grp {
+ fsl,pins = <
+ /* WL_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SDI_LSIO_GPIO0_IO15 0x0000061
+ >;
+ };
+};
+
+&lpspi0 {
+ cs-gpios = <&lsio_gpio1 8 GPIO_ACTIVE_LOW>, <&lsio_gpio1 7 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&lpspi0_pins>, <&switch_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethernet-switch@0 {
+ compatible = "nxp,sja1110a";
+ reg = <0>;
+ reset-gpios = <&lsio_gpio4 3 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <4000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ port@1 {
+ reg = <0x1>;
+ phy-handle = <&switch_port1_base_tx_phy>;
+ phy-mode = "internal";
+ };
+
+ /* CPU */
+ port@2 {
+ reg = <0x2>;
+ ethernet = <&eqos>;
+ phy-mode = "rgmii-id";
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+ };
+
+ /* sgmii on addon board connector J21 */
+ port@3 {
+ reg = <0x3>;
+ status = "disabled";
+ };
+
+ /* sgmii on addon board connector J21 */
+ port@4 {
+ reg = <0x4>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@5 {
+ reg = <0x5>;
+ phy-handle = <&switch_port5_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@6 {
+ reg = <0x6>;
+ phy-handle = <&switch_port6_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@7 {
+ reg = <0x7>;
+ phy-handle = <&switch_port7_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@8 {
+ reg = <0x8>;
+ phy-handle = <&switch_port8_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@9 {
+ reg = <0x9>;
+ phy-handle = <&switch_port9_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ port@a {
+ reg = <0xa>;
+ phy-handle = <&switch_port10_base_t1_phy>;
+ phy-mode = "internal";
+ };
+ };
+
+ mdios {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ compatible = "nxp,sja1110-base-t1-mdio";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port5_base_t1_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x1>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port6_base_t1_phy: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x2>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port7_base_t1_phy: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x3>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port8_base_t1_phy: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x4>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port9_base_t1_phy: ethernet-phy@5 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x5>;
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ switch_port10_base_t1_phy: ethernet-phy@6 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x6>;
+ };
+ };
+
+ mdio@1 {
+ compatible = "nxp,sja1110-base-tx-mdio";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ switch_port1_base_tx_phy: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ };
+ };
+ };
+};
+
+/* bluetooth */
+&lpuart1 {
+ pinctrl-0 = <&lpuart1_pins>, <&bluetooth_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ /* Murata 1MW module supports max. 3M baud */
+ max-speed = <3000000>;
+ shutdown-gpios = <&lsio_gpio0 13 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&usbotg1 {
+ vbus-supply = <&vbus1>;
+};
+
+/* cellular modem */
+&usbotg2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adp-disable;
+ disable-over-current;
+ dr_mode = "host";
+ hnp-disable;
+ pinctrl-0 = <&modem_pins>;
+ pinctrl-names = "default";
+ power-active-high;
+ srp-disable;
+ vbus-supply = <&v_5_0>;
+ status = "okay";
+
+ usb-device@1 {
+ compatible = "usb2c7c,125";
+ reg = <1>;
+ reset-duration-us = <150000>;
+ reset-gpios = <&lsio_gpio1 11 GPIO_ACTIVE_LOW>;
+ vbus-supply = <&v_3_3>;
+ vdd-supply = <&modem_vbat>;
+ };
+};
+
+&usbphy2 {
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ bus-width = <4>;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc3_pins>, <&wifi_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
new file mode 100644
index 0000000000000..93a0eb4d7f770
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+#include "imx8dxl.dtsi"
+/ {
+ compatible = "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL SoM";
+
+ aliases {
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart0;
+ serial2 = &lpuart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ imx8dxl-cm4 {
+ compatible = "fsl,imx8qxp-cm4";
+ clocks = <&clk_dummy>;
+ mboxes = <&lsio_mu5 0 1 &lsio_mu5 1 1 &lsio_mu5 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ power-domains = <&pd IMX_SC_R_M4_0_PID0>, <&pd IMX_SC_R_M4_0_MU_1A>;
+ fsl,entry-address = <0x34fe0000>;
+ fsl,resource-id = <IMX_SC_R_M4_0_PID0>;
+ };
+
+ pps {
+ compatible = "pps-gpio";
+ gpios = <&lsio_gpio2 6 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&gnss_pps_pins>;
+ pinctrl-names = "default";
+ };
+
+ v_1_2: regulator-1-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v2";
+ pinctrl-0 = <®ulator_1_2_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ gpio = <&lsio_gpio1 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_6: regulator-1-6 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v6";
+ pinctrl-0 = <®ulator_1_6_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1600000>;
+ regulator-min-microvolt = <1600000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_8: regulator-1-8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ v_1_8_se: regulator-1-8-secure-element {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8-se";
+ pinctrl-0 = <®ulator_1_8_se_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio3 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_3_3: regulator-3-3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x98000000 0 0x14000000>;
+ reusable;
+ size = <0 0x14000000>;
+ linux,cma-default;
+ };
+
+ vdev0vring0: memory0@90000000 {
+ reg = <0 0x90000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@90008000 {
+ reg = <0 0x90008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: memory@90010000 {
+ reg = <0 0x90010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: memory@90018000 {
+ reg = <0 0x90018000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: memory-rsc-table@900ff000 {
+ reg = <0 0x900ff000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: memory-vdevbuffer@90400000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x90400000 0 0x100000>;
+ no-map;
+ };
+
+ /*
+ * Memory reserved for optee usage. Please do not use.
+ * This will be automatically added to dtb if OP-TEE is installed.
+ * optee@96000000 {
+ * reg = <0 0x96000000 0 0x2000000>;
+ * no-map;
+ * };
+ */
+ };
+
+ memory@80000000 {
+ reg = <0x00000000 0x80000000 0 0x40000000>;
+ device_type = "memory";
+ };
+};
+
+&i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-1 = <&i2c2_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-1 = <&i2c3_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ magnetometer@1e {
+ compatible = "st,iis2mdc";
+ reg = <0x1e>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <10 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&magnetometer_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+
+ /* pressure-sensor@5c */
+
+ inertial-sensor@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&imu_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+};
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl-names = "default";
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHB_PAD 0x000514a0
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHK_PAD 0x000014a0
+ >;
+ };
+
+ dsrc_pins: pinctrl-dsrc-grp {
+ fsl,pins = <
+ /* reset: io without pull */
+ IMX8DXL_ADC_IN0_LSIO_GPIO1_IO10 0x0000060
+
+ /*
+ * boot0: io without pull
+ * After reset, this pin selects radio boot media:
+ * - 0: flash spi
+ * - 1: slave sdio
+ * Once the firmware boots however, the radio controls
+ * this pin for flow-control to signal readiness.
+ */
+ IMX8DXL_ADC_IN1_LSIO_GPIO1_IO09 0x0000060
+ >;
+ };
+
+ gnss_pins: pinctrl-gnss-grp {
+ fsl,pins = <
+ /* gps reset: input with pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT4_LSIO_GPIO2_IO08_IN 0x0000021
+ /* gps interrupt: io without pull-up */
+ IMX8DXL_SNVS_TAMPER_IN0_LSIO_GPIO2_IO09_IN 0x0000061
+ >;
+ };
+
+ gnss_pps_pins: pinctrl-gnss-pps-grp {
+ fsl,pins = <
+ /* gps timepulse: input without pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT2_LSIO_GPIO2_IO06_IN 0x0000061
+ >;
+ };
+
+ i2c2_gpio_pins: pinctrl-i2c2-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_LSIO_GPIO3_IO00 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDO_LSIO_GPIO3_IO01 0x02000021
+ >;
+ };
+
+ i2c2_pins: pinctrl-i2c2-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_ADMA_I2C2_SDA 0x06000021
+ IMX8DXL_SPI1_SDO_ADMA_I2C2_SCL 0x06000021
+ >;
+ };
+
+ i2c3_gpio_pins: pinctrl-i2c3-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_LSIO_GPIO3_IO03 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDI_LSIO_GPIO3_IO02 0x02000021
+ >;
+ };
+
+ i2c3_pins: pinctrl-i2c3-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_ADMA_I2C3_SDA 0x06000021
+ IMX8DXL_SPI1_SDI_ADMA_I2C3_SCL 0x06000021
+ >;
+ };
+
+ imu_pins: pinctrl-imu-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN2_LSIO_GPIO2_IO11_IN 0x0000041
+ >;
+ };
+
+ lpspi2_pins: pinctrl-lpspi2-grp {
+ fsl,pins = <
+ IMX8DXL_USDHC1_RESET_B_ADMA_SPI2_SCK 0x600004c
+ IMX8DXL_USDHC1_VSELECT_ADMA_SPI2_SDO 0x600004c
+ IMX8DXL_USDHC1_WP_ADMA_SPI2_SDI 0x600004c
+ IMX8DXL_USDHC1_CD_B_LSIO_GPIO4_IO22 0x6000021
+ >;
+ };
+
+ lpuart0_pins: pinctrl-lpuart0-grp {
+ fsl,pins = <
+ IMX8DXL_UART0_RX_ADMA_UART0_RX 0x06000020
+ IMX8DXL_UART0_TX_ADMA_UART0_TX 0x06000020
+ >;
+ };
+
+ lpuart2_pins: pinctrl-lpuart2-grp {
+ fsl,pins = <
+ IMX8DXL_UART2_TX_ADMA_UART2_TX 0x06000020
+ IMX8DXL_UART2_RX_ADMA_UART2_RX 0x06000020
+ >;
+ };
+
+ magnetometer_pins: pinctrl-magnetometer-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN1_LSIO_GPIO2_IO10_IN 0x0000041
+ >;
+ };
+
+ regulator_1_2_pins: pinctrl-regulator-1-2-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN5_LSIO_GPIO1_IO13 0x0000061
+ >;
+ };
+
+ regulator_1_6_pins: pinctrl-regulator-1-6-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN4_LSIO_GPIO1_IO14 0x0000061
+ >;
+ };
+
+ regulator_1_8_se_pins: pinctrl-regulator-1-8-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element power switch: io with pull-down */
+ IMX8DXL_QSPI0B_DATA0_LSIO_GPIO3_IO18 0x0000041
+ >;
+ };
+
+ se_pins: pinctrl-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element reset: io with pull-up */
+ IMX8DXL_QSPI0B_DATA1_LSIO_GPIO3_IO19 0x0000021
+
+ /*
+ * v2x-secure-element gpio0: io with pull-up
+ * pulled low by sxf after boot indicating ready for commands
+ */
+ IMX8DXL_QSPI0B_DATA2_LSIO_GPIO3_IO20 0x0000021
+
+ /* v2x-secure-element gpio1: io with pull-up */
+ IMX8DXL_QSPI0B_DATA3_LSIO_GPIO3_IO21 0x0000021
+ >;
+ };
+
+ usdhc1_pins: pinctrl-usdhc1-grp {
+ fsl,pins = <
+ IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
+ IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
+ IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
+ IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
+ IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
+ IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
+ IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
+ IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
+ IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
+ IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
+ IMX8DXL_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000061
+ >;
+ };
+
+ usdhc2_pins: pinctrl-usdhc2-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
+ >;
+ };
+};
+
+&lpspi2 {
+ cs-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
+ num-cs = <1>;
+ pinctrl-0 = <&lpspi2_pins>, <&se_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* console */
+&lpuart0 {
+ pinctrl-0 = <&lpuart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* gnss */
+&lpuart2 {
+ pinctrl-0 = <&lpuart2_pins>, <&gnss_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lsio_gpio3 {
+ gpio-line-names = "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "SXF_RST", "SXF_GPIO0", "SXF_GPIO1", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&lsio_mu5 {
+ status = "okay";
+};
+
+/* OTG port for boot */
+&usbotg1 {
+ adp-disable;
+ disable-over-current;
+ dr_mode = "peripheral";
+ hnp-disable;
+ power-active-high;
+ srp-disable;
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ bus-width = <8>;
+ cap-mmc-hw-reset;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&usdhc1_pins>;
+ pinctrl-1 = <&usdhc1_pins>;
+ pinctrl-2 = <&usdhc1_pins>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
+
+/* DSRC Radio */
+&usdhc2 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ max-frequency = <40000000>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc2_pins>, <&dsrc_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-11 10:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
Add bindings and description for SolidRUn i.MX8DXL based SoM and
HummingBoard Telematics.
Modify SJA1110 Ethernet Switch bindings to allow SPI Mode 0.
This patch-set is based on v7.0-rc2, because rc1 was experiencing
deadlocks with imx8qxp clock driver.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v4:
- picked up acked-by adnrew lunn
- Link to v3: https://lore.kernel.org/r/20260430-imx8dxl-sr-som-v3-0-ce2b86cf75bc@solid-run.com
Changes in v3:
- rebased on v7.1-rc1.
- dropped dsa swtch port labels, should be handled by udev rules if
required.
- Fixed spelling error in alias comment.
- Dropped superfluous status okay properties from switch sub-nodes.
- Link to v2: https://lore.kernel.org/r/20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com
Changes in v2:
- Dropped accidental change to unrelated imx8mp-sr-som.dtsi file.
- Fixed phy-mode on fixed link between cpu and ethernet switch.
(Reported-by: Andrew Lunn <andrew@lunn.ch>)
- Removed spi-cpol property from ethernet-switch on spi bus, fixing
sja1110a driver probe.
- Changed SJA1110 bindings to allow removing spi-cpol property.
- Aligned comments on all ethernet switch port nodes to be consistent.
- Dropped regulator-always-on from dsrc radio power-supplies.
- Link to v1: https://lore.kernel.org/r/20260408-imx8dxl-sr-som-v1-0-ce5a39acd713@solid-run.com
---
Josua Mayer (2):
dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 523 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 ++++++++++++++++++
4 files changed, 990 insertions(+)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260408-imx8dxl-sr-som-f141ec343173
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
From: Josua Mayer @ 2026-05-11 10:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
In-Reply-To: <20260511-imx8dxl-sr-som-v4-0-64381b3bf80d@solid-run.com>
Add binding for the SolidRun i.MX8DXL based System on Module, and the
reference HummingBoard Telematics.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd1268075..17cd47e8efce8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1394,6 +1394,13 @@ properties:
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
- const: fsl,imx8dxl
+ - description: SolidRun i.MX8DXL SoM based boards
+ items:
+ - enum:
+ - solidrun,imx8dxl-hummingboard-telematics # SolidRun i.MX8DXL SoM EVK Board
+ - const: solidrun,imx8dxl-sr-som
+ - const: fsl,imx8dxl
+
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
items:
- enum:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 0/3] Enable CTCU and ETR devices for multiple QCOM platforms
From: Jie Gan @ 2026-05-11 10:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Suzuki K Poulose, Mike Leach,
James Clark, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-arm-msm, devicetree,
linux-kernel, Konrad Dybcio
In-Reply-To: <545b4ebb-2c7e-480d-80bb-5e08dd3c52a7@arm.com>
Hi Bjorn/Konrad
On 2/27/2026 6:10 PM, Suzuki K Poulose wrote:
> Hello,
>
>
> On 04/02/2026 02:22, Jie Gan wrote:
>> The DT‑binding patch adds platform‑specific compatibles for the
>> CTCU device, and the following Qualcomm platforms are included:
>> Kaanapali
>> Pakala(sm8750)
>> Hamoa(x1e80100)
>> Glymur
>
> Given this is predominantly DTS changes, and there is very low chances
> of a conflict with the binding yaml change, I would recommend this to go
> via soc or the qcom platform tree.
>
> For the series:
>
> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
Gentle reminder as Suzuki's proposal.
Thanks,
Jie
>
>>
>> Since the base Coresight DT patches for the Kaanapali and Glymur
>> platforms have not yet been applied, I created DT patches only
>> for the Pakala and Hamoa platforms. I will submit the Kaanapali
>> and Glymur patches once their corresponding base Coresight DT patches
>> are merged.
>>
>> The Hamoa‑related patches were posted in a separate email, and I
>> have included them in the current patch series.
>>
>> Link to the previous Hamoa patch series:
>> https://lore.kernel.org/all/20251106-enable-etr-and-ctcu-for-hamoa-
>> v2-0-cdb3a18753aa@oss.qualcomm.com/
>>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>> Changes in v3:
>> - change back to the numeric compatible from hamoa to x1e80100.
>> - Link to v2: https://lore.kernel.org/r/20260203-enable-ctcu-and-etr-
>> v2-0-aacc7bd7eccb@oss.qualcomm.com
>>
>> Changes in v2:
>> - change back to the numeric compatible from pakala to sm8750.
>> - Link to v1: https://lore.kernel.org/r/20260203-enable-ctcu-and-etr-
>> v1-0-a5371a2ec2b8@oss.qualcomm.com
>>
>> ---
>> Jie Gan (3):
>> dt-binding: document QCOM platforms for CTCU device
>> arm64: dts: qcom: hamoa: enable ETR and CTCU devices
>> arm64: dts: qcom: sm8750: enable ETR and CTCU devices
>>
>> .../bindings/arm/qcom,coresight-ctcu.yaml | 4 +
>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 160 +++++++++++
>> +++++++-
>> arch/arm64/boot/dts/qcom/sm8750.dtsi | 177 +++++++++++
>> ++++++++++
>> 3 files changed, 340 insertions(+), 1 deletion(-)
>> ---
>> base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
>> change-id: 20260203-enable-ctcu-and-etr-31f9e9d1088d
>>
>> Best regards,
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: verisilicon,dc: generalize for DCUltra Lite variant
From: Icenowy Zheng @ 2026-05-11 9:59 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511075142.54752-2-a0987203069@gmail.com>
在 2026-05-11一的 15:51 +0800，Joey Lu写道：
> Extend the verisilicon,dc base schema to accommodate the Nuvoton
> MA35D1
> DCUltra Lite (a previous generation of the DC8000 series) which has a
> different clock topology, no reset control, and a single output.
>
> - Replace the fixed clock/reset item lists with minItems/maxItems
> ranges
> so sub-schemas can enforce variant-specific constraints
> - Add a 'port' property (single-port alias) alongside the existing
> 'ports'
> for single-output variants
> - Remove the mandatory 'ports' requirement from the base schema; sub-
> schemas
> shall enforce their own port topology
> - Add a 'select' stanza so the validator matches any node whose
> compatible
> contains a known Verisilicon DC string, including SoC-specific glue
> - Relax additionalProperties to allow unevaluatedProperties
> enforcement in
> sub-schemas
> - Fix a minor whitespace issue in the port@0 description
>
> Add nuvoton,ma35d1-dcu.yaml as a sub-schema for the Nuvoton MA35D1
> DCUltra
> Lite display controller:
>
> The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
> controller. It is a single-output display controller with a 32-bit
> RGB (DPI) interface. Unlike the DC8000, it does not have discoverable
> chip identity registers, does not support the CONFIG_EX commit path,
> and uses dedicated IRQ status/enable registers at offsets
> 0x147C/0x1480.
> The clock topology uses two clocks (bus gate and pixel divider) and
> does not require explicit reset control from the driver.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/display/nuvoton,ma35d1-dcu.yaml | 94
> +++++++++++++++++++
> .../bindings/display/verisilicon,dc.yaml | 64 +++++++------
> 2 files changed, 131 insertions(+), 27 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
> b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
> new file mode 100644
> index 000000000000..9279004ae27c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-
> dcu.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/nuvoton,ma35d1-dcu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nuvoton MA35D1 DCUltra Lite display controller
> +
> +maintainers:
> + - Joey Lu <yclu4@nuvoton.com>
> +
> +description:
> + The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
> + controller. It is a single-output display controller with a 32-bit
> + RGB (DPI) interface.
You'd better write this in verisilicon,dc.yaml with if clauses. See
Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml for an
example for a generic IP with different integrations, and how it
constraints different SoC's integration.
> +
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nuvoton,ma35d1-dcu
> + required:
> + - compatible
> +
> +allOf:
> + - $ref: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
> +
> +properties:
> + compatible:
> + const: nuvoton,ma35d1-dcu
> +
> + reg:
> + maxItems: 1
> + description:
> + Register range of the DCUltra Lite controller. The address
> space
> + is 0x2000 bytes.
Is it really 0x2000 bytes? The next peripherals in the address space,
the GC520L 2D GPU, is 0x20000 bytes away from the start of DCU
registers space.
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: Bus clock that gates register access (DCU_GATE)
> + - description: Pixel clock divider for display timing
> (DCUP_DIV)
> +
> + clock-names:
> + items:
> + - const: core
> + - const: pix0
> +
> + resets:
> + maxItems: 1
> + description:
> + Optional reset for the display controller. The driver does not
> + assert or deassert this reset; it may be used by firmware or
> + boot loaders to bring the hardware to a clean state.
Why is there a reset in hardware but not toggled in the software?
> +
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Output port to the downstream display device (e.g. RGB panel).
> + The DCUltra Lite supports a single parallel RGB output.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
> +
> + display@40260000 {
> + compatible = "nuvoton,ma35d1-dcu";
> + reg = <0x40260000 0x2000>;
> + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>;
> + clock-names = "core", "pix0";
> + resets = <&sys MA35D1_RESET_DISP>;
> +
> + port {
> + dpi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> diff --git
> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> index 9dc35ab973f2..00884529f8c1 100644
> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> @@ -9,15 +9,34 @@ title: Verisilicon DC-series display controllers
> maintainers:
> - Icenowy Zheng <uwu@icenowy.me>
>
> +description:
> + Verisilicon DC-series display controllers.
> +
> +# Select any node whose compatible contains one of the known
> Verisilicon DC
> +# or DC-derived compatible strings, including SoC-specific glue
> variants.
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - verisilicon,dc
> + - thead,th1520-dc8200
> + - nuvoton,ma35d1-dcu
> + required:
> + - compatible
> +
> properties:
> $nodename:
> pattern: "^display@[0-9a-f]+$"
>
> compatible:
> - items:
> - - enum:
> - - thead,th1520-dc8200
> - - const: verisilicon,dc # DC IPs have discoverable ID/revision
> registers
> + # Enumerated in full so the schema validator can verify any
> compatible
> + # string against this list, including those from child schemas.
> + contains:
> + enum:
> + - verisilicon,dc
> + - thead,th1520-dc8200
> + - nuvoton,ma35d1-dcu
>
> reg:
> maxItems: 1
> @@ -26,32 +45,24 @@ properties:
> maxItems: 1
>
> clocks:
> - items:
> - - description: DC Core clock
> - - description: DMA AXI bus clock
> - - description: Configuration AHB bus clock
> - - description: Pixel clock of output 0
> - - description: Pixel clock of output 1
> + minItems: 2
> + maxItems: 5
>
> clock-names:
> - items:
> - - const: core
> - - const: axi
> - - const: ahb
> - - const: pix0
> - - const: pix1
> + minItems: 2
> + maxItems: 5
>
> resets:
> - items:
> - - description: DC Core reset
> - - description: DMA AXI bus reset
> - - description: Configuration AHB bus reset
> + minItems: 1
> + maxItems: 3
>
> reset-names:
> - items:
> - - const: core
> - - const: axi
> - - const: ahb
> + minItems: 1
> + maxItems: 3
> +
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Single video output port for single-output
> variants.
>
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
> @@ -59,7 +70,7 @@ properties:
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description: The first output channel , endpoint 0 should be
> + description: The first output channel, endpoint 0 should be
> used for DPI format output and endpoint 1 should be used
> for DP format output.
>
> @@ -75,9 +86,8 @@ required:
> - interrupts
> - clocks
> - clock-names
> - - ports
>
> -additionalProperties: false
> +additionalProperties: true
>
> examples:
> - |
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: hamoa-iot-som: Add pm8010 L4M regulator
From: Konrad Dybcio @ 2026-05-11 9:58 UTC (permalink / raw)
To: Wenmeng Liu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bryan O'Donoghue,
Vladimir Zapolskiy, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Mauro Carvalho Chehab
Cc: linux-arm-msm, devicetree, linux-kernel, imx, linux-arm-kernel,
linux-media, Tingguo Cheng
In-Reply-To: <20260508-hamoa_evk-v2-6-3ebdca3e4ae2@oss.qualcomm.com>
On 5/8/26 1:40 PM, Wenmeng Liu wrote:
> From: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com>
>
> Add pm8010 L4M regulator which is used by Camera I2C pull-up.
What about other regulators on that PMIC?
Konrad
^ permalink raw reply
* Re: [PATCH] ARM: Do not select HAVE_RUST when KASAN is enabled
From: Miguel Ojeda @ 2026-05-11 9:58 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Alice Ryhl, Russell King, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Christian Schrrefl,
linux-arm-kernel, linux-kernel, rust-for-linux, stable
In-Reply-To: <20260511090943.GA1029560@ax162>
On Mon, May 11, 2026 at 11:09 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Sure, I kept it simple for backporting purposes but I don't mind
> breaking out the dependencies into their own symbol, even though it
> feels like that could be done when support for the sanitizer is
> re-enabled, which would truly mirror what you did. No strong opinion
> though, so I will send a v2 after giving some time for other comments.
I think it is fine either way, especially for a fix, but up to the
KASAN/arm maintainers of course.
Thanks for the patch!
If KASAN or arm maintainers want to pick it up:
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Otherwise I can send it in a fixes PR I will likely need to send later
this cycle, so please let me know!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 5/7] arm64: dts: qcom: hamoa: Add camera MCLK pinctrl
From: Konrad Dybcio @ 2026-05-11 9:58 UTC (permalink / raw)
To: Wenmeng Liu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bryan O'Donoghue,
Vladimir Zapolskiy, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Mauro Carvalho Chehab
Cc: linux-arm-msm, devicetree, linux-kernel, imx, linux-arm-kernel,
linux-media
In-Reply-To: <20260508-hamoa_evk-v2-5-3ebdca3e4ae2@oss.qualcomm.com>
On 5/8/26 1:40 PM, Wenmeng Liu wrote:
> Define pinctrl definitions to enable camera master clocks on hamoa.
>
> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-05-11 9:55 UTC (permalink / raw)
To: Jinjie Ruan
Cc: will, punit.agrawal, rafael.j.wysocki, fengchengwen, chenl311,
suzuki.poulose, maz, timothy.hayes, lpieralisi, mrigendra.chaubey,
arnd, sudeep.holla, yangyicong, jic23, pierre.gondois,
linux-arm-kernel, linux-kernel, james.morse
In-Reply-To: <54093ddf-e237-4cc0-9fe1-2989916c1f72@huawei.com>
On Mon, May 11, 2026 at 11:17:43AM +0800, Jinjie Ruan wrote:
> On 4/27/2026 10:35 AM, Jinjie Ruan wrote:
> > On arm64, when booting with `maxcpus` greater than the number of present
> > CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
> > but have not yet been registered via register_cpu(). Consequently,
> > the per-cpu device objects for these CPUs are not yet initialized.
> >
> > In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
> > _cpu_up() for these unregistered CPUs eventually leads to
> > sysfs_create_group() being called with a NULL kobject (or a kobject
> > without a directory), triggering the following warning in
> > fs/sysfs/group.c:
> >
> > if (WARN_ON(!kobj || (!update && !kobj->sd)))
> > return -EINVAL;
> >
> > When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
> > enumerated CPUs as "present" regardless of their status in the MADT. This
> > causes issues with SMT hotplug control. For instance, with QEMU's
> > "-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
> > follows: the first four CPUs are marked Enabled while the remaining four
> > are marked Online Capable to support potential hot-plugging.
> >
> > Fix this by:
> >
> > 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
> > entry before calling set_cpu_present() during SMP initialization.
> >
> > 2. Properly managing the present mask in acpi_map_cpu() and
> > acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
> > other architectures like x86 and LoongArch.
> >
> > This ensures that only physically available or explicitly enabled CPUs
> > are in the present mask, keeping the SMT control logic consistent with
> > the actual hardware state.
> >
> > How to reproduce:
> >
> > 1. echo off > /sys/devices/system/cpu/smt/control
> > psci: CPU1 killed (polled 0 ms)
> > psci: CPU3 killed (polled 0 ms)
> >
> > 2. echo 2 > /sys/devices/system/cpu/smt/control
> >
> > Detected PIPT I-cache on CPU1
> > GICv3: CPU1: found redistributor 1 region 0:0x00000000080c0000
> > CPU1: Booted secondary processor 0x0000000001 [0x410fd082]
> > Detected PIPT I-cache on CPU3
> > GICv3: CPU3: found redistributor 3 region 0:0x0000000008100000
> > CPU3: Booted secondary processor 0x0000000003 [0x410fd082]
> > ------------[ cut here ]------------
> > WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
> > Modules linked in:
> > CPU: 2 UID: 0 PID: 181 Comm: sh Not tainted 7.0.0-rc1-00010-g8d13386c7624 #142 PREEMPT
> > Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> > pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : internal_create_group+0x41c/0x4bc
> > lr : sysfs_create_group+0x18/0x24
> > sp : ffff80008078ba40
> > x29: ffff80008078ba40 x28: ffff296c980ad000 x27: ffff00007fb94128
> > x26: 0000000000000054 x25: ffffd693e845f3f0 x24: 0000000000000001
> > x23: 0000000000000001 x22: 0000000000000004 x21: 0000000000000000
> > x20: ffffd693e845fc10 x19: 0000000000000004 x18: 00000000ffffffff
> > x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > x14: 0000000000000358 x13: 0000000000000007 x12: 0000000000000350
> > x11: 0000000000000008 x10: 0000000000000407 x9 : 0000000000000400
> > x8 : ffff00007fbf3b60 x7 : 0000000000000000 x6 : ffffd693e845f3f0
> > x5 : ffff00007fb94128 x4 : 0000000000000000 x3 : ffff000000f4eac0
> > x2 : ffffd693e7095a08 x1 : 0000000000000000 x0 : 0000000000000000
> > Call trace:
> > internal_create_group+0x41c/0x4bc (P)
> > sysfs_create_group+0x18/0x24
> > topology_add_dev+0x1c/0x28
> > cpuhp_invoke_callback+0x104/0x20c
> > __cpuhp_invoke_callback_range+0x94/0x11c
> > _cpu_up+0x200/0x37c
> > cpuhp_smt_enable+0xbc/0x114
> > control_store+0xe8/0x1d4
> > dev_attr_store+0x18/0x2c
> > sysfs_kf_write+0x7c/0x94
> > kernfs_fop_write_iter+0x128/0x1b8
> > vfs_write+0x2b0/0x354
> > ksys_write+0x68/0xfc
> > __arm64_sys_write+0x1c/0x28
> > invoke_syscall+0x48/0x10c
> > el0_svc_common.constprop.0+0x40/0xe8
> > do_el0_svc+0x20/0x2c
> > el0_svc+0x34/0x124
> > el0t_64_sync_handler+0xa0/0xe4
> > el0t_64_sync+0x198/0x19c
> > ---[ end trace 0000000000000000 ]---
>
> Hi, just a gentle ping on this v2 patch. It’s been about two weeks, and
> I was wondering if there are any further comments or if there's anything
> else I should address? Thanks!
No comments from me but I'd like James Morse to review, in case he
recalls the decisions made at the time. I think Jonathan already said
that he doesn't fully remember.
Given that it's just a warning rather than some kernel panic, I'm happy
to wait until the upcoming merging window (for 7.2). In the meantime:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: verisilicon,dc: generalize for DCUltra Lite variant
From: Rob Herring (Arm) @ 2026-05-11 9:49 UTC (permalink / raw)
To: Joey Lu
Cc: maarten.lankhorst, devicetree, yclu4, simona, ychuang3,
tzimmermann, krzk+dt, zhengxingda, schung, linux-arm-kernel,
linux-kernel, conor+dt, mripard, airlied, dri-devel
In-Reply-To: <20260511075142.54752-2-a0987203069@gmail.com>
On Mon, 11 May 2026 15:51:41 +0800, Joey Lu wrote:
> Extend the verisilicon,dc base schema to accommodate the Nuvoton MA35D1
> DCUltra Lite (a previous generation of the DC8000 series) which has a
> different clock topology, no reset control, and a single output.
>
> - Replace the fixed clock/reset item lists with minItems/maxItems ranges
> so sub-schemas can enforce variant-specific constraints
> - Add a 'port' property (single-port alias) alongside the existing 'ports'
> for single-output variants
> - Remove the mandatory 'ports' requirement from the base schema; sub-schemas
> shall enforce their own port topology
> - Add a 'select' stanza so the validator matches any node whose compatible
> contains a known Verisilicon DC string, including SoC-specific glue
> - Relax additionalProperties to allow unevaluatedProperties enforcement in
> sub-schemas
> - Fix a minor whitespace issue in the port@0 description
>
> Add nuvoton,ma35d1-dcu.yaml as a sub-schema for the Nuvoton MA35D1 DCUltra
> Lite display controller:
>
> The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
> controller. It is a single-output display controller with a 32-bit
> RGB (DPI) interface. Unlike the DC8000, it does not have discoverable
> chip identity registers, does not support the CONFIG_EX commit path,
> and uses dedicated IRQ status/enable registers at offsets 0x147C/0x1480.
> The clock topology uses two clocks (bus gate and pixel divider) and
> does not require explicit reset control from the driver.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/display/nuvoton,ma35d1-dcu.yaml | 94 +++++++++++++++++++
> .../bindings/display/verisilicon,dc.yaml | 64 +++++++------
> 2 files changed, 131 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml: allOf:0:$ref: 'http://devicetree.org/schemas/display/verisilicon,dc.yaml#' should not be valid under {'pattern': '^https?://'}
hint: References must start with '/schemas' or be relative to current schema's path.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260511075142.54752-2-a0987203069@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to host
From: Chen-Yu Tsai @ 2026-05-11 9:49 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Matthias Brugger, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <177849219930.115964.12285046748812181326.b4-ty@collabora.com>
On Mon, May 11, 2026 at 5:36 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> On Thu, 30 Apr 2026 20:07:24 +0800, Chen-Yu Tsai wrote:
> > The DMA bounce buffer is attached to the PCIe host controller, i.e. all
> > PCIe DMA transfers should use it.
> >
> > Move it from the PCIe (WiFi) device node down to the PCIe host
> > controller node.
> >
> >
> > [...]
>
> Applied to v7.1-next/dts64, thanks!
>
> [1/1] arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to host
> commit: 0f91911b61d06fc02a058ff7fb0a27e53f7b1136
Sorry, but we actually have to wait for a matching binding change [1] to
land, or we'll get new DT warnings.
ChenYu
[1] https://lore.kernel.org/all/20260508063633.3894348-1-wenst@chromium.org/
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8390-tungsten-smarc: add HDMI support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Gary Bisson
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260310-mtkhdmi-v1-1-841e834c8abc@gmail.com>
On Tue, 10 Mar 2026 16:20:13 +0100, Gary Bisson wrote:
> Add HDMI display out support to both Tungsten510 & Tungsten700
> platforms. HDMI audio is not covered by this patch, audio (HDMI & I2S)
> will be added as a follow-up patch.
>
>
Applied to v7.1-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8390-tungsten-smarc: add HDMI support
commit: a74ceec38c76901baa2fc09a1a744689b696a01a
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Icenowy Zheng @ 2026-05-11 9:47 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511075142.54752-3-a0987203069@gmail.com>
在 2026-05-11一的 15:51 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltra Lite display
> controller, which is a previous generation of the DC8000 series.
> While
> the general register layout is similar to the DC8000, there are
> several
> key differences that require per-variant handling in the driver.
>
> Add a vs_dc_info platform data structure (in vs_hwdb.h) to describe
> per-IP-variant capabilities, and use it throughout the driver to
> select
> the correct code paths at runtime.
>
> Key differences between DC8000 and DCUltra Lite handled:
What the driver supports now is DC8200, DC8000 have the following point
1~4 the same with DCUltraLite (different to DC8200).
>
> 1. No chip identity registers (0x0020-0x0030): DCUltra Lite uses
> static
> platform data instead of reading model/revision/customer_id from
> HW.
My test shows that revision and customer_id is correctly present, only
model is 0 -- I think this can be also considered as a valid model
value because the IP name has also no model number.
The revision number is 0x5560 and customer id is 0x305 .
>
> 2. No CONFIG_EX commit mechanism: DC8000 uses registers at 0x1CC0
> (FB_CONFIG_EX), 0x24D8 (FB_TOP_LEFT), 0x24E0 (FB_BOTTOM_RIGHT),
> 0x2510 (FB_BLEND_CONFIG), 0x2518 (PANEL_CONFIG_EX). DCUltra Lite
> omits all of these and instead uses enable/reset bits in FB_CONFIG
> (bit 0 = enable, bit 4 = reset) for direct framebuffer updates.
>
> 3. No PANEL_START register (0x1CCC): DCUltra Lite panel output starts
> when PANEL_CONFIG.RUNNING is set; no separate multi-display sync
> start register is needed.
>
> 4. Different IRQ registers: DCUltra Lite uses 0x147C (IRQ_STA) /
> 0x1480 (IRQ_EN); DC8000 uses 0x0010 (IRQ_ACK) / 0x0014 (IRQ_EN).
>
> 5. Different clock/reset topology: DCUltra Lite requires only "core"
> (bus gate) and "pix0" (pixel divider) clocks with no reset lines
> managed by the driver. DC8000 needs core/axi/ahb clocks and three
> resets.
It's possible that your SoC integration combines core clock gate with
bus clock gate instead of bus clock gate not existing.
>
> 6. Single output only: DCUltra Lite has one display output; per-
> output
> index logic is still in place but display_count is fixed at 1.
>
> 7. Reduced register space: max_register is 0x2000 vs DC8000's 0x2544.
>
> Add the "nuvoton,ma35d1-dcu" compatible string to the OF match table,
> extend Kconfig to allow building on ARCH_MA35 platforms, and expose
> vs_formats_no_yuv444 as the default format table for DCUltra Lite
> (YUV444 blending is a DC8000-only feature).
>
> All changes have been tested on Nuvoton MA35D1 hardware and are
> functioning correctly.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> drivers/gpu/drm/verisilicon/vs_bridge.c | 28 ++--
> drivers/gpu/drm/verisilicon/vs_crtc.c | 13 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 129 ++++++++++++----
> --
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_drm.c | 16 ++-
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 2 +-
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 25 ++++
> .../gpu/drm/verisilicon/vs_primary_plane.c | 43 +++---
> .../drm/verisilicon/vs_primary_plane_regs.h | 2 +
> 10 files changed, 187 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig
> b/drivers/gpu/drm/verisilicon/Kconfig
> index 7cce86ec8603..295d246eb4b4 100644
> --- a/drivers/gpu/drm/verisilicon/Kconfig
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_VERISILICON_DC
> tristate "DRM Support for Verisilicon DC-series display
> controllers"
> depends on DRM && COMMON_CLK
> - depends on RISCV || COMPILE_TEST
> + depends on RISCV || ARCH_MA35 || COMPILE_TEST
> select DRM_BRIDGE_CONNECTOR
> select DRM_CLIENT_SELECTION
> select DRM_DISPLAY_HELPER
> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
> b/drivers/gpu/drm/verisilicon/vs_bridge.c
> index 7a93049368db..225af322de32 100644
> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> @@ -164,13 +164,16 @@ static void vs_bridge_enable_common(struct
> vs_crtc *crtc,
> VSDC_DISP_PANEL_CONFIG_CLK_EN);
> regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> VSDC_DISP_PANEL_CONFIG_RUNNING);
> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_RUNNING(output));
>
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
> >id),
> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> + if (dc->info->has_config_ex) {
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> +
> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> + VSDC_DISP_PANEL_START_RUNNING(output
> ));
> +
> + regmap_set_bits(dc->regs,
> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
Should the commit operation happen on DC8000/DCUltraLite too? (By
writing to DcregFrameBufferConfig0.VALID).
Many registers written has "Note: This field is double buffered" in the
DCUltraLite documentation.
I suggest create a static function for commit -- write to the
corresponding commit bit on DC8200, and write to
DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
> + }
> }
>
> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
> @@ -228,14 +231,17 @@ static void vs_bridge_atomic_disable(struct
> drm_bridge *bridge,
> struct vs_dc *dc = crtc->dc;
> unsigned int output = crtc->id;
>
> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
> - VSDC_DISP_PANEL_START_RUNNING(output));
> regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> VSDC_DISP_PANEL_CONFIG_RUNNING);
This bit seems to be not present in DCUltraLite, instead should
DcregFrameBufferConfig0.RESET be clear, which will stall the DPI
timing?
>
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
> >id),
> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> + if (dc->info->has_config_ex) {
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> +
> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
> +
> VSDC_DISP_PANEL_START_RUNNING(output));
> +
> + regmap_set_bits(dc->regs,
> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> + }
Ditto.
> }
>
> static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
> b/drivers/gpu/drm/verisilicon/vs_crtc.c
> index 9080344398ca..2f3e6d41c657 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> @@ -18,6 +18,7 @@
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> +#include "vs_hwdb.h"
> #include "vs_plane.h"
>
> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -132,7 +133,11 @@ static int vs_crtc_enable_vblank(struct drm_crtc
> *crtc)
> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
> + regmap_write(dc->regs, VSDC_DISP_IRQ_EN, BIT(0));
Should `BIT(0)` be assigned with a named macro here, like
`VSDC_DISP_IRQ_VSYNC(0)` ?
In addition, even it's known that DC8000/DCUltraLite has only one
output, hardcoding 0 here isn't so good. The header file at [1] (which
is for DC8000) shows that two display interrupts and more other
interrupts are present.
BTW I don't like the idea of setting a "family" (because DC8000 behave
nearly the same with DCUltraLite), maybe use `.irq_reg = VSDC_DISP_IRQ`
(or a bool variable named `uses_top_irq`) is better?
[1]
https://github.com/milkv-megrez/rockos-u-boot/blob/c9221cf2fa77d39c0b241ab4b030c708e7ebe279/drivers/video/eswin/eswin_dc_reg.h#L2771
> + else
> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>
> return 0;
> }
> @@ -142,7 +147,11 @@ static void vs_crtc_disable_vblank(struct
> drm_crtc *crtc)
> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
> + regmap_write(dc->regs, VSDC_DISP_IRQ_EN, 0);
> + else
> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(vcrtc->id));
> }
>
> static const struct drm_crtc_funcs vs_crtc_funcs = {
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index dad9967bc10b..82a6a26f6d81 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -9,21 +9,45 @@
> #include <linux/of_graph.h>
>
> #include "vs_crtc.h"
> +#include "vs_crtc_regs.h"
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> #include "vs_hwdb.h"
>
> -static const struct regmap_config vs_dc_regmap_cfg = {
> +static const struct regmap_config vs_dc8000_regmap_cfg = {
As what I said, the currently supported thing is DC8200, not DC8000.
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = sizeof(u32),
> - /* VSDC_OVL_CONFIG_EX(1) */
> .max_register = 0x2544,
> };
>
> +static const struct regmap_config vs_dcultra_lite_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 0x2000,
> +};
> +
> +static const struct vs_dc_info vs_dc8000_info = {
> + .family = VS_DC_FAMILY_DC8000,
> + .has_chip_id = true,
> + .has_config_ex = true,
> + .regmap_cfg = &vs_dc8000_regmap_cfg,
> +};
> +
> +static const struct vs_dc_info vs_dcultra_lite_info = {
> + .family = VS_DC_FAMILY_DCULTRA_LITE,
> + .display_count = 1,
> + .has_chip_id = false,
> + .has_config_ex = false,
> + .regmap_cfg = &vs_dcultra_lite_regmap_cfg,
> + .formats = &vs_formats_no_yuv444,
> +};
> +
> static const struct of_device_id vs_dc_driver_dt_match[] = {
> - { .compatible = "verisilicon,dc" },
> + { .compatible = "verisilicon,dc", .data = &vs_dc8000_info },
"verisilicon,dc" is expected for DC8000 and 8200, and because of model,
rev and customer_id values are all present for DCUltraLite, the special
data might be dropped?
> + { .compatible = "nuvoton,ma35d1-dcu", .data =
> &vs_dcultra_lite_info },
> {},
> };
> MODULE_DEVICE_TABLE(of, vs_dc_driver_dt_match);
> @@ -33,6 +57,13 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
> *private)
> struct vs_dc *dc = private;
> u32 irqs;
>
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
Maybe add an item in the hwdb for the IRQ register?
> + if (irqs & BIT(0))
> + vs_drm_handle_irq(dc,
> VSDC_TOP_IRQ_VSYNC(0));
> + return IRQ_HANDLED;
Now I think for DC8200, the irq number decoding should be done here
too.
> + }
> +
> regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>
> vs_drm_handle_irq(dc, irqs);
> @@ -43,6 +74,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
> *private)
> static int vs_dc_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> + const struct vs_dc_info *info;
> struct vs_dc *dc;
> void __iomem *regs;
> unsigned int port_count, i;
> @@ -55,6 +87,10 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return -ENODEV;
> }
>
> + info = of_device_get_match_data(dev);
> + if (!info)
> + return -ENODEV;
> +
> port_count = of_graph_get_port_count(dev->of_node);
> if (!port_count) {
> dev_err(dev, "can't find DC downstream ports\n");
> @@ -75,15 +111,31 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> if (!dc)
> return -ENOMEM;
>
> - dc->rsts[0].id = "core";
> - dc->rsts[1].id = "axi";
> - dc->rsts[2].id = "ahb";
> + dc->info = info;
>
> - ret = devm_reset_control_bulk_get_optional_shared(dev,
> VSDC_RESET_COUNT,
> - dc->rsts);
> - if (ret) {
> - dev_err(dev, "can't get reset lines\n");
> - return ret;
> + if (info->family == VS_DC_FAMILY_DC8000) {
> + dc->rsts[0].id = "core";
> + dc->rsts[1].id = "axi";
> + dc->rsts[2].id = "ahb";
> +
> + ret =
> devm_reset_control_bulk_get_optional_shared(dev,
> + VSDC_RESET_COUNT, dc->rsts);
> + if (ret) {
> + dev_err(dev, "can't get reset lines\n");
> + return ret;
> + }
> +
> + dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + if (IS_ERR(dc->axi_clk)) {
> + dev_err(dev, "can't get axi clock\n");
> + return PTR_ERR(dc->axi_clk);
> + }
> +
> + dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> + if (IS_ERR(dc->ahb_clk)) {
> + dev_err(dev, "can't get ahb clock\n");
> + return PTR_ERR(dc->ahb_clk);
> + }
Please make these clocks optional, instead of wrap them in a "family
detection". The resets are already optional, see above.
> }
>
> dc->core_clk = devm_clk_get_enabled(dev, "core");
> @@ -92,28 +144,18 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> - if (IS_ERR(dc->axi_clk)) {
> - dev_err(dev, "can't get axi clock\n");
> - return PTR_ERR(dc->axi_clk);
> - }
> -
> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> - if (IS_ERR(dc->ahb_clk)) {
> - dev_err(dev, "can't get ahb clock\n");
> - return PTR_ERR(dc->ahb_clk);
> - }
> -
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(dev, "can't get irq\n");
> return irq;
> }
>
> - ret = reset_control_bulk_deassert(VSDC_RESET_COUNT, dc-
> >rsts);
> - if (ret) {
> - dev_err(dev, "can't deassert reset lines\n");
> - return ret;
> + if (info->family == VS_DC_FAMILY_DC8000) {
> + ret = reset_control_bulk_deassert(VSDC_RESET_COUNT,
> dc->rsts);
> + if (ret) {
> + dev_err(dev, "can't deassert reset
> lines\n");
> + return ret;
> + }
> }
>
> regs = devm_platform_ioremap_resource(pdev, 0);
> @@ -123,23 +165,30 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> goto err_rst_assert;
> }
>
> - dc->regs = devm_regmap_init_mmio(dev, regs,
> &vs_dc_regmap_cfg);
> + dc->regs = devm_regmap_init_mmio(dev, regs, info-
> >regmap_cfg);
> if (IS_ERR(dc->regs)) {
> ret = PTR_ERR(dc->regs);
> goto err_rst_assert;
> }
>
> - ret = vs_fill_chip_identity(dc->regs, &dc->identity);
> - if (ret)
> - goto err_rst_assert;
> + if (info->has_chip_id) {
> + ret = vs_fill_chip_identity(dc->regs, &dc-
> >identity);
> + if (ret)
> + goto err_rst_assert;
>
> - dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> - dc->identity.revision, dc->identity.customer_id);
> + dev_info(dev, "Found DC%x rev %x customer %x\n",
> + dc->identity.model, dc->identity.revision,
> + dc->identity.customer_id);
>
> - if (port_count > dc->identity.display_count) {
> - dev_err(dev, "too many downstream ports than HW
> capability\n");
> - ret = -EINVAL;
> - goto err_rst_assert;
> + if (port_count > dc->identity.display_count) {
> + dev_err(dev, "too many downstream ports than
> HW capability\n");
> + ret = -EINVAL;
> + goto err_rst_assert;
> + }
> + } else {
> + /* Fill identity from platform data */
> + dc->identity.display_count = info->display_count;
> + dc->identity.formats = info->formats;
> }
>
> for (i = 0; i < dc->identity.display_count; i++) {
> @@ -168,7 +217,8 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return 0;
>
> err_rst_assert:
> - reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> + if (info->family == VS_DC_FAMILY_DC8000)
> + reset_control_bulk_assert(VSDC_RESET_COUNT, dc-
> >rsts);
> return ret;
> }
>
> @@ -180,7 +230,8 @@ static void vs_dc_remove(struct platform_device
> *pdev)
>
> dev_set_drvdata(&pdev->dev, NULL);
>
> - reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> + if (dc->info->family == VS_DC_FAMILY_DC8000)
> + reset_control_bulk_assert(VSDC_RESET_COUNT, dc-
> >rsts);
> }
>
> static void vs_dc_shutdown(struct platform_device *pdev)
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index ed1016f18758..f0613519af37 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -31,6 +31,7 @@ struct vs_dc {
> struct clk *pix_clk[VSDC_MAX_OUTPUTS];
> struct reset_control_bulk_data rsts[VSDC_RESET_COUNT];
>
> + const struct vs_dc_info *info;
> struct vs_drm_dev *drm_dev;
> struct vs_chip_identity identity;
> };
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c
> b/drivers/gpu/drm/verisilicon/vs_drm.c
> index fd259d53f49f..ff0fc6673006 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.c
> @@ -27,6 +27,7 @@
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> +#include "vs_hwdb.h"
>
> #define DRIVER_NAME "verisilicon"
> #define DRIVER_DESC "Verisilicon DC-series display controller
> driver"
> @@ -72,12 +73,19 @@ static struct drm_mode_config_helper_funcs
> vs_mode_config_helper_funcs = {
> .atomic_commit_tail = drm_atomic_helper_commit_tail,
> };
>
> -static void vs_mode_config_init(struct drm_device *drm)
> +static void vs_mode_config_init(struct drm_device *drm, struct vs_dc
> *dc)
> {
> drm->mode_config.min_width = 0;
> drm->mode_config.min_height = 0;
> - drm->mode_config.max_width = 8192;
> - drm->mode_config.max_height = 8192;
> +
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
> + drm->mode_config.max_width = 1920;
> + drm->mode_config.max_height = 1080;
Surely only max width 1920 and max height 1080? Can a display of
1080x1920 (e.g. a portrait DSI panel behind a RGB2DSI bridge) be
supported? Can a 2170x60 display (MacBook Touch Bar panel, also a DSI
panel) be supported? Both displays here will have no higher pixel clock
than 1080p in the same refresh rate, although the width / height is
higher than your restriction.
In addition, these parameters decide how big a FB can be created -- the
FB might be scaned out by multiple devices (e.g. a USB DisplayLink
device scanning out the remaining part). The stride register is said to
have 17-bit width in the MA35D1 TRM, so the possible FB width could be
quite high -- assume the 17th bit is only for the value with one 1 and
all remaining 0, we get 65536 bytes stride; with 4-byte-per-pixel
divided this gets 16384 pixels -- the htotal/hdisplay/vtotal/vdisplay
fields in the manual has 15-bit field width, which can reach 32767.
I strongly suggest leave the original values here.
> + } else {
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + }
> +
> drm->mode_config.funcs = &vs_mode_config_funcs;
> drm->mode_config.helper_private =
> &vs_mode_config_helper_funcs;
> }
> @@ -125,7 +133,7 @@ int vs_drm_initialize(struct vs_dc *dc, struct
> platform_device *pdev)
> if (ret)
> return ret;
>
> - vs_mode_config_init(drm);
> + vs_mode_config_init(drm, dc);
>
> /* Enable connectors polling */
> drm_kms_helper_poll_init(drm);
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 09336af0900a..39402d75d841 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -78,7 +78,7 @@ static const u32 vs_formats_array_with_yuv444[] = {
> /* TODO: non-RGB formats */
> };
>
> -static const struct vs_formats vs_formats_no_yuv444 = {
> +const struct vs_formats vs_formats_no_yuv444 = {
> .array = vs_formats_array_no_yuv444,
> .num = ARRAY_SIZE(vs_formats_array_no_yuv444)
> };
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> index 92192e4fa086..655cf93ca3aa 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> @@ -14,6 +14,29 @@ struct vs_formats {
> unsigned int num;
> };
>
> +enum vs_dc_family {
> + VS_DC_FAMILY_DC8000,
> + VS_DC_FAMILY_DCULTRA_LITE,
> +};
> +
> +/**
> + * struct vs_dc_info - per-SoC DC platform data
> + * @family: DC IP family (DC8000, DCUltra Lite, etc.)
> + * @display_count: number of display outputs (0 = auto-detect
> from DT/HW)
> + * @has_chip_id: whether chip identity registers exist
> + * @has_config_ex: whether CONFIG_EX commit mechanism exists
> + * @regmap_cfg: regmap configuration for this
> variant
> + * @formats: supported pixel formats (NULL = auto-detect
> from chip ID)
> + */
> +struct vs_dc_info {
> + enum vs_dc_family family;
> + u32 display_count;
> + bool has_chip_id;
> + bool has_config_ex;
> + const struct regmap_config *regmap_cfg;
> + const struct vs_formats *formats;
> +};
> +
> struct vs_chip_identity {
> u32 model;
> u32 revision;
> @@ -23,6 +46,8 @@ struct vs_chip_identity {
> const struct vs_formats *formats;
> };
>
> +extern const struct vs_formats vs_formats_no_yuv444;
> +
> int vs_fill_chip_identity(struct regmap *regs,
> struct vs_chip_identity *ident);
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> index 1f2be41ae496..197d5d683e22 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> @@ -55,8 +55,9 @@ static int vs_primary_plane_atomic_check(struct
> drm_plane *plane,
>
> static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int
> output)
> {
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_COMMIT);
> + if (dc->info->has_config_ex)
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_COMMIT);
Should VALID bit be written here instead of doing nothing on
DC8000/DCUltraLite ?
> }
>
> static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
> @@ -69,11 +70,13 @@ static void vs_primary_plane_atomic_enable(struct
> drm_plane *plane,
> unsigned int output = vcrtc->id;
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_FB_EN);
> - regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
> - VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
> + if (dc->info->has_config_ex) {
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
> + regmap_update_bits(dc->regs,
> VSDC_FB_CONFIG_EX(output),
> +
> VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
> +
> VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
> + }
>
> vs_primary_plane_commit(dc, output);
> }
> @@ -88,8 +91,9 @@ static void vs_primary_plane_atomic_disable(struct
> drm_plane *plane,
> unsigned int output = vcrtc->id;
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_FB_EN);
> + if (dc->info->has_config_ex)
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
>
> vs_primary_plane_commit(dc, output);
> }
> @@ -126,6 +130,11 @@ static void
> vs_primary_plane_atomic_update(struct drm_plane *plane,
> VSDC_FB_CONFIG_UV_SWIZZLE_EN,
> vs_state->format.uv_swizzle);
>
> + /* DCUltra Lite requires explicit enable/reset bits in
> FB_CONFIG */
> + if (!dc->info->has_config_ex)
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE |
> VSDC_FB_CONFIG_RESET);
Should VSDC_FB_CONFIG_RESET be only set when it's ready to output the
signal (at least all timing is programmed)? I think it should be
programmed in crtc/bridge instead of primary plane, although it's in
the DcregFrameBufferConfig0 register (obviously this sounds a little
weird, this might be why they changed this in DC8200).
When ENABLE (OUTPUT in the document) is cleared, all pixels will be
blacked out; so I think it's better to set ENABLE in CRTC, and then set
RESET in bridge (doing the work of encoder in this driver) -- it seems
that for DC8000/DCUltraLite the primary plane is not possible to be
disabled.
> dma_addr = vs_fb_get_dma_addr(fb, &state->src);
>
> regmap_write(dc->regs, VSDC_FB_ADDRESS(output),
> @@ -133,16 +142,18 @@ static void
> vs_primary_plane_atomic_update(struct drm_plane *plane,
> regmap_write(dc->regs, VSDC_FB_STRIDE(output),
> fb->pitches[0]);
>
> - regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
> - VSDC_MAKE_PLANE_POS(state->crtc_x, state-
> >crtc_y));
> - regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
> - VSDC_MAKE_PLANE_POS(state->crtc_x + state-
> >crtc_w,
> - state->crtc_y + state-
> >crtc_h));
> regmap_write(dc->regs, VSDC_FB_SIZE(output),
> VSDC_MAKE_PLANE_SIZE(state->crtc_w, state-
> >crtc_h));
>
> - regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
> - VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
> + if (dc->info->has_config_ex) {
> + regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
> + VSDC_MAKE_PLANE_POS(state->crtc_x,
> state->crtc_y));
> + regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
> + VSDC_MAKE_PLANE_POS(state->crtc_x +
> state->crtc_w,
> + state->crtc_y +
> state->crtc_h));
> + regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
> + VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
> + }
>
> vs_primary_plane_commit(dc, output);
> }
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> index cbb125c46b39..288064760b48 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> @@ -16,6 +16,8 @@
> #define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
>
> #define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
> +#define VSDC_FB_CONFIG_ENABLE BIT(0)
As I mentioned that the VALID bit is quite important, please add it
here (you can call it "COMMIT" too if you like).
#define VSDC_FB_CONFIG_VALID BIT(3)
> +#define VSDC_FB_CONFIG_RESET BIT(4)
> #define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
> #define VSDC_FB_CONFIG_ROT_MASK GENMASK(13,
> 11)
> #define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
^ 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