* Re: [PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
From: Philipp Zabel @ 2026-07-02 9:01 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <84C4450E-7355-48CD-BCBB-CF619C27EBED@gmail.com>
On Di, 2026-06-30 at 11:53 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> > Am 30.06.2026 um 11:27 schrieb Philipp Zabel <p.zabel@pengutronix.de>:
> >
> > I think the MFD driver is unnecessary overhead. Can't you just keep the
> > reset controllers as auxdev and use of_platform_populate() to create
> > devices for clock-controller child nodes such as syscon-reboot?
>
> MFD for top and matrix was the suggestion of Conor:
>
> https://lore.kernel.org/linux-arm-kernel/20260618-fantasy-estimate-6c52edbc6890@spud/
>
> To quote:
>
> > I think aux bus makes perfect sense when you have a clock/reset
> > controller, but once you start expanding past that and you have reboot
> > or hwmon or hwspinlock then mfd starts to make sense.
Note how the example Conor gives is introduced with:
> > Because I messed up stuff in the past, reset-mpfs.c has both aux bus
> > and mfd probing in it, [...]
So while, yes, this is possible, I'd like to avoid it if not necessary.
> I can go either way. To me aux vs mfd seems like a distinction without a difference.
I think that's because the main difference doesn't apply here:
MFD comes from aggregate devices where a shared register space
accessible via a physical bus (which we have) can be partitioned out to
child devices. Reset controls are often just individual registers or
even bits scattered around the CRU register space, so we can't make use
of the MFD framework's IO/IRQ resource partitioning infrastructure at
all.
Auxiliary devices were introduced to separate functionality of a single
device into subsystem drivers (which applies here) for devices that are
not just controlled via direct register access, for example via a
firmware interface. That's not the case here, we usually can just share
a regmap.
Either way, I'd prefer the reset driver to not carry more boilerplate
than actual reset code, so if you can either put all of them into a
single auxiliary_driver or into a single platform_driver, I would be
happier.
regards
Philipp
^ permalink raw reply
* [PATCH v5 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
This series adds GPIO support for the Realtek DHC RTD1625 SoC.
Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
the RTD1625 features a per-pin register architecture where each GPIO line
is managed by its own dedicated 32-bit control register. This distinct
hardware design requires a new, separate driver.
Best Regards,
Yu-Chun Lin
---
Changes in v5:
Patch 3 (driver):
- Add comment for @base_offset.
- Rename the local 'gpio_irq_chip' pointer to 'girq' to match common
GPIO IRQ naming.
- Drop the intermediate variable.
v4: https://lore.kernel.org/lkml/20260622092335.1166876-1-eleanor.lin@realtek.com/
v3: https://lore.kernel.org/lkml/20260512033317.1602537-1-eleanor.lin@realtek.com/
v2: https://lore.kernel.org/lkml/20260408025243.1155482-1-eleanor.lin@realtek.com/
v1: https://lore.kernel.org/lkml/20260331113835.3510341-1-eleanor.lin@realtek.com/
Tzuyi Chang (2):
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Yu-Chun Lin (2):
gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
arm64: dts: realtek: Add GPIO support for RTD1625
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 ++
arch/arm64/boot/dts/realtek/kent.dtsi | 39 ++
drivers/gpio/Kconfig | 14 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 610 ++++++++++++++++++
5 files changed, 734 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
create mode 100644 drivers/gpio/gpio-rtd1625.c
--
2.43.0
^ permalink raw reply
* [PATCH v5 2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
Replace "default y" with "default ARCH_REALTEK" to avoid bloating the build
for non-Realtek platforms when COMPILE_TEST is enabled on other platforms.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 28cf6d2e83c2..ed2bc3113374 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -646,7 +646,7 @@ config GPIO_ROCKCHIP
config GPIO_RTD
tristate "Realtek DHC GPIO support"
depends on ARCH_REALTEK || COMPILE_TEST
- default y
+ default ARCH_REALTEK
select GPIOLIB_IRQCHIP
help
This option enables support for GPIOs found on Realtek DHC(Digital
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Krzysztof Kozlowski
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add the device tree bindings for the Realtek DHC (Digital Home Center)
RTD1625 GPIO controllers.
The RTD1625 GPIO controller features a per-pin register architecture
that differs significantly from previous generations. It utilizes
separate register blocks for GPIO configuration and interrupt control.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
new file mode 100644
index 000000000000..f13c910b73c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,rtd1625-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1625 GPIO controller
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description: |
+ GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
+ architecture that differs significantly from earlier RTD series controllers.
+ Each GPIO has dedicated registers for configuration (direction, input/output
+ values, debounce), and interrupt control supporting edge and level detection
+ modes.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-iso-gpio
+ - realtek,rtd1625-isom-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Interrupt number of the assert GPIO interrupt, which is
+ triggered when there is a rising edge.
+ - description: Interrupt number of the deassert GPIO interrupt, which is
+ triggered when there is a falling edge.
+ - description: Interrupt number of the level-sensitive GPIO interrupt,
+ triggered by a configured logic level.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-ranges: true
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-ranges
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ interrupt-parent = <&iso_m_irq_mux>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Bartosz Golaszewski
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
Add the GPIO node for the Realtek RTD1625 SoC.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
arch/arm64/boot/dts/realtek/kent.dtsi | 39 +++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index 8d4293cd4c03..228b82dfdb7a 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -151,6 +151,37 @@ uart0: serial@7800 {
status = "disabled";
};
+ gpio: gpio@31000 {
+ compatible = "realtek,rtd1625-iso-gpio";
+ reg = <0x31000 0x398>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 2>,
+ <&ve4_pinctrl 2 0 6>,
+ <&iso_pinctrl 8 0 4>,
+ <&ve4_pinctrl 12 6 2>,
+ <&main2_pinctrl 14 0 2>,
+ <&ve4_pinctrl 16 8 4>,
+ <&main2_pinctrl 20 2 3>,
+ <&ve4_pinctrl 23 12 3>,
+ <&iso_pinctrl 26 4 2>,
+ <&isom_pinctrl 28 2 2>,
+ <&ve4_pinctrl 30 15 6>,
+ <&main2_pinctrl 36 5 6>,
+ <&ve4_pinctrl 42 21 3>,
+ <&iso_pinctrl 45 6 6>,
+ <&ve4_pinctrl 51 24 1>,
+ <&iso_pinctrl 52 12 1>,
+ <&ve4_pinctrl 53 25 11>,
+ <&main2_pinctrl 64 11 28>,
+ <&ve4_pinctrl 92 36 2>,
+ <&iso_pinctrl 94 13 19>,
+ <&iso_pinctrl 128 32 4>,
+ <&ve4_pinctrl 132 38 13>,
+ <&iso_pinctrl 145 36 19>,
+ <&ve4_pinctrl 164 51 2>;
+ #gpio-cells = <2>;
+ };
+
iso_pinctrl: pinctrl@4e000 {
compatible = "realtek,rtd1625-iso-pinctrl";
reg = <0x4e000 0x1a4>;
@@ -161,6 +192,14 @@ main2_pinctrl: pinctrl@4f200 {
reg = <0x4f200 0x50>;
};
+ iso_m_gpio: gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ #gpio-cells = <2>;
+ };
+
isom_pinctrl: pinctrl@146200 {
compatible = "realtek,rtd1625-isom-pinctrl";
reg = <0x146200 0x34>;
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
which manages pins via shared bank registers, the RTD1625 introduces
a per-pin register architecture. Each GPIO line now has its own
dedicated 32-bit control register to manage configuration independently,
including direction, output value, input value, interrupt enable, and
debounce. Therefore, this distinct hardware design requires a separate
driver.
Additionally, the RTD1625 GPIO controller has a specific hardware quirk:
it fires both 'assert' and 'de-assert' interrupts simultaneously on any
edge toggle. To handle this, we utilize the polarity register to route
the requested edge (rising/falling) to the 'assert' IRQ line. The driver
then filters out the unwanted 'de-assert' interrupt in the IRQ handler
and pre-clears edge interrupts to prevent interrupt storms caused by
unhandled dropped interrupts.
Interrupt support is optional for this device, matching the dt-bindings.
If the interrupts property is not provided, the driver simply skips IRQ
initialization and operates purely as a basic GPIO controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- Add comment for @base_offset.
- Rename the local 'gpio_irq_chip' pointer to 'girq' to match common
GPIO IRQ naming.
- Drop the intermediate variable.
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 610 ++++++++++++++++++++++++++++++++++++
3 files changed, 623 insertions(+)
create mode 100644 drivers/gpio/gpio-rtd1625.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed2bc3113374..f03c05288376 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -656,6 +656,18 @@ config GPIO_RTD
Say yes here to support GPIO functionality and GPIO interrupt on
Realtek DHC SoCs.
+config GPIO_RTD1625
+ tristate "Realtek DHC RTD1625 GPIO support"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ default ARCH_REALTEK
+ select GPIOLIB_IRQCHIP
+ help
+ This option enables support for the GPIO controller on Realtek
+ DHC (Digital Home Center) RTD1625 SoC.
+
+ Say yes here to support both basic GPIO line functionality
+ and GPIO interrupt handling capabilities for this platform.
+
config GPIO_SAMA5D2_PIOBU
tristate "SAMA5D2 PIOBU GPIO support"
depends on OF
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4d0e900402fc..fa14581e3995 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
obj-$(CONFIG_GPIO_REG) += gpio-reg.o
obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
+obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
new file mode 100644
index 000000000000..27af1ac65d28
--- /dev/null
+++ b/drivers/gpio/gpio-rtd1625.c
@@ -0,0 +1,610 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek DHC RTD1625 gpio driver
+ *
+ * Copyright (c) 2023-2026 Realtek Semiconductor Corp.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define RTD1625_GPIO_DIR BIT(0)
+#define RTD1625_GPIO_OUT BIT(2)
+#define RTD1625_GPIO_IN BIT(4)
+#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
+#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
+#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
+#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
+#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
+#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
+
+#define RTD1625_GPIO_WREN(x) ((x) << 1)
+
+/* Write-enable masks for all GPIO configs and reserved hardware bits */
+#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
+#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
+
+#define RTD1625_GPIO_DEBOUNCE_1US 0
+#define RTD1625_GPIO_DEBOUNCE_10US 1
+#define RTD1625_GPIO_DEBOUNCE_100US 2
+#define RTD1625_GPIO_DEBOUNCE_1MS 3
+#define RTD1625_GPIO_DEBOUNCE_10MS 4
+#define RTD1625_GPIO_DEBOUNCE_20MS 5
+#define RTD1625_GPIO_DEBOUNCE_30MS 6
+#define RTD1625_GPIO_DEBOUNCE_50MS 7
+
+#define GPIO_CONTROL(gpio) ((gpio) * 4)
+
+enum rtd1625_irq_index {
+ RTD1625_IRQ_ASSERT,
+ RTD1625_IRQ_DEASSERT,
+ RTD1625_IRQ_LEVEL,
+ RTD1625_MAX_IRQS
+};
+
+/**
+ * struct rtd1625_gpio_info - Specific GPIO register information
+ * @num_gpios: The number of GPIOs
+ * @irq_type_support: Supported IRQ types
+ * @base_offset: Offset for GPIO controller register
+ * @gpa_offset: Offset for GPIO assert interrupt status registers
+ * @gpda_offset: Offset for GPIO deassert interrupt status registers
+ * @level_offset: Offset of level interrupt status register
+ * @write_en_all: Write-enable mask for all configurable bits
+ */
+struct rtd1625_gpio_info {
+ unsigned int num_gpios;
+ unsigned int irq_type_support;
+ unsigned int base_offset;
+ unsigned int gpa_offset;
+ unsigned int gpda_offset;
+ unsigned int level_offset;
+ unsigned int write_en_all;
+};
+
+struct rtd1625_gpio {
+ struct gpio_chip gpio_chip;
+ const struct rtd1625_gpio_info *info;
+ void __iomem *base;
+ void __iomem *irq_base;
+ unsigned int irqs[RTD1625_MAX_IRQS];
+ raw_spinlock_t lock;
+ unsigned int *save_regs;
+};
+
+static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpa_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpda_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->level_offset + ((offset / 32) * 4);
+}
+
+static int rtd1625_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u8 deb_val;
+ u32 val;
+
+ switch (debounce) {
+ case 1:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1US;
+ break;
+ case 10:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10US;
+ break;
+ case 100:
+ deb_val = RTD1625_GPIO_DEBOUNCE_100US;
+ break;
+ case 1000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1MS;
+ break;
+ case 10000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10MS;
+ break;
+ case 20000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_20MS;
+ break;
+ case 30000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_30MS;
+ break;
+ case 50000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_50MS;
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ val = FIELD_PREP(RTD1625_GPIO_DEBOUNCE, deb_val) | RTD1625_GPIO_DEBOUNCE_WREN;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ u32 debounce;
+
+ if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ return rtd1625_gpio_set_debounce(chip, offset, debounce);
+ }
+
+ return gpiochip_generic_config(chip, offset, config);
+}
+
+static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
+
+ if (value)
+ val |= RTD1625_GPIO_OUT;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return !!(val & RTD1625_GPIO_OUT);
+ else
+ return !!(val & RTD1625_GPIO_IN);
+}
+
+static int rtd1625_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
+static int rtd1625_gpio_set_direction(struct gpio_chip *chip, unsigned int offset, bool out)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_DIR);
+
+ if (out)
+ val |= RTD1625_GPIO_DIR;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ return rtd1625_gpio_set_direction(chip, offset, false);
+}
+
+static int rtd1625_gpio_direction_output(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ rtd1625_gpio_set(chip, offset, value);
+
+ return rtd1625_gpio_set_direction(chip, offset, true);
+}
+
+static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
+{
+ unsigned int (*get_reg_offset)(struct rtd1625_gpio *gpio, unsigned int offset);
+ struct rtd1625_gpio *data = irq_desc_get_handler_data(desc);
+ struct irq_domain *domain = data->gpio_chip.irq.domain;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int irq = irq_desc_get_irq(desc);
+ unsigned long status;
+ unsigned int reg_offset, i, j;
+ irq_hw_number_t hwirq;
+ u32 irq_type;
+
+ if (irq == data->irqs[RTD1625_IRQ_ASSERT])
+ get_reg_offset = &rtd1625_gpio_gpa_offset;
+ else if (irq == data->irqs[RTD1625_IRQ_DEASSERT])
+ get_reg_offset = &rtd1625_gpio_gpda_offset;
+ else if (irq == data->irqs[2])
+ get_reg_offset = &rtd1625_gpio_level_offset;
+ else
+ return;
+
+ chained_irq_enter(chip, desc);
+
+ for (i = 0; i < data->info->num_gpios; i += 32) {
+ reg_offset = get_reg_offset(data, i);
+ status = readl_relaxed(data->irq_base + reg_offset);
+
+ /*
+ * Hardware quirk: The controller fires both "assert" and "de-assert"
+ * interrupts simultaneously on any edge toggle.
+ * We must pre-clear edge interrupts here. If we drop an unwanted
+ * de-assert interrupt below, it will never reach the IRQ core
+ * (generic_handle_domain_irq), meaning ->irq_ack() won't be called.
+ * Failing to clear it here leads to an interrupt storm.
+ */
+ if (irq != data->irqs[RTD1625_IRQ_LEVEL])
+ writel_relaxed(status, data->irq_base + reg_offset);
+
+ for_each_set_bit(j, &status, 32) {
+ hwirq = i + j;
+ irq_type = irq_get_trigger_type(irq_find_mapping(domain, hwirq));
+
+ /*
+ * Filter out the hardware-forced de-assert interrupt unless
+ * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
+ */
+ if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
+ irq_type != IRQ_TYPE_EDGE_BOTH)
+ continue;
+
+ generic_handle_domain_irq(domain, hwirq);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static void rtd1625_gpio_ack_irq(struct irq_data *d)
+{
+ struct rtd1625_gpio *data = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ u32 bit_mask = BIT(hwirq % 32);
+ int reg_offset;
+
+ if (irq_type & IRQ_TYPE_LEVEL_MASK) {
+ reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ writel_relaxed(bit_mask, data->irq_base + reg_offset);
+ }
+}
+
+static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
+ int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
+ writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
+ val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int level_reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + level_reg_offset);
+ val = RTD1625_GPIO_LEVEL_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ gpiochip_enable_irq(gc, hwirq);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_enable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_enable_level_irq(data, hwirq);
+}
+
+static void rtd1625_gpio_disable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_disable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_disable_level_irq(data, hwirq);
+
+ gpiochip_disable_irq(gc, hwirq);
+}
+
+static int rtd1625_gpio_irq_set_level_type(struct irq_data *d, bool level)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK))
+ return -EINVAL;
+
+ if (level)
+ val |= RTD1625_GPIO_LEVEL_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_level_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_edge_type(struct irq_data *d, bool polarity)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_EDGE_BOTH))
+ return -EINVAL;
+
+ if (polarity)
+ val |= RTD1625_GPIO_EDGE_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_edge_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ switch (type & IRQ_TYPE_SENSE_MASK) {
+ case IRQ_TYPE_EDGE_RISING:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_EDGE_FALLING:
+ return rtd1625_gpio_irq_set_edge_type(d, 0);
+
+ case IRQ_TYPE_EDGE_BOTH:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ return rtd1625_gpio_irq_set_level_type(d, 0);
+
+ case IRQ_TYPE_LEVEL_LOW:
+ return rtd1625_gpio_irq_set_level_type(d, 1);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static struct irq_chip rtd1625_iso_gpio_irq_chip = {
+ .name = "rtd1625-gpio",
+ .irq_ack = rtd1625_gpio_ack_irq,
+ .irq_mask = rtd1625_gpio_disable_irq,
+ .irq_unmask = rtd1625_gpio_enable_irq,
+ .irq_set_type = rtd1625_gpio_irq_set_type,
+ .flags = IRQCHIP_IMMUTABLE | IRQCHIP_SKIP_SET_WAKE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
+static int rtd1625_gpio_setup_irq(struct platform_device *pdev, struct rtd1625_gpio *data)
+{
+ struct gpio_irq_chip *girq;
+ unsigned int num_irqs;
+ int irq;
+
+ /*
+ * Interrupt support is optional. All IRQs must be provided together.
+ * If index 0 is missing, we assume no interrupts are configured in DT
+ * and fall back to basic GPIO operation.
+ */
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -ENXIO)
+ return 0;
+ if (irq < 0)
+ return irq;
+
+ num_irqs = (data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK) ? 3 : 2;
+ data->irqs[RTD1625_IRQ_ASSERT] = irq;
+
+ for (unsigned int i = 1; i < num_irqs; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+ data->irqs[i] = irq;
+ }
+
+ girq = &data->gpio_chip.irq;
+ girq->handler = handle_bad_irq;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->parent_handler = rtd1625_gpio_irq_handle;
+ girq->parent_handler_data = data;
+ girq->num_parents = num_irqs;
+ girq->parents = data->irqs;
+
+ gpio_irq_chip_set_chip(girq, &rtd1625_iso_gpio_irq_chip);
+
+ return 0;
+}
+
+static int rtd1625_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rtd1625_gpio *data;
+ void __iomem *irq_base;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->info = device_get_match_data(dev);
+ if (!data->info)
+ return -EINVAL;
+
+ raw_spin_lock_init(&data->lock);
+
+ irq_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(irq_base))
+ return PTR_ERR(irq_base);
+
+ data->irq_base = irq_base;
+ data->base = irq_base + data->info->base_offset;
+
+ data->save_regs = devm_kcalloc(dev, data->info->num_gpios, sizeof(*data->save_regs),
+ GFP_KERNEL);
+ if (!data->save_regs)
+ return -ENOMEM;
+
+ data->gpio_chip.label = dev_name(dev);
+ data->gpio_chip.base = -1;
+ data->gpio_chip.ngpio = data->info->num_gpios;
+ data->gpio_chip.request = gpiochip_generic_request;
+ data->gpio_chip.free = gpiochip_generic_free;
+ data->gpio_chip.get_direction = rtd1625_gpio_get_direction;
+ data->gpio_chip.direction_input = rtd1625_gpio_direction_input;
+ data->gpio_chip.direction_output = rtd1625_gpio_direction_output;
+ data->gpio_chip.set = rtd1625_gpio_set;
+ data->gpio_chip.get = rtd1625_gpio_get;
+ data->gpio_chip.set_config = rtd1625_gpio_set_config;
+ data->gpio_chip.parent = dev;
+
+ ret = rtd1625_gpio_setup_irq(pdev, data);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, data);
+
+ return devm_gpiochip_add_data(dev, &data->gpio_chip, data);
+}
+
+static const struct rtd1625_gpio_info rtd1625_iso_gpio_info = {
+ .num_gpios = 166,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH,
+ .base_offset = 0x100,
+ .gpa_offset = 0x000,
+ .gpda_offset = 0x020,
+ .write_en_all = RTD1625_ISO_GPIO_WREN_ALL,
+};
+
+static const struct rtd1625_gpio_info rtd1625_isom_gpio_info = {
+ .num_gpios = 4,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_LOW |
+ IRQ_TYPE_LEVEL_HIGH,
+ .base_offset = 0x20,
+ .gpa_offset = 0x00,
+ .gpda_offset = 0x04,
+ .level_offset = 0x18,
+ .write_en_all = RTD1625_ISOM_GPIO_WREN_ALL,
+};
+
+static int rtd1625_gpio_suspend(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ data->save_regs[i] = readl_relaxed(data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static int rtd1625_gpio_resume(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ writel_relaxed(data->save_regs[i] | info->write_en_all,
+ data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static DEFINE_NOIRQ_DEV_PM_OPS(rtd1625_gpio_pm_ops, rtd1625_gpio_suspend, rtd1625_gpio_resume);
+
+static const struct of_device_id rtd1625_gpio_of_matches[] = {
+ { .compatible = "realtek,rtd1625-iso-gpio", .data = &rtd1625_iso_gpio_info },
+ { .compatible = "realtek,rtd1625-isom-gpio", .data = &rtd1625_isom_gpio_info },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rtd1625_gpio_of_matches);
+
+static struct platform_driver rtd1625_gpio_platform_driver = {
+ .driver = {
+ .name = "gpio-rtd1625",
+ .of_match_table = rtd1625_gpio_of_matches,
+ .pm = pm_sleep_ptr(&rtd1625_gpio_pm_ops),
+ },
+ .probe = rtd1625_gpio_probe,
+};
+module_platform_driver(rtd1625_gpio_platform_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Realtek Semiconductor Corporation");
+MODULE_DESCRIPTION("Realtek DHC SoC RTD1625 gpio driver");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Uladzislau Rezki @ 2026-07-02 9:04 UTC (permalink / raw)
To: Wen Jiang
Cc: Andrew Morton, linux-mm, linux-arm-kernel, catalin.marinas, will,
urezki, baohua, Xueyuan.chen21, dev.jain, rppt, david,
ryan.roberts, anshuman.khandual, ajd, linux-kernel, jiangwen6,
shanghaoqiang
In-Reply-To: <CAHKocdHJ-JB5jjXG3_-syz4P8k1C=jWrGaFxwnTjcinpGyR_BA@mail.gmail.com>
On Thu, Jul 02, 2026 at 02:35:24PM +0800, Wen Jiang wrote:
> On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> >
> > > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > > is physically fully or partially contiguous. Two techniques are used:
> >
> > Thanks.
> >
> > > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > > segments
> > > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > > layers
> > >
> > > Besides accelerating the mapping path, this also enables large
> > > mappings (PMD and cont-PTE) for vmap, which are currently not
> > > supported.
> > >
> > > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > > CONT-PTE regions instead of just one.
> > >
> > > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> > >
> > > Patch 4 extends the page table walk path to support page shifts other
> > > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > > to vmap_pages_range_noflush_walk().
> > >
> > > Patches 5-6 add huge vmap support for contiguous pages, including
> > > support for non-compound pages with pfn alignment verification.
> > >
> > > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > > the performance CPUfreq policy enabled, benchmark results:
> > >
> > > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > > * vmalloc(1 MB) mapping time (excluding allocation) with
> > > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
> >
> > Nice.
> >
> > > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> >
> > Indeed.
> >
> > I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> > folks) have time to go through this.
> >
> > Is there any effect on anything other than arm64? I'm wondering how
> > much testing these changes will really get in mm.git and linux-next.
> >
> > How is our selftests coverage of these changes? Is there some existing
> > selftest which will exercise these new features?
> >
>
> Hi Andrew,
>
> I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
> x86_64, comparing base (v7.0.10) against the patched kernel.
>
> All test_vmalloc subtests passed on both platforms. I do not see any
> functional or performance regression. The small differences below look
> like measurement noise.
>
> ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
> 5 runs averaged):
>
I think there are still comments to this series. One from me about
naming and there is one more from Jain here: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
Could you please have a look?
--
Uladzislau Rezki
^ permalink raw reply
* [PATCH RFC] dt-bindings: perf: riscv,pmu: Add interrupts-extended property
From: Eric Lin @ 2026-07-02 9:04 UTC (permalink / raw)
To: Will Deacon, Mark Rutland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Atish Patra
Cc: linux-arm-kernel, linux-perf-users, devicetree, linux-riscv,
linux-kernel, Nick Hu, Eric Lin
The interrupts-extended property is used to specify the connection
between the PMU counter overflow interrupt and the corresponding CPU
local interrupt controller (riscv,cpu-intc).
This property also allows the software to associate a PMU node with a
specific CPU. To support future heterogeneous systems, where different
CPUs may support different PMU events, this property allows the driver
to identify the correct PMU capabilities for each hart.
Reviewed-by: Nick Hu <nick.hu@sifive.com>
Signed-off-by: Eric Lin <eric.lin@sifive.com>
---
Documentation/devicetree/bindings/perf/riscv,pmu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
index d01c677ad3c7..13aceb3d42b9 100644
--- a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
+++ b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
@@ -34,6 +34,13 @@ properties:
compatible:
const: riscv,pmu
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4095
+ description:
+ Specifies the interrupt-parent and local interrupt index for each CPU's
+ PMU counter overflow. Each item points to a riscv,cpu-intc node.
+
riscv,event-to-mhpmevent:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
description:
@@ -101,6 +108,7 @@ examples:
- |
pmu {
compatible = "riscv,pmu";
+ interrupts-extended = <&cpu0_intc 13>;
riscv,event-to-mhpmevent = <0x0000B 0x0000 0x0001>;
riscv,event-to-mhpmcounters = <0x00001 0x00001 0x00000001>,
<0x00002 0x00002 0x00000004>,
@@ -127,6 +135,9 @@ examples:
*/
pmu {
compatible = "riscv,pmu";
+ interrupts-extended = <&cpu0_intc 13>,
+ <&cpu1_intc 13>,<&cpu2_intc 13>,
+ <&cpu3_intc 13>,<&cpu4_intc 13>;
riscv,event-to-mhpmevent =
/* SBI_PMU_HW_CACHE_REFERENCES -> Instruction or Data cache/ITIM busy */
<0x00003 0x00000000 0x1801>,
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260701-pmu-dt-property-ff12b35fe0fc
Best regards,
--
Eric Lin <eric.lin@sifive.com>
^ permalink raw reply related
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Dev Jain @ 2026-07-02 9:08 UTC (permalink / raw)
To: Muchun Song
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, david, liam
In-Reply-To: <97a43d82-28c2-4f98-ad74-fe05ed9f0297@linux.dev>
On 02/07/26 2:17 pm, Muchun Song wrote:
>
>
> On 2026/7/2 13:13, Dev Jain wrote:
>> try_to_unmap_one() handles hugetlb folios when memory failure needs
>> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
>> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
>> in pvmw.pte, but the code reads it with ptep_get().
>>
>> On arches which provide their own huge_ptep_get() to dereference a huge
>> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
>> etc to misbehave.
>>
>> It is not clear whether this has a trivially visible effect to userspace.
>>
>> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>>
>> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
>> Cc: stable@vger.kernel.org
>> Reported-by: David Hildenbrand <david@kernel.org>
>> Signed-off-by: Dev Jain <dev.jain@arm.com>
>> ---
>> include/linux/hugetlb.h | 3 +++
>> mm/rmap.c | 16 ++++++++++------
>> 2 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 2abaf99321e90..fdb7bdf7645c5 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
>> {
>> }
>> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
>> + pte_t *ptep);
>> +
>
> Maybe I didn't express my thoughts clearly in the first version, let me
> explain in more detail.
>
> We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
> set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
> in your previous version). Currently, you've added a declaration, but the
> function itself doesn't actually exist, which seems quite strange to me.
https://lore.kernel.org/all/a4fe8ba6-2ecd-4bb9-95a9-27f9f1e87d2e@kernel.org/
David suggested this. Honestly I quite like David's suggestion, what do you
think?
>
> Muchun,
> Thanks.
>> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>> unsigned long addr, pte_t *ptep)
>> {
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 1c77d5dc06e9f..aa8a254efaecc 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
>> /* Unexpected PMD-mapped THP? */
>> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>> - /*
>> - * Handle PFN swap PTEs, such as device-exclusive ones, that
>> - * actually map pages.
>> - */
>> - pteval = ptep_get(pvmw.pte);
>> + address = pvmw.address;
>> + if (folio_test_hugetlb(folio)) {
>> + pteval = huge_ptep_get(mm, address, pvmw.pte);
>> + } else {
>> + /*
>> + * Handle PFN swap PTEs, such as device-exclusive ones,
>> + * that actually map pages.
>> + */
>> + pteval = ptep_get(pvmw.pte);
>> + }
>> if (likely(pte_present(pteval))) {
>> pfn = pte_pfn(pteval);
>> } else {
>> @@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
>> }
>> subpage = folio_page(folio, pfn - folio_pfn(folio));
>> - address = pvmw.address;
>> anon_exclusive = folio_test_anon(folio) &&
>> PageAnonExclusive(subpage);
>>
>
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-07-02 9:12 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: Andrew Morton, linux-mm, linux-arm-kernel, catalin.marinas, will,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <akYplZcaLXIl7AsP@pc636>
On Thu, 2 Jul 2026 at 17:04, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, Jul 02, 2026 at 02:35:24PM +0800, Wen Jiang wrote:
> > On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> > >
> > > > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > > > is physically fully or partially contiguous. Two techniques are used:
> > >
> > > Thanks.
> > >
> > > > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > > > segments
> > > > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > > > layers
> > > >
> > > > Besides accelerating the mapping path, this also enables large
> > > > mappings (PMD and cont-PTE) for vmap, which are currently not
> > > > supported.
> > > >
> > > > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > > > CONT-PTE regions instead of just one.
> > > >
> > > > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > > > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > > > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> > > >
> > > > Patch 4 extends the page table walk path to support page shifts other
> > > > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > > > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > > > to vmap_pages_range_noflush_walk().
> > > >
> > > > Patches 5-6 add huge vmap support for contiguous pages, including
> > > > support for non-compound pages with pfn alignment verification.
> > > >
> > > > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > > > the performance CPUfreq policy enabled, benchmark results:
> > > >
> > > > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > > > * vmalloc(1 MB) mapping time (excluding allocation) with
> > > > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > > > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
> > >
> > > Nice.
> > >
> > > > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> > >
> > > Indeed.
> > >
> > > I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> > > folks) have time to go through this.
> > >
> > > Is there any effect on anything other than arm64? I'm wondering how
> > > much testing these changes will really get in mm.git and linux-next.
> > >
> > > How is our selftests coverage of these changes? Is there some existing
> > > selftest which will exercise these new features?
> > >
> >
> > Hi Andrew,
> >
> > I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
> > x86_64, comparing base (v7.0.10) against the patched kernel.
> >
> > All test_vmalloc subtests passed on both platforms. I do not see any
> > functional or performance regression. The small differences below look
> > like measurement noise.
> >
> > ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
> > 5 runs averaged):
> >
> I think there are still comments to this series. One from me about
> naming and there is one more from Jain here: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
>
> Could you please have a look?
Hi Uladzislau,
Thanks for the reminder. I’ve already gone through all the review
comments, but haven’t had time to reply yet. All the feedback will be
addressed in the v5 version.
Thanks.
>
> --
> Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Bartosz Golaszewski @ 2026-07-02 9:12 UTC (permalink / raw)
To: Vinod Koul
Cc: Bartosz Golaszewski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, Giuseppe Cavallaro, Chen-Yu Tsai,
Jernej Skrabec, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Shawn Guo, Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar,
Romain Gantois, Magnus Damm, Maxime Ripard, Christophe Roullier,
Radu Rendec, linux-arm-msm, devicetree, linux-kernel, netdev,
linux-stm32, linux-arm-kernel, Drew Fustini, linux-sunxi,
linux-amlogic, linux-mips, imx, linux-renesas-soc, linux-rockchip,
sophgo, linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski,
Geert Uytterhoeven
In-Reply-To: <akOZFIowVvprnAMf@vaman>
On Tue, 30 Jun 2026 12:23:16 +0200, Vinod Koul <vkoul@kernel.org> said:
> On 29-06-26, 16:51, Geert Uytterhoeven wrote:
>> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
>> > driver instead of the MAC driver where it was previously. Instead of cramming
>> > both HLOS and firmware handling into the same driver, I figured it makes more
>> > sense to have a dedicated, cleaner driver as the two share very little code (if
>> > any).
>>
>> I think you are mixing up DT bindings and driver implementation?
>
> Should the bindings change if we have different driver and firmware
> implementations? Isn't binding supposed to be agnostic of
> implementations..?
>
I've thought about it some more and I believe this question is philosophical in
nature.
sa8775p and sa8255p are *the same* hardware. I can flash different firmware on
the same Lemans Ride board and it becomes one or the other. Yet they are not
described by the same DTS and the bindings differ as well. I don't see why we
wouldn't allow the same approach for the this PHY.
We treat it as different HW variant when it's managed by firmware - just like
we do with the rest of the SoC.
Bart
^ permalink raw reply
* Re: [PATCH v4 5/6] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Wen Jiang @ 2026-07-02 9:18 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <akPKkOt_GNbAbyN5@milan>
On Tue, 30 Jun 2026 at 21:54, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 04:47:25PM +0800, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > In many cases, the pages passed to vmap() may include high-order
> > pages. For example, the systemheap often allocates pages in descending
> > order: order 8, then 4, then 0. Currently, vmap() iterates over every
> > page individually—even pages inside a high-order block are handled
> > one by one.
> >
> > This patch detects physically contiguous pages (regardless of whether
> > they are compound or non-compound) by scanning with
> > num_pages_contiguous(), and maps them as a single contiguous block
> > whenever possible. The mapping order is determined by taking the
> > minimum of the contiguous page count and the pfn alignment, allowing
> > graceful degradation when pfn alignment is less than the contiguous
> > range.
> >
> > Pages with the same page_shift are coalesced and mapped via
> > vmap_pages_range_noflush_walk() to avoid page table rewalk.
> >
> > As users typically allocate memory in descending orders (e.g.
> > 8 → 4 → 0), once an order-0 page is encountered, we stop scanning
> > for contiguous pages since subsequent pages are likely order-0 as well.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Co-developed-by: Dev Jain <dev.jain@arm.com>
> > Signed-off-by: Dev Jain <dev.jain@arm.com>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 85 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 253e017130e09..fffb885cb2158 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3545,6 +3545,89 @@ void vunmap(const void *addr)
> > }
> > EXPORT_SYMBOL(vunmap);
> >
> > +static inline unsigned int vm_shift(pgprot_t prot, unsigned long size)
> > +{
> > + if (arch_vmap_pmd_supported(prot) && size >= PMD_SIZE)
> > + return PMD_SHIFT;
> > +
> > + return arch_vmap_pte_supported_shift(size);
> > +}
> > +
> > +static inline int get_vmap_batch_order(struct page **pages,
> > + pgprot_t prot, unsigned int max_steps, unsigned int idx)
> > +{
> > + unsigned int nr_contig;
> > + int order;
> > +
> > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
> > + return 0;
> > +
> > + nr_contig = num_pages_contiguous(&pages[idx], max_steps);
> > + if (nr_contig < 2)
> > + return 0;
> > +
> > + order = ilog2(nr_contig);
> > +
> > + /* Limit order by pfn alignment */
> > + order = min_t(int, order, __ffs(page_to_pfn(pages[idx])));
> > +
> > + if (vm_shift(prot, PAGE_SIZE << order) == PAGE_SHIFT)
> > + return 0;
> > +
> > + return order;
> > +}
> > +
> > +static int vmap_batched(unsigned long addr, unsigned long end,
> > + pgprot_t prot, struct page **pages)
> > +{
> > + unsigned int count = (end - addr) >> PAGE_SHIFT;
> > + unsigned int prev_shift = 0, idx = 0;
> > + unsigned long start = addr, map_addr = addr;
> > + int err;
> > +
> > + err = kmsan_vmap_pages_range_noflush(addr, end, prot, pages,
> > + PAGE_SHIFT, GFP_KERNEL);
> > + if (err)
> > + goto out;
> > +
> > + for (unsigned int i = 0; i < count; ) {
> > + unsigned int shift = PAGE_SHIFT +
> > + get_vmap_batch_order(pages, prot, count - i, i);
> > +
> > + if (!i)
> > + prev_shift = shift;
> > +
> > + if (shift != prev_shift) {
> > + err = vmap_pages_range_noflush_walk(map_addr, addr,
> > + prot, pages + idx, prev_shift);
> > + if (err)
> > + goto out;
> > + prev_shift = shift;
> > + map_addr = addr;
> > + idx = i;
> > + }
> > +
> > + /*
> > + * Once small pages are encountered, the remaining pages
> > + * are likely small as well.
> > + */
> > + if (shift == PAGE_SHIFT)
> > + break;
> > +
> > + addr += 1UL << shift;
> > + i += 1U << (shift - PAGE_SHIFT);
> > + }
> > +
> > + /* Remaining */
> > + if (map_addr < end)
> > + err = vmap_pages_range_noflush_walk(map_addr, end,
> > + prot, pages + idx, prev_shift);
> > +
> > +out:
> > + flush_cache_vmap(start, end);
> > + return err;
> > +}
> > +
> > /**
> > * vmap - map an array of pages into virtually contiguous space
> > * @pages: array of page pointers
> > @@ -3588,8 +3671,8 @@ void *vmap(struct page **pages, unsigned int count,
> > return NULL;
> >
> > addr = (unsigned long)area->addr;
> > - if (vmap_pages_range(addr, addr + size, pgprot_nx(prot),
> > - pages, PAGE_SHIFT) < 0) {
> > + if (vmap_batched(addr, addr + size, pgprot_nx(prot),
> > + pages) < 0) {
> >
> Better naming? vmap_pages_range_batched()?
>
Yes, I’ll adopt this naming in v5.
Thanks.
> --
> Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
From: Ben Horgan @ 2026-07-02 9:20 UTC (permalink / raw)
To: Reinette Chatre
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, rohit.mathew, scott, sdonthineni, tan.shaopeng, xhao,
zengheng4, x86
In-Reply-To: <4b0552cc-85cc-40b6-ab65-6b7620149f74@intel.com>
Hi Reinette,
On 7/1/26 23:38, Reinette Chatre wrote:
> Hi Ben,
>
> On 5/20/26 2:24 PM, Ben Horgan wrote:
>> Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
>> to the user via resctrl. Add some documentation so the user knows what to
>> expect.
>>
>> Co-developed-by: James Morse <james.morse@arm.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>> ---
>> Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
>> index 570f51a8d4eb..208ff17068c4 100644
>> --- a/Documentation/arch/arm64/mpam.rst
>> +++ b/Documentation/arch/arm64/mpam.rst
>> @@ -65,6 +65,23 @@ The supported features are:
>> there is at least one CSU monitor on each MSC that makes up the L3 group.
>> Exposing CSU counters from other caches or devices is not supported.
>>
>> +* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
>> + L3 cache-id to identify where the memory bandwidth is measured. For this
>> + reason the platform must have an L3 cache with cache-id's supplied by
>> + firmware. (It doesn't need to support MPAM.)
>> +
>> + Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
>> + makes up the L3 group. If the memory bandwidth monitoring is on the memory
>> + rather than the L3 then there must be a single global L3 as otherwise it
>> + is unknown which L3 the traffic came from.
>> +
>> + To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
>> + match the topology of the L3 cache so that the cache-id's can be
>> + repainted. For example: Platforms with Memory bandwidth monitors on
>> + CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
>> + have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
>> + cannot distinguish local traffic from global traffic.
>
> Hopefully we can get to a point where memory bandwidth monitoring data from
> CPU-less NUMA nodes can be exposed via resctrl. When considering such possible
Thank you for your interest here. I hope so too.
> future I think it may make this work easier to build on if the documentation
> focuses on what the current implementation supports and leave room for
> future enhancements by not constraining user space expectation with an absolute
> like "CPU-less NUMA nodes cannot expose 'mbm_total_bytes'".
The intention was to describe the current limitations but I do see how
this can come across as fundamental problems rather than just that we
need to do some more work to establish how this can be done and
implement it.
How about if I add this paragraph at the end?
All these restrictions based on L3 cache are due to resctrl, currently,
only supporting monitoring at the scope of the L3 scope. It is expected
that going forward more MBWU monitors can be exposed to the user after
support for more monitoring scopes is added to resctrl.
Thanks,
Ben>
> Reinette
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Geert Uytterhoeven @ 2026-07-02 9:16 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, Giuseppe Cavallaro, Chen-Yu Tsai,
Jernej Skrabec, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Shawn Guo, Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar,
Romain Gantois, Magnus Damm, Maxime Ripard, Christophe Roullier,
Radu Rendec, linux-arm-msm, devicetree, linux-kernel, netdev,
linux-stm32, linux-arm-kernel, Drew Fustini, linux-sunxi,
linux-amlogic, linux-mips, imx, linux-renesas-soc, linux-rockchip,
sophgo, linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMRc=MfBcOhbj=ETxy2Xz9o_nyzykrEhKAc3jYi6V5_jMZEE3Q@mail.gmail.com>
Hi Bartosz,
On Thu, 2 Jul 2026 at 11:12, Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Tue, 30 Jun 2026 12:23:16 +0200, Vinod Koul <vkoul@kernel.org> said:
> > On 29-06-26, 16:51, Geert Uytterhoeven wrote:
> >> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
> >> > driver instead of the MAC driver where it was previously. Instead of cramming
> >> > both HLOS and firmware handling into the same driver, I figured it makes more
> >> > sense to have a dedicated, cleaner driver as the two share very little code (if
> >> > any).
> >>
> >> I think you are mixing up DT bindings and driver implementation?
> >
> > Should the bindings change if we have different driver and firmware
> > implementations? Isn't binding supposed to be agnostic of
> > implementations..?
>
> I've thought about it some more and I believe this question is philosophical in
> nature.
>
> sa8775p and sa8255p are *the same* hardware. I can flash different firmware on
> the same Lemans Ride board and it becomes one or the other. Yet they are not
> described by the same DTS and the bindings differ as well. I don't see why we
> wouldn't allow the same approach for the this PHY.
>
> We treat it as different HW variant when it's managed by firmware - just like
> we do with the rest of the SoC.
DT describes hardware, not software policy.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702083746.578461-1-wenst@chromium.org>
On Thu, 02 Jul 2026 16:37:45 +0800, Chen-Yu Tsai wrote:
> The SPI NOR flash is powered from the always on 1.8V power rail through
> a load switch that is controlled by the security chip.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
commit: 1f16e99cd8361b33758205eba587dbe40a82975a
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: mediatek: mt8186: change CCI OPP scaling mapping
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Matthias Brugger, devicetree,
linux-kernel, Mark Tseng
Cc: linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260529100514.52082-2-chun-jen.tseng@mediatek.com>
On Fri, 29 May 2026 18:05:08 +0800, Mark Tseng wrote:
> The original CCI OPP table minimum frequency 500Mhz is too low to cause
> system stall, So it need update to new version, 1.4G ~ 0.8G.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8186: change CCI OPP scaling mapping
commit: c41cd028e8fb138aa6243d224d637db15354ea95
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702083800.578581-1-wenst@chromium.org>
On Thu, 02 Jul 2026 16:37:58 +0800, Chen-Yu Tsai wrote:
> The SPI NOR flash is powered the "always on" 1.8V LDO regulated power
> rail.
>
> Add the supply for the SPI NOR flash.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
commit: eb3e990db356964d64f5cc258d30776c0363f9e9
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v3] drm/rockchip: Remove dependency on DRM simple helpers
From: Javier Martinez Canillas @ 2026-07-02 9:23 UTC (permalink / raw)
To: Diogo Silva, Sandy Huang, Heiko Stübner, Andy Yan
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel, Diogo Silva
In-Reply-To: <20260608124018.480365-2-diogompaissilva@gmail.com>
Diogo Silva <diogompaissilva@gmail.com> writes:
Hello Diogo,
> Simple KMS helper are deprecated since they only add an intermediate
> layer between drivers and the atomic modesetting.
> This patch removes the dependency on drm simple helpers from rockchip
> DRM drivers.
>
I think that would be more informative to say something like following:
This patch removes the drm_simple_encoder_init() helper usage in the
rockchip drivers, by open coding it and using the encoder atomic helpers
directly. This is a step to eventually get rid of this simple KMS helper,
once all drivers that use it have been converted.
> Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
> ---
The changes look good to me:
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Wen Jiang @ 2026-07-02 9:26 UTC (permalink / raw)
To: Dev Jain
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <aecf8ea2-43e3-4aad-810a-120b036d8bc2@arm.com>
On Mon, 29 Jun 2026 at 14:47, Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 18/06/26 2:17 pm, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > Try to align the vmap virtual address to PMD_SHIFT or a
> > larger PTE mapping size hinted by the architecture, so
> > contiguous pages can be batch-mapped when setting PMD or
> > PTE entries.
> >
> > Add __get_vm_area_node_aligned_caller() as a wrapper over
> > __get_vm_area_node() to simplify repeated calls with fixed
> > arguments.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 37 ++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index fffb885cb2158..bc9fa93e2bdc6 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3628,6 +3628,41 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> > return err;
> > }
> >
> > +static struct vm_struct *__get_vm_area_node_aligned_caller(unsigned long size,
> > + unsigned long align, unsigned long flags, const void *caller)
>
> There are 3 similar functions below __get_vm_area_node: they are __get_vm_area_caller,
> get_vm_area and get_vm_area_caller. You can put this one just below them.
>
>
> > +{
> > + return __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> > + VMALLOC_START, VMALLOC_END,
> > + NUMA_NO_NODE, GFP_KERNEL, caller);
> > +}
> > +
> > +static struct vm_struct *vmap_get_aligned_vm_area(unsigned long size,
> > + unsigned long flags, const void *caller)
> > +{
> > + struct vm_struct *vm_area;
> > + unsigned int shift;
> > +
> > + /* Try PMD alignment for large sizes */
>
> This comment feels excessive. Can remove it.
>
>
> > + if (size >= PMD_SIZE) {
>
> Need an arch_vmap_pmd_supported() check here.
>
>
Will add the check here.
> > + vm_area = __get_vm_area_node_aligned_caller(size, PMD_SIZE,
> > + flags, caller);
> > + if (vm_area)
> > + return vm_area;
> > + }
> > +
> > + /* Try CONT_PTE alignment */
>
> Comment feels excessive, and again no need to mention arm64 specific stuff here.
> Just remove it.
>
> > + shift = arch_vmap_pte_supported_shift(size);
> > + if (shift > PAGE_SHIFT) {
> > + vm_area = __get_vm_area_node_aligned_caller(size, 1UL << shift,
> > + flags, caller);
> > + if (vm_area)
> > + return vm_area;
> > + }
> > +
> > + /* Fall back to page alignment */
>
> This comment can also be dropped, but I am fine either way.
>
>
Will do.
> > + return __get_vm_area_node_aligned_caller(size, PAGE_SIZE, flags, caller);
> > +}
> > +
> > /**
> > * vmap - map an array of pages into virtually contiguous space
> > * @pages: array of page pointers
> > @@ -3666,7 +3701,7 @@ void *vmap(struct page **pages, unsigned int count,
> > return NULL;
> >
> > size = (unsigned long)count << PAGE_SHIFT;
> > - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> > + area = vmap_get_aligned_vm_area(size, flags, __builtin_return_address(0));
>
> So the effect is that now we search for an aligned vm_struct unconditionally. Better
> to mention in the commit message that we do not expect any significant overhead for
> this.
>
Yes, I'll mention this in v5.
Thanks.
>
> > if (!area)
> > return NULL;
> >
>
^ permalink raw reply
* [PATCH 01/18] arm64: dts: ti: k3-{j721e/j721s2}-main: Fix indentation in CSI2RX node
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fix a few minor indentation errors in the cdns csi2rx clocks and
clock-names properties.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index d5fd30a01032..5a8414fc5751 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -612,9 +612,9 @@ cdns_csi2rx0: csi-bridge@4504000 {
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 26 2>, <&k3_clks 26 0>, <&k3_clks 26 2>,
- <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
+ <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy0>;
phy-names = "dphy";
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 1228ac5711bf..5cac119e4292 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1251,9 +1251,9 @@ cdns_csi2rx0: csi-bridge@4504000 {
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 38 3>, <&k3_clks 38 1>, <&k3_clks 38 3>,
- <&k3_clks 38 3>, <&k3_clks 38 4>, <&k3_clks 38 4>;
+ <&k3_clks 38 3>, <&k3_clks 38 4>, <&k3_clks 38 4>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy0>;
phy-names = "dphy";
@@ -1307,9 +1307,9 @@ cdns_csi2rx1: csi-bridge@4514000 {
<GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 39 3>, <&k3_clks 39 1>, <&k3_clks 39 3>,
- <&k3_clks 39 3>, <&k3_clks 39 4>, <&k3_clks 39 4>;
+ <&k3_clks 39 3>, <&k3_clks 39 4>, <&k3_clks 39 4>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy1>;
phy-names = "dphy";
--
2.34.1
^ permalink raw reply related
* [PATCH 02/18] arm64: dts: ti: k3-j721e-main: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts. Add
additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 5a8414fc5751..b1988437f52d 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -600,8 +600,14 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_udmap 0x4940>;
- dma-names = "rx0";
+ dmas = <&main_udmap 0x4940>, <&main_udmap 0x4941>, <&main_udmap 0x4942>,
+ <&main_udmap 0x4943>, <&main_udmap 0x4944>, <&main_udmap 0x4945>,
+ <&main_udmap 0x4946>, <&main_udmap 0x4947>, <&main_udmap 0x4948>,
+ <&main_udmap 0x4949>, <&main_udmap 0x494a>, <&main_udmap 0x494b>,
+ <&main_udmap 0x494c>, <&main_udmap 0x494d>, <&main_udmap 0x494e>,
+ <&main_udmap 0x494f>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
+ "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", "rx14", "rx15";
power-domains = <&k3_pds 26 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -656,8 +662,14 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_udmap 0x4960>;
- dma-names = "rx0";
+ dmas = <&main_udmap 0x4960>, <&main_udmap 0x4961>, <&main_udmap 0x4962>,
+ <&main_udmap 0x4963>, <&main_udmap 0x4964>, <&main_udmap 0x4965>,
+ <&main_udmap 0x4966>, <&main_udmap 0x4967>, <&main_udmap 0x4968>,
+ <&main_udmap 0x4969>, <&main_udmap 0x496a>, <&main_udmap 0x496b>,
+ <&main_udmap 0x496c>, <&main_udmap 0x496d>, <&main_udmap 0x496e>,
+ <&main_udmap 0x496f>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
+ "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", "rx14", "rx15";
power-domains = <&k3_pds 27 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 03/18] arm64: dts: ti: k3-j721s2-main: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts. Add
additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 5cac119e4292..f4b8713873b1 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1239,8 +1239,11 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4940 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4940 0>, <&main_bcdma_csi 0 0x4941 0>,
+ <&main_bcdma_csi 0 0x4942 0>, <&main_bcdma_csi 0 0x4943 0>,
+ <&main_bcdma_csi 0 0x4944 0>, <&main_bcdma_csi 0 0x4945 0>,
+ <&main_bcdma_csi 0 0x4946 0>, <&main_bcdma_csi 0 0x4947 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 38 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -1295,8 +1298,11 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4960 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4960 0>, <&main_bcdma_csi 0 0x4961 0>,
+ <&main_bcdma_csi 0 0x4962 0>, <&main_bcdma_csi 0 0x4963 0>,
+ <&main_bcdma_csi 0 0x4964 0>, <&main_bcdma_csi 0 0x4965 0>,
+ <&main_bcdma_csi 0 0x4966 0>, <&main_bcdma_csi 0 0x4967 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 39 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 04/18] arm64: dts: ti: k3-j784s4-j742s2-main-common: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts,
Add additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
.../dts/ti/k3-j784s4-j742s2-main-common.dtsi | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index c2636e624f18..4b4545a5af19 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
@@ -811,8 +811,11 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4940 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4940 0>, <&main_bcdma_csi 0 0x4941 0>,
+ <&main_bcdma_csi 0 0x4942 0>, <&main_bcdma_csi 0 0x4943 0>,
+ <&main_bcdma_csi 0 0x4944 0>, <&main_bcdma_csi 0 0x4945 0>,
+ <&main_bcdma_csi 0 0x4946 0>, <&main_bcdma_csi 0 0x4947 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 72 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -867,8 +870,11 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4960 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4960 0>, <&main_bcdma_csi 0 0x4961 0>,
+ <&main_bcdma_csi 0 0x4962 0>, <&main_bcdma_csi 0 0x4963 0>,
+ <&main_bcdma_csi 0 0x4964 0>, <&main_bcdma_csi 0 0x4965 0>,
+ <&main_bcdma_csi 0 0x4966 0>, <&main_bcdma_csi 0 0x4967 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 73 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -922,8 +928,11 @@ ti_csi2rx2: ticsi2rx@4520000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4980 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4980 0>, <&main_bcdma_csi 0 0x4981 0>,
+ <&main_bcdma_csi 0 0x4982 0>, <&main_bcdma_csi 0 0x4983 0>,
+ <&main_bcdma_csi 0 0x4984 0>, <&main_bcdma_csi 0 0x4985 0>,
+ <&main_bcdma_csi 0 0x4986 0>, <&main_bcdma_csi 0 0x4987 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 74 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 07/18] arm64: dts: ti: k3-j721e: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J721E.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721e-evm-fusion.dtso | 191 ++++++++++++++++++
2 files changed, 195 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 21db60cd19de..7e2ed5c94e79 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -141,6 +141,7 @@ k3-j721e-evm-gesi-dtbs := k3-j721e-common-proc-board.dtb k3-j721e-evm-gesi-exp-b
dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board-infotainment.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-fusion.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo
@@ -274,6 +275,8 @@ k3-j7200-evm-pcie1-ep-dtbs := k3-j7200-common-proc-board.dtb \
k3-j7200-evm-pcie1-ep.dtbo
k3-j721e-common-proc-board-infotainment-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-common-proc-board-infotainment.dtbo
+k3-j721e-evm-fpdlink-fusion-dtbs := k3-j721e-evm.dtb \
+ k3-j721e-evm-fusion.dtbo
k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie0-ep.dtbo
k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
@@ -344,6 +347,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am69-sk-pcie0-ep.dtb \
k3-j7200-evm-pcie1-ep.dtb \
k3-j721e-common-proc-board-infotainment.dtb \
+ k3-j721e-evm-fpdlink-fusion.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
new file mode 100644
index 000000000000..0df2e48a4089
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721E EVM
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&main_i2c6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 09/18] arm64: dts: ti: k3-j721e-sk: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J721E SK.
CSI2RX connectivity on AM68-SK and AM69-SK is the same as that of J721E-SK,
hence the same overlay can be reused.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 10 +
.../dts/ti/k3-j721e-sk-fpdlink-fusion.dtso | 191 ++++++++++++++++++
2 files changed, 201 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 79ce2ff38cc3..b31bf2f305aa 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -148,6 +148,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk-csi2-dual-imx219.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk-fpdlink-fusion.dtbo
# Boards with J721s2 SoC
dtb-$(CONFIG_ARCH_K3) += k3-am68-phyboard-izar.dtb
@@ -268,8 +269,12 @@ k3-am68-sk-base-board-csi2-dual-imx219-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
k3-am68-sk-base-board-pcie1-ep.dtbo
+k3-am68-sk-fpdlink-fusion-dtbs := k3-am68-sk-base-board.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-am69-sk-csi2-dual-imx219-dtbs := k3-am69-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-am69-sk-fpdlink-fusion-dtbs := k3-am69-sk.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-am69-sk-pcie0-ep-dtbs := k3-am69-sk.dtb \
k3-am69-sk-pcie0-ep.dtbo
k3-j7200-evm-pcie1-ep-dtbs := k3-j7200-common-proc-board.dtb \
@@ -284,6 +289,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721e-sk-fpdlink-fusion-dtbs := k3-j721e-sk.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-j721s2-evm-fpdlink-fusion-dtbs := k3-j721s2-evm.dtb \
k3-j721s2-evm-fusion.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -348,7 +355,9 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am68-phyboard-izar-peb-av-15.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
k3-am68-sk-base-board-pcie1-ep.dtb \
+ k3-am68-sk-fpdlink-fusion.dtb \
k3-am69-sk-csi2-dual-imx219.dtb \
+ k3-am69-sk-fpdlink-fusion.dtb \
k3-am69-sk-pcie0-ep.dtb \
k3-j7200-evm-pcie1-ep.dtb \
k3-j721e-common-proc-board-infotainment.dtb \
@@ -356,6 +365,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtb \
k3-j721s2-evm-fpdlink-fusion.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
new file mode 100644
index 000000000000..dd82ec3accfe
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721E SK,
+ * AM68 SK or AM69 SK.
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&cam0_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX*/
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX*/
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ 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