* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Khristine Andreea Barbulescu @ 2026-03-31 7:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <f3ff461b-edd7-423a-ac99-e70145aaaaea@kernel.org>
On 3/23/2026 10:07 AM, Krzysztof Kozlowski wrote:
> On 23/03/2026 08:57, Khristine Andreea Barbulescu wrote:
>> On 3/14/2026 9:31 AM, Arnd Bergmann wrote:
>>> On Fri, Mar 13, 2026, at 18:10, Krzysztof Kozlowski wrote:
>>>> On 25/02/2026 10:40, Ghennadi Procopciuc wrote:
>>>>> On 2/23/2026 3:14 PM, Krzysztof Kozlowski wrote:
>>>>>>> there are no resources allocated specifically for nodes like
>>>>>>> "nxp,s32g-siul2-syscfg". Their consumers are the pinctrl/gpio
>>>>>>> driver and other drivers that read SoC‑specific information from
>>>>>>> those shared registers.
>>>>>>>
>>>>>>> My alternative is to keep two separate syscon providers for the
>>>>>>
>>>>>> You got review already.
>>>>>>
>>>>> I still believe that nvmem is a suitable and accurate mechanism for
>>>>> describing SoC‑specific identification information, as originally
>>>>> proposed in [0], assuming the necessary adjustments are made.
>>>>>
>>>>> More specifically, instead of modeling software-defined cells, the nvmem
>>>>> layout would describe the actual hardware registers backing this
>>>>> information. One advantage of this approach is that consumer nodes (for
>>>>> example PCIe, Ethernet, or other IPs that need SoC identification data)
>>>>> can reference these registers using the standard nvmem-cells /
>>>>> nvmem-cell-names mechanism, without introducing custom, per-subsystem
>>>>> bindings.
>>>>
>>>> nvmem is applicable only if this is NVMEM. Information about the soc is
>>>> not NVMEM, unless this are blow out fuses / efuse. Does not look like,
>>>> because SoC information is set probably during design phase, not board
>>>> assembly.
>>>
>>> Agreed, nvmem clearly makes no sense here, the patch description
>>> appears to accurately describe the MMIO area as hardware registers
>>> with a fixed meaning rather than a convention for how the
>>> memory is being used.
>>>
>>> That said, there is probably room for improvement, since some of
>>> the register contents are read-only and could just be accessed
>>> by the boot firmware in order to move the information into more
>>> regular DT properties instead of defining bindings for drivers
>>> to access the information in raw form.
>>>
>>> Arnd
>>
>> Hi Krzysztof & Arnd,
>>
>> Assuming we drop the syscon approach entirely, for the SerDes
>> presence information we could follow Arnd’s suggestion and have
>> it provided by the boot firmware instead of exposing it through SIUL2.
>
> I think there is misunderstanding. By dropping syscon nodes, I meant to
> drop the nodes. Remove them. It implies that whatever their contain must
> go somewhere, right? Because your hardware is fixed and you cannot drop
> it from the hardware, right?
>
> So their parent node is the syscon.
>
> Best regards,
> Krzysztof
Hi Krzysztof & Arnd,
Following your suggestions, I reworked the DT so that the SIUL2
register regions are now described directly on the parent node, and
the separate syscon child nodes are removed.
The node would look like this:
siul2: siul2@4009c000 {
compatible = "nxp,s32g2-siul2";
reg = <0x4009c000 0x179c>,
<0x44010000 0x17b0>;
reg-names = "siul20", "siul21";
pinctrl: pinctrl {
compatible = "nxp,s32g-siul2-pinctrl";
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&pinctrl 0 0 102>, <&pinctrl 112 112 79>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
jtag_pins: jtag-pins {
...
};
};
};
With the current layout, the SIUL2 node itself now contains the two
MMIO ranges directly, while the remaining child node is only the
pinctrl/GPIO function.
I am wondering whether it still makes sense to keep the MFD approach
at all. In the current form, the node no longer models multiple
separate child providers such as the previous syscon children, but
rather a single parent node containing the whole register space
together with the pinctrl/GPIO.
Would you recommend dropping the MFD layer entirely and having
the pinctrl/GPIO driver bind directly to the parent `siul2@...`
node instead?
Please let me know whether this is the direction you would prefer,
or if you still see value in keeping the current MFD based approach.
Best regards,
Khristine
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Krzysztof Kozlowski @ 2026-03-31 7:50 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Marek Vasut, devicetree, Geert Uytterhoeven,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <dd3587eb-f91e-4a9a-8a0b-b55bfba2c23a@kernel.org>
On 31/03/2026 09:15, Krzysztof Kozlowski wrote:
> On 27/03/2026 12:42, Wolfram Sang wrote:
>>>> +#define MFIS_CHANNEL_TX (0 << 0)
>>>> +#define MFIS_CHANNEL_RX (1 << 0)
>>>
>>> No improvements and no answers to comments. Same review, drop, not a
>>> binding. If disagree, respond to v1 comments.
>>
>> I think I did. I explained above in "changes since v1" that I decided to
>> keep it because of the existing users in upstream that Geert mentioned.
>
> Same review as in v1. Not a binding. I asked what Linux ABI are you here
> binding. Point me to Linux code using these. This is the ABI.
>
> You replied something about device, so how does it matter? It is not the
> answer to the question.
You made the posting unnecessarily complicated - this patch went to my
DT address, but the rest to non-DT. Why not using b4 which gets it
correct without effort? Plus it gives you much more like changelog with
lore links and trailers handling?
So now I found the driver (in different place...) and indeed you use
some of the constants, so this is an ABI. It was so easy in v1 to just
point me to usage of the ABI when I asked how do you use this in Linux...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] interconnect: qcom: add Hawi interconnect provider driver
From: Konrad Dybcio @ 2026-03-31 7:52 UTC (permalink / raw)
To: Vivek Aknurwar, Georgi Djakov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-icc-hawi-v1-2-4b54a9e7d38c@oss.qualcomm.com>
On 3/31/26 2:40 AM, Vivek Aknurwar wrote:
> Add driver for the Qualcomm interconnect buses found in Hawi
> based platforms. The topology consists of several NoCs that are
> controlled by a remote processor that collects the aggregated
> bandwidth for each master-slave pairs.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: soc: renesas: add MFIS binding documentation
From: Krzysztof Kozlowski @ 2026-03-31 7:52 UTC (permalink / raw)
To: Wolfram Sang
Cc: Geert Uytterhoeven, linux-renesas-soc, linux-kernel, Jassi Brar,
Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree
In-Reply-To: <act6gTgkYE6Az5hK@shikoro>
On 31/03/2026 09:40, Wolfram Sang wrote:
>
>>> In case you mean this as unanswered questions to v1: This describes the
>>> device specific second mbox cell. Like Tegra does it here (even with
>>
>> I asked Linux ABI. Device specific numbers is not Linux ABI, because
>> Linux is not device.
>
> I have no idea what you want here. I see it like this: DT is OS
DT, but we talk about bindings. Bindings is not DT. Bindings bind the SW
and DTS.
> agnostic. So, the flags are to describe the hardware. The Linux driver
Well, then no. Bindings headers do not describe the hardware.
> then does the proper things according to these flags. Other OS driver
> might do other things.
>
>>> shifts instead of plain numbers):
>>>
>>> include/dt-bindings/mailbox/tegra186-hsp.h
>
> And I still have no idea why my header is different than the Tegra one.
>
No clue what is there. I am not going even to investigate, because this
is argument of "I found a bug somewhere, so I can implement same bug".
I responded to this *MULTIPLE* times already on the lists. I explained
the rationale, I even provided old messages from Arnd and other people.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/7] clk: qcom: clk-alpha-pll: Add support for Taycan EHA_T PLL
From: Konrad Dybcio @ 2026-03-31 7:53 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-6-c2a663e1d35b@oss.qualcomm.com>
On 3/31/26 2:35 AM, Vivek Aknurwar wrote:
> Add clock operations and register offsets to enable control of the Taycan
> EHA_T PLL, allowing for proper configuration and management of the PLL.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: (subset) [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Bartosz Golaszewski @ 2026-03-31 7:55 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
Manivannan Sadhasivam
Cc: Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
On Thu, 26 Mar 2026 13:36:28 +0530, Manivannan Sadhasivam wrote:
> This series is the continuation of the series [1] that added the initial support
> for the PCIe M.2 connectors. This series extends it by adding support for Key E
> connectors. These connectors are used to connect the Wireless Connectivity
> devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> interfaces are left for future improvements.
>
> [...]
Applied, thanks!
[1/8] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
https://git.kernel.org/brgl/c/e7fef85039ccdba67d97b2a09f313aceeb6691c8
[2/8] serdev: Add an API to find the serdev controller associated with the devicetree node
https://git.kernel.org/brgl/c/a2b4814190af5944b276c5fd708d95ea146106b3
[3/8] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
https://git.kernel.org/brgl/c/92fa16ecad07dddc5703f7e2ff342441b04c45af
[4/8] dt-bindings: serial: Document the graph port
https://git.kernel.org/brgl/c/1785c7bc1495e4e22377edffaf0ff8c3c697647d
[5/8] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
https://git.kernel.org/brgl/c/5970c1dafb8adbeab5f6d9a22a4ad5b1c0067888
[7/8] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
https://git.kernel.org/brgl/c/0d38285a12a283e12cd589ad5bb46c6f4a8cc647
[8/8] power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
https://git.kernel.org/brgl/c/3f736aecbdc8e4faf2ed82c981812a6bfc76ea98
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [DMARC error]Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: Xianwei Zhao @ 2026-03-31 7:59 UTC (permalink / raw)
To: George Stark, Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <4a9c726a-d580-4b0b-9530-228b58389c80@salutedevices.com>
Hi George,
On 2026/3/31 15:33, George Stark wrote:
> Hello Martin, Xianwei
>
>
> On 3/31/26 10:10, Xianwei Zhao wrote:
>> Hi Martin,
>> I confirmed with Junyi Zhao that the current implementation counts
>> from zero, so this submission is correct.
>> We agree this should be fixed and will address it in a follow-up patch.
>> Thanks for pointing it out.
>>
>> On 2026/3/31 05:54, Martin Blumenstingl wrote:
>>> Hi Xianwei Zhao,
>>>
>>> thanks for your contribution!
>>>
>>> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
>>> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>>>> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
>>> There is an old report that got lost, stating that the current
>
> Xianwei Zhao thanks for the confirmation.
> I am the author of the old report and the corresponding patch and it's
> not lost. So if the patch is correct I'll be glad to add relevant
> tested-by tags.
>
I will use your patch and won't send a separate one.
Do you mean I should add a Tested-by tag to your patch?
>>> pwm-meson driver has an off-by-one error with the hi and lo fields:
>>> [0]
>>> Since you are working on bringing up a new platform: is this something
>>> you can verify in your lab?
>>> To be clear: I'm not expecting you to work on this ad-hoc or bring a
>>> patch into this series. However, it would be great if you could verify
>>> if the findings from [0] are correct and send an updated patch in
>>> future.
>>>
>>> Thank you and best regards
>>> Martin
^ permalink raw reply
* Re: [PATCH v2 07/10] drm/bridge: dw-hdmi: move next_bridge lookup to attach time
From: Damon Ding @ 2026-03-31 7:24 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Christopher Obbard,
Daniel Scally, Emanuele Ghidoli, Fabio Estevam, Francesco Dolcini,
Frieder Schrempf, Gilles Talis, Goran Rađenović,
Heiko Schocher, Josua Mayer, Kieran Bingham, Marco Felsch,
Martyn Welch, Oleksij Rempel, Peng Fan, Richard Hu, Shengjiu Wang,
Stefan Eichenberger, Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-7-c7f2af536a24@bootlin.com>
On 3/31/2026 3:25 AM, Luca Ceresoli wrote:
> This driver looks up the next_bridge at probe time and stores it in
> hdmi->bridge.next_bridge, but only uses the stored value when attaching,
> and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
>
> This will be problematic with an upcoming change, adding an hdmi-connector
> using a device tree overlay when not present. That change is in turn
> necessary to migrate the i.MX LCDIF driver to the bridge-connector.
>
> The problem is that, adding the hdmi-connector via an overlay, devlink
> considers hdmi-connector a consumer of the dw-hdmi device, generating a
> chicken-egg problem:
>
> * hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
> * dw-hdmi probe will defer until it finds the next_bridge (the
> hdmi-connector wrapper bridge)
>
> In preparation for those changes, move the next_bridge lookup from probe to
> attach, when it is actually used. This allows dw-hdmi to probe, so that the
> hdmi-connector can probe as well.
>
> Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
> computed when needed, thus a local variable is enough.
>
> Finally, this also allows to slightly improve the code by not doing any DT
> lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
>
> Tested-by: Martyn Welch <martyn.welch@collabora.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Changes in v2:
> - Fix returned error codes
> - Added missing cleanup.h include
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +++++++++++--------------------
> 1 file changed, 16 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ab1a6a8783cd..f4a1ebb79716 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -6,6 +6,8 @@
> * Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> * Copyright (C) 2010, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> */
> +
> +#include <linux/cleanup.h>
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/err.h>
> @@ -2914,9 +2916,20 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
> if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port))
> return -EINVAL;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return drm_bridge_attach(encoder, hdmi->bridge.next_bridge,
> - bridge, flags);
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> + struct device_node *remote __free(device_node) =
> + of_graph_get_remote_node(hdmi->dev->of_node,
> + hdmi->plat_data->output_port, -1);
> + if (!remote)
> + return -ENODEV;
> +
> + struct drm_bridge *next_bridge __free(drm_bridge_put) =
> + of_drm_find_and_get_bridge(remote);
> + if (!next_bridge)
> + return -EPROBE_DEFER;
> +
> + return drm_bridge_attach(encoder, next_bridge, bridge, flags);
> + }
>
> return dw_hdmi_connector_create(hdmi);
> }
> @@ -3307,28 +3320,6 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
> * Probe/remove API, used from platforms based on the DRM bridge API.
> */
>
> -static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
> -{
> - struct device_node *remote;
> -
> - if (!hdmi->plat_data->output_port)
> - return 0;
> -
> -
> - remote = of_graph_get_remote_node(hdmi->dev->of_node,
> - hdmi->plat_data->output_port,
> - -1);
> - if (!remote)
> - return -ENODEV;
> -
> - hdmi->bridge.next_bridge = of_drm_find_and_get_bridge(remote);
> - of_node_put(remote);
> - if (!hdmi->bridge.next_bridge)
> - return -EPROBE_DEFER;
> -
> - return 0;
> -}
> -
> bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi)
> {
> return hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format);
> @@ -3373,10 +3364,6 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
> mutex_init(&hdmi->cec_notifier_mutex);
> spin_lock_init(&hdmi->audio_lock);
>
> - ret = dw_hdmi_parse_dt(hdmi);
> - if (ret < 0)
> - return ERR_PTR(ret);
> -
> ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
> if (ddc_node) {
> hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
>
Tested-by: Damon Ding <damon.ding@rock-chips.com> (on rk3399)
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH 7/7] clk: qcom: Add support for global clock controller on Hawi
From: Konrad Dybcio @ 2026-03-31 8:01 UTC (permalink / raw)
To: Vivek Aknurwar, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-7-c2a663e1d35b@oss.qualcomm.com>
On 3/31/26 2:35 AM, Vivek Aknurwar wrote:
> Add support for the global clock controller (GCC) on the Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v3] ARM: dts: aspeed: anacapa: Add eeprom device node for NFC adaptor board
From: Carl Lee via B4 Relay @ 2026-03-31 8:02 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
carl.lee, peter.shen, colin.huang2
From: Carl Lee <carl.lee@amd.com>
Add eeprom device node for NFC adaptor board FRU.
Signed-off-by: Carl Lee <carl.lee@amd.com>
---
Add eeprom device node to store FRU data for NFC adapter
board on Anacapa platform.
---
Changes in v3:
- Fix node ordering to follow ascending unit address
- Update commit message to match actual changes
- Link to v2: https://lore.kernel.org/r/20260309-arm-dts-aspeed-anacapa-add-eeprom-device-v2-1-91c7dde4b79d@amd.com
Changes in v2:
- Remove PRoT module eeprom commit since it is already included in another series under review.
- Only include NFC adapter board eeprom node.
- Link to v1: https://lore.kernel.org/r/20260309-arm-dts-aspeed-anacapa-add-eeprom-device-v1-0-45092310e0e6@amd.com
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 5 +++++
1 file changed, 5 insertions(+)
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..57fd81e931d6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -824,6 +824,11 @@ nfc@28 {
enable-gpios = <&sgpiom0 241 GPIO_ACTIVE_HIGH>;
};
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
};
};
};
---
base-commit: a0ae2a256046c0c5d3778d1a194ff2e171f16e5f
change-id: 20260309-arm-dts-aspeed-anacapa-add-eeprom-device-a1aabe06a35b
Best regards,
--
Carl Lee <carl.lee@amd.com>
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Wolfram Sang @ 2026-03-31 8:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-renesas-soc, Marek Vasut, devicetree, Geert Uytterhoeven,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cfee8254-8573-4106-b71f-293073b64c89@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
> You made the posting unnecessarily complicated - this patch went to my
> DT address, but the rest to non-DT. Why not using b4 which gets it
> correct without effort? Plus it gives you much more like changelog with
> lore links and trailers handling?
Switching to b4 is on my to-do list. I will give it a priority boost.
> So now I found the driver (in different place...) and indeed you use
> some of the constants, so this is an ABI. It was so easy in v1 to just
> point me to usage of the ABI when I asked how do you use this in Linux...
Well, IMO I pointed you to the ABI by sending v2. I still think this is
a valid choice, I understand that you would have liked it differently.
Back on topic: As I understand it, I will prepare v3 by adding interrupt
constraints, fix the indentation and use your DT address properly,
right? The ABI issue is resolved now?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Konrad Dybcio @ 2026-03-31 8:11 UTC (permalink / raw)
To: Bryan O'Donoghue, Dmitry Baryshkov
Cc: johannes.goede, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <96d3bb35-3fae-47e4-b484-1a37f2f41b43@kernel.org>
On 3/31/26 12:51 AM, Bryan O'Donoghue wrote:
> On 30/03/2026 19:55, Dmitry Baryshkov wrote:
>> This sounds like the most horrible idea: letting userspace directly
>> program any registers in a way that is not visible to the kernel.
>
> No I'm wondering if there is a way to construct the basic format in user-space so it doesn't need to be re-interpreted stuffed/unstuffed.
>
> As mentioned I believe there is a defunct qcom project which did/does just that, not sure why that hasn't been investigated/developed.
I believe this isn't a great idea since the format will at one point be
platform-dependent (I think it may be already) and one will have to teach
_all_ of the userspace implementations about all of these specifics
Unless I'm missing the bigger picture, we're not talking about super
large amounts of data that would need to be slightly shuffled around
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Krzysztof Kozlowski @ 2026-03-31 8:11 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Marek Vasut, devicetree, Geert Uytterhoeven,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <acuA_CGZNrsdmXy0@shikoro>
On 31/03/2026 10:08, Wolfram Sang wrote:
>
> Well, IMO I pointed you to the ABI by sending v2. I still think this is
> a valid choice, I understand that you would have liked it differently.
>
> Back on topic: As I understand it, I will prepare v3 by adding interrupt
> constraints, fix the indentation and use your DT address properly,
> right? The ABI issue is resolved now?
>
Yes
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v16 2/3] arm64: dts: qcom: talos/qcs615-ride: Fix inconsistent USB PHY node naming
From: Konrad Dybcio @ 2026-03-31 8:12 UTC (permalink / raw)
To: Sudarshan Shetty, andersson, konradybcio
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <20260331060107.501561-3-tessolveupstream@gmail.com>
On 3/31/26 8:01 AM, Sudarshan Shetty wrote:
> The USB PHY nodes has inconsistent labels as 'usb_1_hsphy'
> and 'usb_hsphy_2' across talos.dtsi and qcs615-ride.dts.
> This patch renames them to follow a consistent naming
> scheme.
>
> No functional changes, only label renaming.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RFC 08/19] RISC-V: QoS: add resctrl interface for CBQRI controllers
From: guo.wenjia23 @ 2026-03-31 8:14 UTC (permalink / raw)
To: fustini
Cc: dave.martin, acpica-devel, alex, aou, aricciardi, atish.patra,
atishp, babu.moger, ben.horgan, conor+dt, cp0613, cuiyunhui,
devicetree, fenghua.yu, james.morse, krzk+dt, lenb, linux-acpi,
linux-kernel, linux-riscv, liu.qingtao2, liwei1518, mindal,
npitre, palmer, paul.walmsley, peternewman, pjw, rafael,
reinette.chatre, rkrcmar, robert.moore, robh, samuel.holland,
sunilvl, tony.luck, vasu, ved, x86, zhiwei_liu
In-Reply-To: <actiYi6ACcOrvz9J@gen8>
Hi Drew,
> On Thu, Mar 26, 2026 at 07:05:48PM +0800, guo.wenjia23@zte.com.cn wrote:
> > Hi Drew,
> >
> > On Thu, Jan 29, 2026 at 4:28 AM Drew Fustini <fustini@kernel.org> wrote:>
> > > Add interface for CBQRI controller drivers to make use of the resctrl
> > > filesystem.
> > >
> > > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > > ---
> > > arch/riscv/kernel/qos/qos_resctrl.c | 1192 +++++++++++++++++++++++++++++++++++
> > > 1 file changed, 1192 insertions(+)
> > >
> > > ...
> > >
> > > +
> > > +int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> > > + u32 closid, enum resctrl_conf_type t, u32 cfg_val)
> > > +{
> > > + struct cbqri_controller *ctrl;
> > > + struct cbqri_resctrl_dom *dom;
> > > + struct cbqri_config cfg;
> > > + int err = 0;
> > > +
> > > + dom = container_of(d, struct cbqri_resctrl_dom, resctrl_ctrl_dom);
> > > + ctrl = dom->hw_ctrl;
> > > +
> > > + if (!r->alloc_capable)
> > > + return -EINVAL;
> > > +
> > > + switch (r->rid) {
> > > + case RDT_RESOURCE_L2:
> > > + case RDT_RESOURCE_L3:
> > > + cfg.cbm = cfg_val;
> > > + err = cbqri_apply_cache_config(dom, closid, t, &cfg);
> > > + break;
> > > + case RDT_RESOURCE_MBA:
> > > + /* covert from percentage to bandwidth blocks */
> > > + cfg.rbwb = cfg_val * ctrl->bc.nbwblks / 100;
> >
> > Should use bc.mrbwb to calculate rbwb?
> > I think bc.nbwblks represent the available bw blks in the controller.
> It should should decrease as they are allocated.
>
> The resctrl MBA resource is supposed to be the percentage of total
> memory bandwidth. nbwblks is the total number of bandwidth blocks, so I
> think the existing calucation is correct.
>
> From the example SoC configuration, the number of bandwidth blocks is
> 1024, and mrbwb is meant to be 80% of nbwblks which is 819.
>
> Setting MB to 80% in schemata would yield: 80 * 1024 / 100 = 819
>
According to the specification
1. The MRBWB field reports the maximum number of bandwidth blocks that can be reserved.
2. The sum of Rbwb allocated across all rcids must not exceed MRBWB value.
Based on the specification and the example you mentioned, can this be understood as follows:
MRBWB is a fixed value determined by the SoC configuration, representing the effective bandwidth capacity of the bandwidth controller.
And the MRBWB value itself should remain constant and must not vary after the bandwidth allocations assigned to RCIDs.
Thanks,
Wenjia
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-31 8:21 UTC (permalink / raw)
To: Thomas Richard
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-1-1c1e11b190dc@bootlin.com>
On Mon, Mar 30, 2026 at 03:43:58PM +0200, Thomas Richard wrote:
> +$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PBIAS internal regulator
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - ti,pbias-dra7
> + - ti,pbias-omap2
> + - ti,pbias-omap3
> + - ti,pbias-omap4
> + - ti,pbias-omap5
> + - const: ti,pbias-omap
> +
> + reg:
> + maxItems: 1
> +
> + syscon:
> + description: Phandle of the system control module
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> +patternProperties:
> + '^pbias_*':
That wasn't in old binding and underscore is not allowed, so this needs
explanation. Old binding mentioned only the names.
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - syscon
> +
> +additionalProperties: false
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ti,pbias-omap2
> + then:
> + patternProperties:
> + '^pbias_*':
> + properties:
> + regulator-name:
> + contains:
> + enum:
> + - pbias_mmc_omap2430
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ti,pbias-omap3
> + then:
> + patternProperties:
> + '^pbias_*':
> + properties:
> + regulator-name:
> + contains:
> + enum:
> + - pbias_mmc_omap2430
> + - pbias_sim_omap3
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ti,pbias-omap4
> + then:
> + patternProperties:
> + '^pbias_*':
> + properties:
> + regulator-name:
> + contains:
> + enum:
> + - pbias_mmc_omap4
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ti,pbias-dra7
> + - ti,pbias-omap5
> + then:
> + patternProperties:
> + '^pbias_*':
> + properties:
> + regulator-name:
> + contains:
> + enum:
> + - pbias_mmc_omap5
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pbias_regulator: pbias_regulator@0 {
Drop unused labels
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Krzysztof Kozlowski @ 2026-03-31 8:22 UTC (permalink / raw)
To: Thomas Richard
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-2-1c1e11b190dc@bootlin.com>
On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
> supply and allows to unlock USB I/O cell.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> index 3e020d87701b..908fbb46b5cf 100644
> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> @@ -89,6 +89,7 @@ allOf:
> contains:
> enum:
> - pbias_mmc_omap4
> + - pbias_sim_omap4
Names cannot be fixed, because they represent different board naming.
Why growing the deprecated style?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Krzysztof Kozlowski @ 2026-03-31 8:25 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <20260330190304.1841593-2-radhey.shyam.pandey@amd.com>
On Tue, Mar 31, 2026 at 12:33:01AM +0530, Radhey Shyam Pandey wrote:
> Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
> 2x1 Dual Role Device IP. Introduce a new compatibility string to support
> it. The USB wrapper registers reside in the MMI UDH system-level control
> registers (SLCR) block, so instead of a dedicated reg property, add
> xlnx,usb-syscon phandle with four cells specifying register offsets for
> USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> Changes for v2:
> - Add blank line after compatible as suggested by Krzysztof.
> - Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
> IP from Synopsys is part of the dedicated Multimedia Interface. The
> Versal Gen2 platform also includes a separate USB 2.0 controller,
> and the mmi suffix uniquely distinguishes between the two USB
> controllers. MMI is an independent subsystem particularly targeted for
> deployment in Multi-Media related applications. The MMI block include
> following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
> Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
> Controllers, DP AUX-I2C PHY.
> - For MMI USB define parent address space i.e UDH block.
> - Fix inconsistent MHz spacing to use SI convention with spaces.
> - Move description before $ref and items in xlnx,usb-syscon property.
> - Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
> - Use 'usb' node name (without unit address) for versal2 example since
> it has no reg property.
> - Use 1/1 address/size configuration in versal2 example, use lowercase
> hex in syscon offsets.
> ---
> .../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
> 1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> index d6823ef5f9a7..5e31b961aff7 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> @@ -15,6 +15,8 @@ properties:
> - enum:
> - xlnx,zynqmp-dwc3
> - xlnx,versal-dwc3
> + - xlnx,versal2-mmi-dwc3
I am not going to ask the same questions.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur-crd: Enable DisplayPort support
From: Konrad Dybcio @ 2026-03-31 8:27 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260330-glymur-enable-displayport-v1-1-1543ad6dac3a@oss.qualcomm.com>
On 3/30/26 4:24 PM, Abel Vesa wrote:
> The two Type-C ports found on Glymur CRD are DisplayPort alternate mode
> capable. Everything is in place already for the USB, but for DisplayPort
> the controllers need to be enabled.
>
> So enable the related DisplayPort controller for each of these two
> ports. Also define the supported link frequencies for each output.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v3 0/5] dmaengine: Add Peripheral DMA support for SpacemiT K3 SoC
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
Hi all,
This patch series introduces Peripheral DMA (PDMA) support for the
SpacemiT K3 SoC, leveraging the existing mmp_pdma driver.
The K3 PDMA IP is largely based on the design found in the previous
SpacemiT K1 SoC, but introduces a few key architectural differences:
1. It features a variable extended DRCMR base address for DMA request
numbers (>= 64) depending on the hardware implementation.
2. Unlike the K1 SoC, where some DMA masters had memory addressing
limitations (requiring a dedicated dma-bus), the K3 DMA masters
have full memory addressing capabilities.
The series is structured as follows:
- Patch 1: Introduce the necessary dt-bindings: K3 compatible string.
- Patch 2-3: Refactor the mmp_pdma driver to support variable extended
DRCMR bases, and add the specific implementation/ops for the K3 SoC.
- Patch 4: Fixes a critical clock issue where the DDR bus clock
(top_dclk) could be gated by CCF, which would cause DMA engines to
hang and lead to system instability.
- Patch 5: Finally, instantiates the PDMA controller node in the
SpacemiT K3 device tree.
---
Changes in v3:
- Removed the dt-bindings patches related to the DMA number.
- patch 1/5:
- update commit message
- patch 2-5: nothing
- Link to v2: https://lore.kernel.org/r/20260326-k3-pdma-v2-0-ca94ca7bb595@linux.spacemit.com
Changes in v2:
- patch 1-6 are added in this version
- patch 7/7
- update commit message
- using k3 compatible string
- Link to v1: https://lore.kernel.org/all/20260317-k3-pdma-v1-1-f39d3e97b53a@linux.spacemit.com/
---
Guodong Xu (3):
dt-bindings: dmaengine: Add SpacemiT K3 DMA compatible string
dmaengine: mmp_pdma: support variable extended DRCMR base
dmaengine: mmp_pdma: add Spacemit K3 support
Troy Mitchell (2):
clk: spacemit: k3: mark top_dclk as CLK_IS_CRITICAL
riscv: dts: spacemit: Add PDMA controller node for K3 SoC
.../devicetree/bindings/dma/spacemit,k1-pdma.yaml | 4 ++-
arch/riscv/boot/dts/spacemit/k3.dtsi | 11 +++++++
drivers/clk/spacemit/ccu-k3.c | 2 +-
drivers/dma/mmp_pdma.c | 37 ++++++++++++++++++++--
4 files changed, 49 insertions(+), 5 deletions(-)
---
base-commit: 02f90981a67f3b9ee7d6684e7503a4fed7aade0c
change-id: 20260317-k3-pdma-7c1734431436
Best regards,
--
Troy Mitchell <troy.mitchell@linux.spacemit.com>
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: dmaengine: Add SpacemiT K3 DMA compatible string
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
In-Reply-To: <20260331-k3-pdma-v3-0-a4e60dd8b4b3@linux.spacemit.com>
From: Guodong Xu <guodong@riscstar.com>
Add the "spacemit,k3-pdma" compatible string for the SpacemiT K3 SoC.
While the K3 PDMA IP reuses most of the design found on the earlier K1 SoC,
a new compatible string is required due to the following hardware differences:
- Variable extended DRCMR base: The DRCMR (DMA Request/Command Register) base
address for extended DMA request numbers (>= 64) differs from the K1
implementation, requiring different driver ops.
- Memory addressing capabilities: Unlike the K1 SoC, which had memory addressing
limitations (e.g., restricted to the 0-4GB space) and required a dedicated
dma-bus with dma-ranges to restrict memory allocations, the K3 DMA masters
possess full memory addressing capabilities.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml b/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml
index ec06235baf5c..62ce6d81526b 100644
--- a/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml
+++ b/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml
@@ -14,7 +14,9 @@ allOf:
properties:
compatible:
- const: spacemit,k1-pdma
+ enum:
+ - spacemit,k1-pdma
+ - spacemit,k3-pdma
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/5] dmaengine: mmp_pdma: add Spacemit K3 support
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
In-Reply-To: <20260331-k3-pdma-v3-0-a4e60dd8b4b3@linux.spacemit.com>
From: Guodong Xu <guodong@riscstar.com>
SpacemiT K3 reuses most of the PDMA IP design found on K1, with one difference
being the extended DRCMR base address. This patch adds "spacemit,k3-pdma"
compatible string and it defines a new mmp_pdma_ops for k3 pdma.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
drivers/dma/mmp_pdma.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index 6112369006ee..386e85cd4882 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -52,6 +52,7 @@
#define DCSR_EORINTR BIT(9) /* The end of Receive */
#define DRCMR_BASE 0x0100
+#define DRCMR_EXT_BASE_K3 0x1000
#define DRCMR_EXT_BASE_DEFAULT 0x1100
#define DRCMR_REQ_LIMIT 64
#define DRCMR_MAPVLD BIT(7) /* Map Valid (read / write) */
@@ -1207,6 +1208,20 @@ static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
.drcmr_ext_base = DRCMR_EXT_BASE_DEFAULT,
};
+static const struct mmp_pdma_ops spacemit_k3_pdma_ops = {
+ .write_next_addr = write_next_addr_64,
+ .read_src_addr = read_src_addr_64,
+ .read_dst_addr = read_dst_addr_64,
+ .set_desc_next_addr = set_desc_next_addr_64,
+ .set_desc_src_addr = set_desc_src_addr_64,
+ .set_desc_dst_addr = set_desc_dst_addr_64,
+ .get_desc_src_addr = get_desc_src_addr_64,
+ .get_desc_dst_addr = get_desc_dst_addr_64,
+ .run_bits = (DCSR_RUN | DCSR_LPAEEN | DCSR_EORIRQEN | DCSR_EORSTOPEN),
+ .dma_width = 64,
+ .drcmr_ext_base = DRCMR_EXT_BASE_K3,
+};
+
static const struct of_device_id mmp_pdma_dt_ids[] = {
{
.compatible = "marvell,pdma-1.0",
@@ -1214,6 +1229,9 @@ static const struct of_device_id mmp_pdma_dt_ids[] = {
}, {
.compatible = "spacemit,k1-pdma",
.data = &spacemit_k1_pdma_ops
+ }, {
+ .compatible = "spacemit,k3-pdma",
+ .data = &spacemit_k3_pdma_ops
}, {
/* sentinel */
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 4/5] clk: spacemit: k3: mark top_dclk as CLK_IS_CRITICAL
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
In-Reply-To: <20260331-k3-pdma-v3-0-a4e60dd8b4b3@linux.spacemit.com>
top_dclk is the DDR bus clock. If it is gated by clk_disable_unused,
all memory-mapped bus transactions cease to function, causing DMA
engines to hang and general system instability.
Mark it CLK_IS_CRITICAL so the CCF never gates it during the
unused clock sweep.
Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
drivers/clk/spacemit/ccu-k3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/spacemit/ccu-k3.c b/drivers/clk/spacemit/ccu-k3.c
index e98afd59f05c..bb8b75bdbdb3 100644
--- a/drivers/clk/spacemit/ccu-k3.c
+++ b/drivers/clk/spacemit/ccu-k3.c
@@ -846,7 +846,7 @@ static const struct clk_parent_data top_parents[] = {
CCU_PARENT_HW(pll6_d3),
};
CCU_MUX_DIV_GATE_FC_DEFINE(top_dclk, top_parents, APMU_TOP_DCLK_CTRL, 5, 3,
- BIT(8), 2, 3, BIT(1), 0);
+ BIT(8), 2, 3, BIT(1), CLK_IS_CRITICAL);
static const struct clk_parent_data ucie_parents[] = {
CCU_PARENT_HW(pll1_d8_307p2),
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/5] dmaengine: mmp_pdma: support variable extended DRCMR base
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
In-Reply-To: <20260331-k3-pdma-v3-0-a4e60dd8b4b3@linux.spacemit.com>
From: Guodong Xu <guodong@riscstar.com>
DRCMR base address for extended DMA request numbers (which means bigger
or equal to 64) varies in different PMDA hardware implementation.
One such different PDMA implementation is found in SpacemiT's K3. In
this patch is for preparation the adding of K3 PDMA support.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
drivers/dma/mmp_pdma.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index d12e729ee12c..6112369006ee 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -51,7 +51,9 @@
#define DCSR_CMPST BIT(10) /* The Descriptor Compare Status */
#define DCSR_EORINTR BIT(9) /* The end of Receive */
-#define DRCMR(n) ((((n) < 64) ? 0x0100 : 0x1100) + (((n) & 0x3f) << 2))
+#define DRCMR_BASE 0x0100
+#define DRCMR_EXT_BASE_DEFAULT 0x1100
+#define DRCMR_REQ_LIMIT 64
#define DRCMR_MAPVLD BIT(7) /* Map Valid (read / write) */
#define DRCMR_CHLNUM 0x1f /* mask for Channel Number (read / write) */
@@ -154,6 +156,7 @@ struct mmp_pdma_phy {
* @run_bits: Control bits in DCSR register for channel start/stop
* @dma_width: DMA addressing width in bits (32 or 64). Determines the
* DMA mask capability of the controller hardware.
+ * @drcmr_ext_base: Base DRCMR address for extended requests
*/
struct mmp_pdma_ops {
/* Hardware Register Operations */
@@ -174,6 +177,7 @@ struct mmp_pdma_ops {
/* Controller Configuration */
u32 run_bits;
u32 dma_width;
+ u32 drcmr_ext_base;
};
struct mmp_pdma_device {
@@ -195,6 +199,13 @@ struct mmp_pdma_device {
#define to_mmp_pdma_dev(dmadev) \
container_of(dmadev, struct mmp_pdma_device, device)
+static u32 mmp_pdma_get_drcmr(struct mmp_pdma_device *pdev, u32 drcmr)
+{
+ if (drcmr < DRCMR_REQ_LIMIT)
+ return DRCMR_BASE + (drcmr << 2);
+ return pdev->ops->drcmr_ext_base + ((drcmr - DRCMR_REQ_LIMIT) << 2);
+}
+
/* For 32-bit PDMA */
static void write_next_addr_32(struct mmp_pdma_phy *phy, dma_addr_t addr)
{
@@ -301,7 +312,7 @@ static void enable_chan(struct mmp_pdma_phy *phy)
pdev = to_mmp_pdma_dev(phy->vchan->chan.device);
- reg = DRCMR(phy->vchan->drcmr);
+ reg = mmp_pdma_get_drcmr(pdev, phy->vchan->drcmr);
writel(DRCMR_MAPVLD | phy->idx, phy->base + reg);
dalgn = readl(phy->base + DALGN);
@@ -437,7 +448,7 @@ static void mmp_pdma_free_phy(struct mmp_pdma_chan *pchan)
return;
/* clear the channel mapping in DRCMR */
- reg = DRCMR(pchan->drcmr);
+ reg = mmp_pdma_get_drcmr(pdev, pchan->drcmr);
writel(0, pchan->phy->base + reg);
spin_lock_irqsave(&pdev->phy_lock, flags);
@@ -1179,6 +1190,7 @@ static const struct mmp_pdma_ops marvell_pdma_v1_ops = {
.get_desc_dst_addr = get_desc_dst_addr_32,
.run_bits = (DCSR_RUN),
.dma_width = 32,
+ .drcmr_ext_base = DRCMR_EXT_BASE_DEFAULT,
};
static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
@@ -1192,6 +1204,7 @@ static const struct mmp_pdma_ops spacemit_k1_pdma_ops = {
.get_desc_dst_addr = get_desc_dst_addr_64,
.run_bits = (DCSR_RUN | DCSR_LPAEEN),
.dma_width = 64,
+ .drcmr_ext_base = DRCMR_EXT_BASE_DEFAULT,
};
static const struct of_device_id mmp_pdma_dt_ids[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v3 5/5] riscv: dts: spacemit: Add PDMA controller node for K3 SoC
From: Troy Mitchell @ 2026-03-31 8:27 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: dmaengine, devicetree, linux-riscv, spacemit, linux-kernel,
linux-clk, Troy Mitchell
In-Reply-To: <20260331-k3-pdma-v3-0-a4e60dd8b4b3@linux.spacemit.com>
Add the Peripheral DMA (PDMA) controller node for the SpacemiT K3 SoC.
The PDMA controller provides general-purpose DMA capabilities for various
peripheral devices across the system to offload CPU data transfers.
Unlike the previous K1 SoC, where some DMA masters had memory addressing
limitations (e.g. restricted to the 0-4GB space) requiring a dedicated dma-bus
with dma-ranges to restrict memory allocations, the K3 DMA masters have
full memory addressing capabilities. Therefore, the PDMA node is now
instantiated directly under the main soc bus.
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
arch/riscv/boot/dts/spacemit/k3.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index a3a8ceddabec..cd321975fc18 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -438,6 +438,17 @@ soc: soc {
dma-noncoherent;
ranges;
+ pdma: dma-controller@d4000000 {
+ compatible = "spacemit,k3-pdma";
+ reg = <0x0 0xd4000000 0x0 0x4000>;
+ clocks = <&syscon_apmu CLK_APMU_DMA>;
+ resets = <&syscon_apmu RESET_APMU_DMA>;
+ interrupts = <72 IRQ_TYPE_LEVEL_HIGH>;
+ dma-channels = <16>;
+ #dma-cells = <1>;
+ status = "disabled";
+ };
+
syscon_apbc: system-controller@d4015000 {
compatible = "spacemit,k3-syscon-apbc";
reg = <0x0 0xd4015000 0x0 0x1000>;
--
2.53.0
^ permalink raw reply related
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