* 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
* [PATCH] ARM: dts: aspeed: anacapa: add JTAG CPLD TRST pin to SGPIO map
From: Colin Huang via B4 Relay @ 2026-05-11 9:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
colin.huang2, Colin Huang
From: Colin Huang <u8813345@gmail.com>
Add JTAG_CPLD_TRST_R_N to the sgpiom0 pin name table on
Facebook Anacapa BMC.
This exposes the CPLD JTAG TRST signal through SGPIO,
allowing proper JTAG reset control during debug.
Signed-off-by: Colin Huang <u8813345@gmail.com>
---
Add JTAG_CPLD_TRST_R_N to the SGPIO M0 pin name table on
Facebook Anacapa BMC.
This exposes the CPLD JTAG TRST signal through SGPIO,
allowing proper JTAG reset control during debug.
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..9a43e0c87257 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -882,7 +882,7 @@ &sgpiom0 {
/* C0-C7 line 32-47 */
"RSVD_RMC_GPIO3", "", "", "",
"", "", "", "",
- "LEAK_DETECT_RMC_N", "", "", "",
+ "LEAK_DETECT_RMC_N", "JTAG_CPLD_TRST_R_N", "", "",
"", "", "", "",
/* D0-D7 line 48-63 */
---
base-commit: b333a0f1c857411d83a02aa6f1d9ecc7666d6179
change-id: 20260511-add-jtag-trst-pin-540b7d84ae2c
Best regards,
--
Colin Huang <u8813345@gmail.com>
^ permalink raw reply related
* Re: [PATCH] arm: dts: mediatek: mt6589: Add Arm Generic Timer node
From: AngeloGioacchino Del Regno @ 2026-05-11 9:47 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, matthias.bgg, Akari Tsuyukusa
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260325144500.667385-1-akkun11.open@gmail.com>
On Wed, 25 Mar 2026 23:45:00 +0900, Akari Tsuyukusa wrote:
> Add the Arm Generic Timer node to the MT6589 SoC.
> "arm,cpu-registers-not-fw-configured;" is required
> because the bootloader does not initialize the Arm Generic Timer.
>
>
Applied to v7.1-next/dts32, thanks!
[1/1] arm: dts: mediatek: mt6589: Add Arm Generic Timer node
commit: 2a5d54507c68c2a8de9d6f6746f23771d38f4dbc
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v2 0/3] arm: dts: mediatek: fix pinctl node names
From: AngeloGioacchino Del Regno @ 2026-05-11 9:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
David Lechner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260305-mtk-fix-mt7623-pinctl-name-v2-0-a68854a51065@baylibre.com>
On Thu, 05 Mar 2026 15:03:15 -0600, David Lechner wrote:
> While passing by, I noticed that the pinctrl nodes in a couple of dtsi
> files did not match the addresses in their reg properties. Here are some
> patches to fix that.
>
>
Applied to v7.1-next/dts32, thanks!
[1/3] arm: dts: mediatek: mt7623: fix pinctrl child node names
commit: 23d304b97e8e20b8d786b82b4d56257dde95139c
[2/3] arm: dts: mediatek: mt7623: fix pinctrl controller node name
commit: 85fdc6458535d234e54d0968cc816dec9003d341
[3/3] arm: dts: mediatek: mt8135: fix pinctrl node name
commit: ba6afff1d9b70028a5fc3df2d3acbee501c20a53
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch
From: Arnd Bergmann @ 2026-05-11 9:46 UTC (permalink / raw)
To: Thomas Gleixner, Arnd Bergmann, Will Deacon, Robin Murphy,
Joerg Roedel, Andrew Morton
Cc: linux-arm-kernel, iommu, linux-kernel, Sebastian Andrzej Siewior
In-Reply-To: <87y0hq8lcu.ffs@tglx>
On Mon, May 11, 2026, at 09:18, Thomas Gleixner wrote:
> On Mon, May 11 2026 at 08:17, Arnd Bergmann wrote:
>> On Sun, May 10, 2026, at 21:31, Thomas Gleixner wrote:
>>> On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
>>>> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>>>>
>>>> From what I can tell, the transformation is correct, as this
>>>> is only called when lookup_object_or_alloc() is called from
>>>> debug_objects_selftest(), which is also __init.
>>>
>>> So clearly the compiler is buggy. It creates an __init specific copy of
>>> lookup_object_or_alloc() and then fails to attribute it correctly.
>>
>> I don't see what else the compiler is supposed to do, it has no idea what
>> __init means in the kernel, or what the rules are for calling between
>> that and normal functions. Putting a non-inlined lookup_object_or_alloc()
>> into a special section without an explicit attribute would clearly
>> be a bug.
>
> I agree that the compiler does not know what __init means, but this
> sucks as it leaves an unused copy of lookup_object_or_alloc() around
> after init.
>
> What happens if you mark is_static_object() with 'noinline'?
I've reproduced the issue with the release gcc-16.1.0 build,
and tested marking is_static_object (along with
dummy_tlb_add_page and dummy_tlb_flush from the other
instance) as noinline.
As expected, this avoids the problem as well.
Arnd
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 40e33257d3c2..b89dcf167832 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -782,16 +782,17 @@ static void __init dummy_tlb_flush_all(void *cookie)
WARN_ON(cookie != cfg_cookie);
}
-static void __init dummy_tlb_flush(unsigned long iova, size_t size,
- size_t granule, void *cookie)
+static noinline void __init dummy_tlb_flush(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
{
WARN_ON(cookie != cfg_cookie);
WARN_ON(!(size & cfg_cookie->pgsize_bitmap));
}
-static void __init dummy_tlb_add_page(struct iommu_iotlb_gather *gather,
- unsigned long iova, size_t granule,
- void *cookie)
+static noinline void __init dummy_tlb_add_page(struct iommu_iotlb_gather *gather,
+ unsigned long iova,
+ size_t granule,
+ void *cookie)
{
dummy_tlb_flush(iova, granule, granule, cookie);
}
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 12e2e42e6a31..18253cb03701 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -1212,7 +1212,7 @@ struct self_test {
static __initconst const struct debug_obj_descr descr_type_test;
-static bool __init is_static_object(void *addr)
+static noinline bool __init is_static_object(void *addr)
{
struct self_test *obj = addr;
^ permalink raw reply related
* Re: [PATCH v4 2/2] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: AngeloGioacchino Del Regno @ 2026-05-11 9:46 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
devicetree, linux-kernel, linux-arm-kernel, dri-devel
In-Reply-To: <20260505214541.333657-3-l.scorcia@gmail.com>
On 5/5/26 23:45, Luca Leonardo Scorcia wrote:
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Unfortunately the device tree has a dedicated compatible for
> mt8167 since 2022 and it cannot be changed with a fallback nor removed at
> this point. The only way to get the device to work is to add the
> compatible to the driver.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 0/9] ASoC: mediatek: mt2701: HDMI audio support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:43 UTC (permalink / raw)
To: Daniel Golle, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <cover.1776998727.git.daniel@makrotopia.org>
On 4/24/26 04:48, Daniel Golle wrote:
> This series wires up on-chip HDMI audio on MT2701 and MT7623N, from the
> DRM bridge down through the AFE into a small machine driver that binds
> the AFE HDMI BE to the HDMI TX codec already exposed by the
> mediatek-drm-hdmi driver. Bindings, DT and a BananaPi R2 board node
> are included.
>
> In order to survive vblank or late hotplug of the monitor, the fix
> submitted separately [1] is required as well.
>
> Everything here was developed for and tested on a BananaPi R2
> (MT7623N), which turns ten years old this year -- a nice occasion to
> finally land HDMI audio for a SoC which was truly ahead of its time.
>
> [1]: https://patchwork.kernel.org/project/linux-mediatek/patch/a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org/
>
Whole series is
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
I'll pick the devicetree bits after the ASoC and bindings bits get picked.
Cheers,
Angelo
^ 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