* Re: [PATCH v5 2/4] drm/dp: Add helper to validate DP lane counts
From: Luca Ceresoli @ 2026-06-26 16:29 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260604085220.2862986-3-damon.ding@rock-chips.com>
On Thu, 04 Jun 2026 16:52:18 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
> Add a generic helper function drm_dp_lane_count_is_valid() to check
> if a DisplayPort lane count is valid. According to the DP specification,
> only 1, 2, or 4 lanes are supported.
>
> This helper avoids duplicating DP lane count validation logic across
> individual DisplayPort drivers.
>
> [...]
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 3/6] mm/vmalloc: Extract vmap_set_ptes() to consolidate PTE mapping logic
From: Uladzislau Rezki @ 2026-06-26 16:21 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260618084726.1070022-4-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:23PM +0800, Wen Jiang wrote:
> Extract the common PTE mapping logic from vmap_pte_range() into a
> shared helper vmap_set_ptes(). This handles both CONT_PTE and regular
> PTE mappings in a single function, preparing for the next patch which
> will extend vmap_pages_pte_range() to also use this helper.
>
> The #ifdef CONFIG_HUGETLB_PAGE guard is moved inside vmap_set_ptes(),
> so callers no longer need to handle the conditional compilation.
>
> No functional change.
>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 44 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 2c2f74a07f396..6660f240d27c9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -91,6 +91,35 @@ struct vfree_deferred {
> static DEFINE_PER_CPU(struct vfree_deferred, vfree_deferred);
>
> /*** Page table manipulation functions ***/
> +
> +/*
> + * Set PTE mappings for the given PFN. Try CONT_PTE mappings first when
> + * supported, otherwise fall back to PAGE_SIZE mappings.
> + *
> + * Return: mapping size.
> + */
> +static __always_inline unsigned long vmap_set_ptes(pte_t *pte,
> + unsigned long addr, unsigned long end, u64 pfn,
> + pgprot_t prot, unsigned int max_page_shift)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> + if (max_page_shift > PAGE_SHIFT) {
> + unsigned long size;
> +
> + size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> + if (size != PAGE_SIZE) {
> + pte_t entry = pfn_pte(pfn, prot);
> +
> + entry = arch_make_huge_pte(entry, ilog2(size), 0);
> + set_huge_pte_at(&init_mm, addr, pte, entry, size);
> + return size;
> + }
> + }
> +#endif
> + set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> + return PAGE_SIZE;
> +}
> +
> static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> phys_addr_t phys_addr, pgprot_t prot,
> unsigned int max_page_shift, pgtbl_mod_mask *mask)
> @@ -119,19 +148,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> BUG();
> }
>
> -#ifdef CONFIG_HUGETLB_PAGE
> - size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> - if (size != PAGE_SIZE) {
> - pte_t entry = pfn_pte(pfn, prot);
> -
> - entry = arch_make_huge_pte(entry, ilog2(size), 0);
> - set_huge_pte_at(&init_mm, addr, pte, entry, size);
> - pfn += PFN_DOWN(size);
> - continue;
> - }
> -#endif
> - set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> - pfn++;
> + size = vmap_set_ptes(pte, addr, end, pfn, prot, max_page_shift);
> + pfn += PFN_DOWN(size);
> } while (pte += PFN_DOWN(size), addr += size, addr != end);
>
> lazy_mmu_mode_disable();
> --
> 2.34.1
>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Andrew Davis @ 2026-06-26 16:21 UTC (permalink / raw)
To: Nathan Morrisson, nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
In-Reply-To: <20260626161014.1146128-2-nmorrisson@phytec.com>
On 6/26/26 11:10 AM, Nathan Morrisson wrote:
> Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
> corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
> uses the TI AM67x SoC and can come with different sizes and models of
> DDR, eMMC, and SPI NOR Flash.
>
> Supported features:
> * Audio playback and recording
> * CAN
> * Debug UART
> * eMMC
> * Ethernet
> * GPIO buttons
> * Heartbeat LED
> * I2C Current sensor
> * I2C EEPROM
> * I2C Light sensor
> * I2C RTC
> * Micro SD card
> * PCIe
> * SPI NOR flash
> * USB
>
> [1] https://www.phytec.com/product/phycore-am67x/
> [2] https://www.phytec.com/product/phyboard-am67x-development-kit/
>
> Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
> ---
Reviewed-by: Andrew Davis <afd@ti.com>
> Changes in v2:
> * Move k3-j722s.dtsi include from the phyboard to phycore dts
> * Remove cpsw_port2 node because it was already disabled
> * Remove mcasp1 because it is used by HDMI, and HDMI is not included in this dts
> * Fix typo in audio codec properties ai3xx-micbias-vg -> ai31xx-micbias-vg
> * Use IRQ_TYPE_EDGE_FALLING instead of IRQ_TYPE_LEVEL_LOW for gpio expanders
>
> arch/arm64/boot/dts/ti/Makefile | 1 +
> .../boot/dts/ti/k3-am67-phycore-som.dtsi | 325 ++++++++++++
> .../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 478 ++++++++++++++++++
> 3 files changed, 804 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
>
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 371f9a043fe5..623ee2369132 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
> dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
>
> # Boards with J722s SoC
> +dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
> diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> new file mode 100644
> index 000000000000..1bbd6d024c60
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> @@ -0,0 +1,325 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Copyright (C) 2026 PHYTEC America LLC
> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
> + */
> +
> +#include <dt-bindings/net/ti-dp83867.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "k3-j722s.dtsi"
> +
> +/ {
> + compatible = "phytec,am67-phycore-som", "ti,j722s";
> + model = "PHYTEC phyCORE-AM67";
> +
> + aliases {
> + ethernet0 = &cpsw_port1;
> + gpio0 = &main_gpio0;
> + mmc0 = &sdhci0;
> + rtc0 = &i2c_som_rtc;
> + rtc1 = &wkup_rtc0;
> + spi0 = &ospi0;
> + };
> +
> + memory@80000000 {
> + /* 4G RAM */
> + reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> + <0x00000008 0x80000000 0x00000000 0x80000000>;
> + device_type = "memory";
> + bootph-all;
> + };
> +
> + reserved_memory: reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + secure_tfa_ddr: tfa@9e780000 {
> + reg = <0x00 0x9e780000 0x00 0x80000>;
> + no-map;
> + };
> +
> + secure_ddr: optee@9e800000 {
> + reg = <0x00 0x9e800000 0x00 0x01800000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_memory_region: memory@a0100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0100000 0x00 0xf00000>;
> + no-map;
> + };
> + };
> +
> + vcc_5v0_som: regulator-vcc-5v0-som {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_5V0_SOM";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + led-0 {
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + function = LED_FUNCTION_HEARTBEAT;
> + };
> + };
> +};
> +
> +&main_pmx0 {
> + leds_pins_default: leds-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
> + >;
> + };
> +
> + mdio_pins_default: mdio-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
> + J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
> + >;
> + bootph-all;
> + };
> +
> + ospi0_pins_default: ospi0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
> + J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
> + J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
> + J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
> + J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
> + J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
> + J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
> + J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
> + J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
> + J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
> + J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
> + J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
> + >;
> + bootph-all;
> + };
> +
> + pmic_irq_pins_default: pmic-irq-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
> + >;
> + };
> +
> + rgmii1_pins_default: rgmii1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
> + J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
> + J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
> + J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
> + J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
> + J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
> + J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
> + J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
> + J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
> + J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
> + J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
> + J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
> + >;
> + bootph-all;
> + };
> +};
> +
> +&mcu_pmx0 {
> + wkup_i2c0_pins_default: wkup-i2c0-default-pins {
> + pinctrl-single,pins = <
> + J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
> + J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
> + >;
> + bootph-all;
> + };
> +};
> +
> +&cpsw3g {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii1_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&cpsw3g_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins_default>;
> + status = "okay";
> +
> + cpsw3g_phy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> + tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,min-output-impedance;
> + };
> +};
> +
> +&cpsw_port1 {
> + phy-mode = "rgmii-id";
> + phy-handle = <&cpsw3g_phy1>;
> + status = "okay";
> +};
> +
> +&ospi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ospi0_pins_default>;
> + bootph-all;
> + status = "okay";
> +
> + serial_flash: flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-tx-bus-width = <8>;
> + spi-rx-bus-width = <8>;
> + spi-max-frequency = <25000000>;
> + vcc-supply = <&vdd_1v8>;
> + cdns,tshsl-ns = <60>;
> + cdns,tsd2d-ns = <60>;
> + cdns,tchsh-ns = <60>;
> + cdns,tslch-ns = <60>;
> + cdns,read-delay = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + non-removable;
> + bootph-all;
> + ti,driver-strength-ohm = <50>;
> + status = "okay";
> +};
> +
> +&wkup_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&wkup_i2c0_pins_default>;
> + clock-frequency = <400000>;
> + bootph-all;
> + status = "okay";
> +
> + pmic@30 {
> + compatible = "ti,tps65219";
> + reg = <0x30>;
> + buck1-supply = <&vcc_5v0_som>;
> + buck2-supply = <&vcc_5v0_som>;
> + buck3-supply = <&vcc_5v0_som>;
> + ldo1-supply = <&vdd_3v3>;
> + ldo2-supply = <&vdd_1v8>;
> + ldo3-supply = <&vdd_3v3>;
> + ldo4-supply = <&vdd_3v3>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_irq_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + system-power-controller;
> + ti,power-button;
> +
> + regulators {
> + vdd_3v3: buck1 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v8: buck2 {
> + regulator-name = "VDD_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_lpddr4: buck3 {
> + regulator-name = "VDD_LPDDR4";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vddshv_sdio: ldo1 {
> + regulator-name = "VDDSHV_SDIO";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-allow-bypass;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v2: ldo2 {
> + regulator-name = "VDD_1V2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdda_1v8_phy: ldo3 {
> + regulator-name = "VDDA_1V8_PHY";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v8_pll: ldo4 {
> + regulator-name = "VDD_1V8_PLL";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + vdd_core: regulator-vdd-core@44 {
> + compatible = "ti,tps62873";
> + reg = <0x44>;
> + bootph-pre-ram;
> + regulator-name = "VDD_CORE";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <850000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + pagesize = <32>;
> + };
> +
> + som_eeprom_opt: eeprom@51 {
> + compatible = "atmel,24c32";
> + reg = <0x51>;
> + pagesize = <32>;
> + };
> +
> + i2c_som_rtc: rtc@52 {
> + compatible = "microcrystal,rv3028";
> + reg = <0x52>;
> + };
> +};
> +
> +#include "k3-j722s-ti-ipc-firmware.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> new file mode 100644
> index 000000000000..e6e74910e0bb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> @@ -0,0 +1,478 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Copyright (C) 2026 PHYTEC America LLC
> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "k3-serdes.h"
> +#include "k3-am67-phycore-som.dtsi"
> +
> +/ {
> + compatible = "phytec,am6754-phyboard-rigel",
> + "phytec,am67-phycore-som", "ti,j722s";
> + model = "PHYTEC phyBOARD-Rigel AM67";
> +
> + aliases {
> + gpio1 = &main_gpio1;
> + mmc1 = &sdhci1;
> + serial2 = &main_uart0;
> + usb0 = &usb0;
> + usb1 = &usb1;
> + };
> +
> + can_tc0: can-phy0 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <8000000>;
> + standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + usb0_connector: connector {
> + compatible = "gpio-usb-b-connector", "usb-b-connector";
> + label = "USB-C";
> + data-role = "dual";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_usbc_power_pins_default>;
> +
> + id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + usb0_con: endpoint {
> + remote-endpoint = <&usb0_ep>;
> + };
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_keys_pins_default>;
> +
> + key-home {
> + label = "home";
> + linux,code = <KEY_HOME>;
> + gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
> + };
> +
> + key-menu {
> + label = "menu";
> + linux,code = <KEY_MENU>;
> + gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + pcie_refclk0: pcie-refclk0 {
> + compatible = "gpio-gate-clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_pcie_usb_sel_pins_default>;
> + clocks = <&serdes_refclk>;
> + #clock-cells = <0>;
> + enable-gpios = <&main_gpio0 22 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_1v8: regulator-vcc-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_aud: regulator-vcc-3v3-aud {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_AUD";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_mmc: regulator-vcc-3v3-mmc {
> + /* TPS22963C OUTPUT */
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_MMC";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_sw: regulator-vcc-3v3-sw {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_SW";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_speaker: regulator-vcc-speaker {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_SPEAKER";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,widgets =
> + "Microphone", "Mic Jack",
> + "Headphone", "Headphone Jack",
> + "Line", "Stereo Jack",
> + "Speaker", "L SPKR",
> + "Speaker", "R SPKR";
> + simple-audio-card,routing =
> + "MIC1RP", "Mic Jack",
> + "Mic Jack", "MICBIAS",
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "MIC1LM", "Stereo Jack",
> + "MIC1LP", "Stereo Jack",
> + "SPL", "L SPKR",
> + "SPR", "R SPKR";
> + simple-audio-card,name = "phyBOARD-Rigel";
> + simple-audio-card,format = "dsp_b";
> + simple-audio-card,bitclock-master = <&sound_master>;
> + simple-audio-card,frame-master = <&sound_master>;
> + simple-audio-card,bitclock-inversion;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&mcasp0>;
> + };
> +
> + sound_master: simple-audio-card,codec {
> + sound-dai = <&audio_codec>;
> + clocks = <&audio_refclk1>;
> + };
> + };
> +};
> +
> +&main_pmx0 {
> + audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
> + >;
> + };
> +
> + gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
> + >;
> + };
> +
> + gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
> + >;
> + };
> +
> + gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
> + >;
> + };
> +
> + gpio_keys_pins_default: gpio-keys-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
> + >;
> + };
> +
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
> + J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
> + >;
> + bootph-all;
> + };
> +
> + main_i2c1_pins_default: main-i2c1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
> + J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
> + >;
> + bootph-all;
> + };
> +
> + main_mcan0_pins_default: main-mcan0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
> + J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
> + >;
> + };
> +
> + main_mcasp0_pins_default: main-mcasp0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
> + J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
> + J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
> + J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
> + >;
> + };
> +
> + main_mmc1_pins_default: main-mmc1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
> + J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
> + J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
> + J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
> + J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
> + J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
> + J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
> + >;
> + bootph-all;
> + };
> +
> + main_pcie_pins_default: main-pcie-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x07c, PIN_INPUT, 7) /* (T23) GPMC0_CLK.GPIO0_31 */
> + >;
> + };
> +
> + main_pcie_usb_sel_pins_default: main-pcie-usb-sel-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x058, PIN_INPUT, 7) /* (T22) GPMC0_AD7.GPIO0_22 */
> + >;
> + };
> +
> + main_uart0_pins_default: main-uart0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
> + J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
> + >;
> + bootph-all;
> + };
> +
> + main_usbc_power_pins_default: main-usbc-power-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
> + >;
> + };
> +};
> +
> +&audio_refclk1 {
> + assigned-clock-rates = <25000000>;
> +};
> +
> +&main_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c0_pins_default>;
> + clock-frequency = <400000>;
> + status = "okay";
> +
> + veml6030: light-sensor@10 {
> + compatible = "vishay,veml6030";
> + reg = <0x10>;
> + vdd-supply = <&vcc_3v3_sw>;
> + };
> +};
> +
> +&main_i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c1_pins_default>;
> + clock-frequency = <100000>;
> + status = "okay";
> +
> + audio_codec: audio-codec@18 {
> + compatible = "ti,tlv320aic3110";
> + reg = <0x18>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&audio_ext_refclk1_pins_default>;
> + #sound-dai-cells = <0>;
> + ai31xx-micbias-vg = <2>;
> + reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
> +
> + HPVDD-supply = <&vcc_3v3_aud>;
> + SPRVDD-supply = <&vcc_speaker>;
> + SPLVDD-supply = <&vcc_speaker>;
> + AVDD-supply = <&vcc_3v3_aud>;
> + IOVDD-supply = <&vcc_3v3_aud>;
> + DVDD-supply = <&vcc_1v8>;
> + };
> +
> + gpio_exp0: gpio@20 {
> + compatible = "nxp,pcf8574";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp0_int_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
> + "CSI3_SHUTTER", "CSI3_OE",
> + "CSI2_STROBE", "CSI2_TRIGGER",
> + "CSI2_SHUTTER", "CSI2_OE";
> + };
> +
> + gpio_exp1: gpio@21 {
> + compatible = "nxp,pcf8574";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp1_int_pins_default>;
> + interrupt-parent = <&main_gpio1>;
> + interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
> + "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
> + "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
> + "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
> + };
> +
> + gpio_exp2: gpio@23 {
> + compatible = "nxp,pcf8574";
> + reg = <0x23>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp2_int_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
> + "CSI1_SHUTTER", "CSI1_OE",
> + "CSI0_STROBE", "CSI0_TRIGGER",
> + "CSI0_SHUTTER", "CSI0_OE";
> + };
> +
> + current-sensor@40 {
> + compatible = "ti,ina233";
> + reg = <0x40>;
> + shunt-resistor = <18000>;
> + };
> +
> + eeprom@51 {
> + compatible = "atmel,24c02";
> + reg = <0x51>;
> + pagesize = <16>;
> + };
> +};
> +
> +&main_mcan0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan0_pins_default>;
> + phys = <&can_tc0>;
> + status = "okay";
> +};
> +
> +&main_uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_uart0_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&mcasp0 {
> + #sound-dai-cells = <0>;
> + op-mode = <0>; /* MCASP_IIS_MODE */
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcasp0_pins_default>;
> + tdm-slots = <2>;
> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
> + 0 0 1 2
> + 0 0 0 0
> + 0 0 0 0
> + 0 0 0 0
> + >;
> + status = "okay";
> +};
> +
> +&pcie0_rc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_pcie_pins_default>;
> + num-lanes = <1>;
> + phys = <&serdes1_pcie_link>;
> + phy-names = "pcie-phy";
> + reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&sdhci1 {
> + /* SD/MMC */
> + vmmc-supply = <&vcc_3v3_mmc>;
> + vqmmc-supply = <&vddshv_sdio>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mmc1_pins_default>;
> + disable-wp;
> + no-1-8-v;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&serdes_ln_ctrl {
> + idle-states = <J722S_SERDES0_LANE0_USB>,
> + <J722S_SERDES1_LANE0_PCIE0_LANE0>;
> +};
> +
> +&serdes0 {
> + status = "okay";
> +
> + serdes0_usb_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_USB3>;
> + resets = <&serdes_wiz0 1>;
> + };
> +};
> +
> +&serdes_wiz0 {
> + status = "okay";
> +};
> +
> +&serdes1 {
> + status = "okay";
> +
> + serdes1_pcie_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_PCIE>;
> + resets = <&serdes_wiz1 1>;
> + };
> +};
> +
> +&serdes_wiz1 {
> + clocks = <&k3_clks 280 0>, <&k3_clks 280 1>, <&pcie_refclk0>;
> + status = "okay";
> +};
> +
> +&usbss0 {
> + ti,vbus-divider;
> + status = "okay";
> +};
> +
> +&usb0 {
> + dr_mode = "otg";
> + usb-role-switch;
> + maximum-speed = "high-speed";
> +
> + port {
> + usb0_ep: endpoint {
> + remote-endpoint = <&usb0_con>;
> + };
> + };
> +};
> +
> +&usbss1 {
> + ti,vbus-divider;
> + status = "okay";
> +};
> +
> +&usb1 {
> + dr_mode = "host";
> + phys = <&serdes0_usb_link>;
> + phy-names = "cdns3,usb3-phy";
> + maximum-speed = "super-speed";
> +};
^ permalink raw reply
* Re: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-06-26 16:20 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260618084726.1070022-7-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:26PM +0800, 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)
> +{
> + 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 */
> + if (size >= PMD_SIZE) {
> + vm_area = __get_vm_area_node_aligned_caller(size, PMD_SIZE,
> + flags, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Try CONT_PTE alignment */
> + 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 */
> + 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));
> if (!area)
> return NULL;
>
> --
> 2.34.1
>
Did intensive random mapping/unmaping, so i have not noticed any issues.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v2 05/11] iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event
From: Robin Murphy @ 2026-06-26 16:15 UTC (permalink / raw)
To: Nicolin Chen, will, jgg
Cc: joro, bhelgaas, praan, kevin.tian, kees, smostafa, baolu.lu,
linux-arm-kernel, iommu, linux-kernel, linux-pci, skaestle,
mmarrid, skolothumtho, bbiber
In-Reply-To: <6c713c724fa09bf5a1b5e2247c633e516036f079.1779944354.git.nicolinc@nvidia.com>
On 28/05/2026 8:59 am, Nicolin Chen wrote:
> From: Malak Marrid <mmarrid@nvidia.com>
>
> To handle IOMMU_FAULT_PAGE_REQ from the PRI queue, arm_smmu_page_response()
> must issue a CMDQ_OP_PRI_RESP back to the SMMU.
>
> However, either a stall event in the EVTQ or a PRI request in the PRIQ can
> surface to the IOPF infrastructure with fault.type == IOMMU_FAULT_PAGE_REQ,
> and a single master can in principle be both stall-capable and PRI-capable
No, the SMMU architecture does all it can to specifically forbid this,
see 3.12.1 and 16.4, it just can't be made architecturally ILLEGAL to
enable stalls for PCIe devices because there's no strict architectural
definition for what "a PCIe device" actually is. Similarly with the note
in the definition of STE.EATS about the relationship with CD.S - the
unwritten implication is that defining specific behaviours would only
create an unreasonable burden for hardware validation, for the sake of
something that nobody in their right mind should ever do anyway.
The expectation is that RCiEPs which do speak stallable non-PCIe bus
protocols will not go to the effort of implementing ATS/PRI capabilities
(not least because there's every chance that such protocols simply
doesn't have that kind of transaction flow anyway). And conversely that
it can be considered an egregious firmware (or system design) error to
even claim (let alone force) stall capability for a real PCIe root port
which may be deadlocked by blocking its requirement for free-flowing
writes. Thus I think we could go so far as to refuse to handle any
endpoint which did somehow claim both.
Thanks,
Robin.
> (e.g. FEAT_STALL_FORCE on a PCIe device with PRI), so master state is not a
> reliable discriminator.
>
> Add IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS to the generic flags so the fault
> reporter can mark a page request that is holding the device's transaction:
> arm_smmu_handle_event() sets it on STALL events
> arm_smmu_handle_ppr() leaves it clear for PRI events
>
> Note: streams[0].id remains the RID because arm_smmu_enable_iopf() rejects
> num_streams != 1.
>
> Co-developed-by: Barak Biber <bbiber@nvidia.com>
> Signed-off-by: Barak Biber <bbiber@nvidia.com>
> Co-developed-by: Stefan Kaestle <skaestle@nvidia.com>
> Signed-off-by: Stefan Kaestle <skaestle@nvidia.com>
> Signed-off-by: Malak Marrid <mmarrid@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> include/linux/iommu.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 +++++++++++++++------
> 3 files changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 2bb810e4d5fce..1083621705f16 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -1007,6 +1007,7 @@ struct arm_smmu_master {
> /* Locked by the iommu core using the group mutex */
> struct arm_smmu_ctx_desc_cfg cd_table;
> unsigned int num_streams;
> + bool pri_enabled : 1;
> bool ats_enabled : 1;
> bool ste_ats_enabled : 1;
> bool stall_enabled;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e587d4ac4d331..83c4dfcf20637 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -76,6 +76,7 @@ struct iommu_fault_page_request {
> #define IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (1 << 0)
> #define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1)
> #define IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID (1 << 2)
> +#define IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS (1 << 3)
> u32 flags;
> u32 pasid;
> u32 grpid;
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index ffc9621cd2288..061f1d46fda0d 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -921,32 +921,68 @@ static int arm_smmu_drain_queue_for_iopf(struct arm_smmu_device *smmu,
> return ret;
> }
>
> -static void arm_smmu_page_response(struct device *dev, struct iopf_fault *unused,
> +static void arm_smmu_page_response(struct device *dev, struct iopf_fault *evt,
> struct iommu_page_response *resp)
> {
> struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> - u8 resume_resp;
> + struct arm_smmu_cmd cmd;
> + int sid;
>
> - if (WARN_ON(!master->stall_enabled))
> + if (WARN_ON_ONCE(evt->fault.type != IOMMU_FAULT_PAGE_REQ))
> return;
>
> - switch (resp->code) {
> - case IOMMU_PAGE_RESP_INVALID:
> - case IOMMU_PAGE_RESP_FAILURE:
> - resume_resp = CMDQ_RESUME_0_RESP_ABORT;
> - break;
> - case IOMMU_PAGE_RESP_SUCCESS:
> - resume_resp = CMDQ_RESUME_0_RESP_RETRY;
> - break;
> - default:
> - resume_resp = CMDQ_RESUME_0_RESP_TERM;
> - break;
> + /* IOPF is gated to num_streams == 1 in arm_smmu_enable_iopf() */
> + sid = master->streams[0].id;
> +
> + if (evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS) {
> + u8 resume_resp;
> +
> + if (WARN_ON_ONCE(!master->stall_enabled))
> + return;
> + switch (resp->code) {
> + case IOMMU_PAGE_RESP_INVALID:
> + case IOMMU_PAGE_RESP_FAILURE:
> + resume_resp = CMDQ_RESUME_0_RESP_ABORT;
> + break;
> + case IOMMU_PAGE_RESP_SUCCESS:
> + resume_resp = CMDQ_RESUME_0_RESP_RETRY;
> + break;
> + default:
> + resume_resp = CMDQ_RESUME_0_RESP_TERM;
> + break;
> + }
> + cmd = arm_smmu_make_cmd_resume(sid, resp->grpid, resume_resp);
> + } else {
> + enum pri_resp pri_resp;
> + bool ssv;
> +
> + if (WARN_ON_ONCE(!master->pri_enabled))
> + return;
> + /* PCIe allows only one PRG Response per group */
> + if (!(evt->fault.prm.flags &
> + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> + return;
> + switch (resp->code) {
> + case IOMMU_PAGE_RESP_SUCCESS:
> + pri_resp = PRI_RESP_SUCC;
> + break;
> + case IOMMU_PAGE_RESP_FAILURE:
> + pri_resp = PRI_RESP_FAIL;
> + break;
> + case IOMMU_PAGE_RESP_INVALID:
> + pri_resp = PRI_RESP_DENY;
> + break;
> + default:
> + WARN_ON(true);
> + return;
> + }
> + ssv = !!(evt->fault.prm.flags &
> + IOMMU_FAULT_PAGE_REQUEST_PASID_VALID);
> + cmd = arm_smmu_make_cmd_pri_resp(sid, resp->pasid, ssv,
> + resp->grpid, pri_resp);
> }
>
> - arm_smmu_cmdq_issue_cmd(master->smmu,
> - arm_smmu_make_cmd_resume(master->streams[0].id,
> - resp->grpid,
> - resume_resp));
> + arm_smmu_cmdq_issue_cmd(master->smmu, cmd);
> /*
> * Don't send a SYNC, it doesn't do anything for RESUME or PRI_RESP.
> * RESUME consumption guarantees that the stalled transaction will be
> @@ -2081,7 +2117,8 @@ static int arm_smmu_handle_event(struct arm_smmu_device *smmu, u64 *evt,
>
> flt->type = IOMMU_FAULT_PAGE_REQ;
> flt->prm = (struct iommu_fault_page_request){
> - .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> + .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE |
> + IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS,
> .grpid = event->stag,
> .perm = perm,
> .addr = event->iova,
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
From: Nathan Morrisson @ 2026-06-26 16:10 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
Add device tree bindings for the AM67x based phyCORE-AM67x SoM and
phyBOARD-Rigel.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
* Use spaces instead of tabs for indentation
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 69b5441cbf1a..ae47190d1f82 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -222,6 +222,13 @@ properties:
- ti,j722s-evm
- const: ti,j722s
+ - description: K3 AM67 SoC PHYTEC phyBOARD-Rigel
+ items:
+ - enum:
+ - phytec,am6754-phyboard-rigel
+ - const: phytec,am67-phycore-som
+ - const: ti,j722s
+
- description: K3 J742S2 SoC
items:
- enum:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
From: David Hildenbrand (Arm) @ 2026-06-26 16:09 UTC (permalink / raw)
To: Anshuman Khandual, linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, linux-kernel,
Ben Hutchings
In-Reply-To: <20260626012845.475959-1-anshuman.khandual@arm.com>
On 6/26/26 03:28, Anshuman Khandual wrote:
> flush_tlb_kernel_range() could flush down an entire block mapping just with
> a single PAGE_SIZE stride. This capability was being used umapping PMD and
> PUD based block mappings in unmap_hotplug_[pmd|pud]_range().
>
> But later on the commit 48478b9f7913
> ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()") replaced
> this PAGE_SIZE stride with [PMD|PUD]_SIZE strides, hence forcing multiple
> PAGE_SIZE stride based TLB flushes on platforms where TLB range operation
> is not supported. Revert back to the earlier TLB behaviour along with the
> required comments that were dropped earlier.
>
Right, it looked like the right thing to do in that commit. I wonder if we can
make the comments even clearer to prevent his happening another time,
incorporating the HW consideration.
In any case
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Ben Hutchings <ben@decadent.org.uk>
> Closes: https://lore.kernel.org/all/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/
> Fixes: 48478b9f7913 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/mm/mmu.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 8242f93f05e4..5ff0041f4a5f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1509,7 +1509,11 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
> if (free_mapped) {
> /* CONT blocks are not supported in the vmemmap */
> WARN_ON(pmd_cont(pmd));
> - flush_tlb_kernel_range(addr, addr + PMD_SIZE);
> + /*
> + * One TLBI should be sufficient here as the PMD_SIZE
> + * range is mapped with a single block entry.
> + */
"Flush only a single page, resulting in a single TLBi for this large block
mapping, avoiding multiple TLBIs on HW without TLB range flushes."
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] arm64: mm: refresh stale pmd snapshot after split_contpmd()
From: David Hildenbrand (Arm) @ 2026-06-26 16:03 UTC (permalink / raw)
To: Dev Jain, lirongqing, Catalin Marinas, Will Deacon, Ryan Roberts,
Ard Biesheuvel, Anshuman Khandual, Kevin Brodsky, Yang Shi,
Chaitanya S Prakash, linux-arm-kernel, linux-kernel
In-Reply-To: <e0031cbe-2a49-4611-ad48-bde73fe4cd1c@arm.com>
On 6/26/26 15:03, Dev Jain wrote:
>
>
> On 25/06/26 5:09 pm, lirongqing wrote:
>> From: Li RongQing <lirongqing@baidu.com>
>>
>> split_contpmd() modifies the pmd entries in-place by clearing the CONT
>> bit, but the local 'pmd' variable still holds the old snapshot with CONT
>> set. The subsequent split_pmd() call uses this stale value to derive the
>> pgprot for the new PTE entries via pmd_pgprot(), causing the resulting
>> PTEs to be populated with incorrect protection bits.
>
> Since the block was CONTPMD, it means the pgprot was uniform on that block,
> so after splitting, it should be safe to derive the pgprot from individual pmd's
> right?
I'm also confused by that, can we get some details why (and how) the cont bit
misguides pmd_pgprot?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Conor Dooley @ 2026-06-26 15:57 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20260626-rpi-tryboot-v1-2-490b1c4c4970@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
On Fri, Jun 26, 2026 at 09:35:05AM +0200, Gregor Herburger wrote:
> The Raspberry Pi firmware allows to set a reboot mode called tryboot
> that allows to try booting from a different partition to allow updating
> of the boot partition. Allow reboot mode properties by referencing the
> reboot-mode schema.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec97..30b490e0d9fb3 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -133,11 +133,14 @@ properties:
> required:
> - compatible
>
> +allOf:
> + - $ref: /schemas/power/reset/reboot-mode.yaml#
> +
> required:
> - compatible
> - mboxes
>
> -additionalProperties: false
> +unevaluatedProperties: false
I think you should keep additionalProperties: false and add
mode-normal: true
mode-tryboot: true
(I don't know if the latter works though, you may need to have a $ref to
uint32-array).
What you've done permits freeform reboot modes, but I think only normal
and tryboot are valid?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 15:49 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <c1ac3ab4-f214-4947-b42f-cbc635be6bbb@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
[...]
> I have another proposal: what if we allocate the ATID in trace_noc_id() when
> the device does not already have a valid ATID?
>
> Possible scenarios:
>
> If the itnoc device is connected to a TPDM device (which has no ATID),
> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
> valid ATID can be allocated for the path.
>
> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
> will never be invoked, and therefore no ATID will be allocated for the
> device, saving resources.
TBH, I'm not sure I can make a judgement here, as I don't have enough
knowledge of the topology. And I'm not sure whether the listed
connections cover all possible cases.
I also found commit 5799dee92dc2:
| This patch adds platform driver support for the CoreSight Interconnect
| TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
| from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
| it does not have aggregation and ATID functionality.
With your proposal, wouldn't ATID be allocated for the interconnect
TNOC while being skipped for the Aggregator TNOC? That seems to
contradict the commit log.
Thanks,
Leo
^ permalink raw reply
* Re: [GIT PULL] arm64 fixes for -rc1
From: pr-tracker-bot @ 2026-06-26 15:45 UTC (permalink / raw)
To: Will Deacon
Cc: torvalds, catalin.marinas, linux-arm-kernel, linux-kernel,
kernel-team
In-Reply-To: <aj5bfQ9E7Qjeeo1d@willie-the-truck>
The pull request you sent on Fri, 26 Jun 2026 11:59:09 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e7c93451eeb06b67b4eb23017824b3dee90b360e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:32 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Fri, Jun 26, 2026 at 05:33:26PM +0800, Icenowy Zheng wrote:
> > > >
> > > > > > > +
> > > > > > > + resets:
> > > > > > > + minItems: 1
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + reset-names:
> > > > > > > + items:
> > > > > > > + - const: core
> > > > > >
> > > > > > This is just maxItems: 1.
> > > > >
> > > > > Well the implicit rules of DT binding schemas are quite
> > > > > weird...
> > > >
> > > > I don't think it is that strange, as the binding has
> > > > reset-names:
> > > > items:
> > > > - const: core
> > > > - const: axi
> > > > - const: ahb
> > >
> > > Ah does the list constraint the order of items? If it constrains
> > > the
> >
> > It does, yes.
> > Alternatively, using an enum permits free ordering.
>
> Ah in this case this should be converted to an enum, I think.
>
> Should I send a patch for converting it?
Why do you think it should be an enum? We don't currently have any users
of this that only provide no core or no axi reset.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:16 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <996c3d442e92e7f908fb3a32973805dd2d2680d7.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 4813 bytes --]
On Fri, Jun 26, 2026 at 05:09:12PM +0800, Icenowy Zheng wrote:
> 在 2026-06-26五的 09:57 +0100，Conor Dooley写道：
> > On Fri, Jun 26, 2026 at 03:58:14PM +0800, Icenowy Zheng wrote:
> > > 在 2026-06-26五的 08:22 +0100，Conor Dooley写道：
> > > > On Thu, Jun 25, 2026 at 05:33:37PM +0100, Conor Dooley wrote:
> > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > > +
> > > > > > + - if:
> > > > > > + properties:
> > > > > > + compatible:
> > > > > > + contains:
> > > > > > + const: nuvoton,ma35d1-dcu
> > > > > > + then:
> > > > > > + properties:
> > > > > > + clocks:
> > > > > > + minItems: 2
> > > > >
> > > > > Anything that updates the minimum constraint should be done at
> > > > > the
> > > > > top
> > > > > level of this schema. The conditional section should then
> > > > > tighten
> > > > > the
> > > > > constraint, in this case that means only having maxItems.
> > > > >
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: core
> > > > > > + - const: pix0
> > > > >
> > > > > Does this even work when the top level schema thinks clock 2
> > > > > should
> > > > > be
> > > > > called axi?
> > > >
> > > > Additionally here, only have core and pix0 seems like it might be
> > > > an
> > > > oversimplification. I doubt removing the second output port means
> > > > that
> > > > the axi and ahb clocks are no longer needed.
> > > > Is it the case that your device supplies the same clock to core,
> > > > ahb
> > > > and
> > > > axi? If so, then you should fill those clocks in in your
> > > > devicetree
> > > > and
> > > > this can just constrain the number of clocks/clock-names to 4.
> > >
> > > The clock controller of that SoC is quite weird -- it has only a
> > > single
> > > gate bit, but controlling 3 clock gates. All core, ahb and axi
> > > clocks
> > > have gates controlled by this single bit, so it's why currently
> > > it's
> > > modelled as only core clock supplied.
> >
> > Yeah, then what's in the binding is definitely wrong.
> > Even if the same clock was provided to all clock inputs in the IP,
> > all
> > individual clock should be listed in the devicetree - although it
> > will
> > look a little silly to see clocks = <&foo 2>, <&foo 2>, <&foo 2>,
> > <&foo 2>;
> > In this case, 3 clocks controlled by 1 gate bit is an implementation
> > detail
> > of the SoC's clocking hardware, and not relevant to how the dc
> > instance
> > should be described.
> >
> > > Well it might be worthful to supply the bus clock before the gate
> > > as
> > > ahb/axi, especially axi, because both the AXI clock and the core
> > > clock
> > > constraints the maximum pixel clock.
> >
> > Right. And looking at patch 4/7, and the wording:
> > > The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
> > > whose
> > > AXI and AHB bus clocks share a single gate enable bit with the
> > > display
> > > core clock, so the clock driver does not expose them separately.
> > > This
> > > patch makes the axi and ahb clocks optional in the probe.
> >
> > It sounds like there's probably some issues with how things are
> > modelled
> > clock wise in this device, unless this is not an accurate statement
> > and
> > there's actually one clock provided to all three inputs. If they're
> > distinct clocks, with different rates, only having one exposed has a
> > lot
> > of potential to be problematic!
>
> Yes, I agree with this, they're different clocks according to the
> manual.
>
> I added the clk people to the CC list in a reply of the previous
> revision, but they didn't react yet. I don't know how to represent
> multiple clock gates sharing a single control bit in the clock
> framework...
Yeah, I have absolutely no idea. Maybe it requires custom refcounting?
Surely this cannot be the only device that does something like this
though.
> Maybe just supplying the ungated AXI/AHB clocks here, and let the core
> clock manage the gate?
I guess, but that seems incorrect and would require commentary about why
it's being done. Feel like they (the missing axi/ahb clocks) should be
added to the clock driver and binding, and any special workarounds done
there.
Of course letting the core clock manage the gate and making the enable
method for the gated AXI/AHB clocks be a NOP is one way of handling it
in the clock driver. Still a bit of a hack compared to refcounting it,
but it makes me happier to have the correct clock tree modelled in DT.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Leo Yan @ 2026-06-26 15:12 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang,
Suzuki K Poulose, Mike Leach, James Clark, Tamas.Petz,
Michiel.VanTol
In-Reply-To: <20260618084726.1070022-1-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:20PM +0800, Wen Jiang wrote:
> Besides accelerating the mapping path, this also enables large
> mappings (PMD and cont-PTE) for vmap, which are currently not
> supported.
I verified this series with large vmap() mappings for Arm trace buffer
units (TRBE and SPE), and the results are positive.
Arm trace buffer units use the CPU's page tables for address translation
when writing trace data to DRAM. The larger vmap() mapping granules
reduce TLB pressure, resulting in significantly fewer L2D TLB refills
and reduced L1D TLB refills. The decrease in dtlb_walk indicates that
fewer page table walks are required and that address translations are
more often satisfied by cached TLB entries.
The detailed results are included below for reference.
Thanks for working on this, and here is my test tag:
Tested-by: Leo Yan <leo.yan@arm.com>
P.s. I applied a local change to set PERF_PMU_CAP_AUX_PREFER_LARGE in
the CoreSight and SPE drivers to allocate large memory chunks. This
change will be sent out once the MM changes are agreed.
## Results with TRBE
Test command:
taskset -c 2 perf stat -C 10 -e cycles:u,instructions:u,dtlb_walk:u,l1d_tlb:u,l1d_tlb_refill:u,l2d_tlb_refill:u \
-- taskset -c 2 perf record -C 10 -m ,1G -e cs_etm// \
-- taskset -c 10 ./sparse_branch_delay.elf
The benchmark was run 5 times. CPU10 was isolated and dedicated to
running the workload while collecting the TLB statistics.
Before this series:
+----------------+--------+--------+--------+--------+--------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. |
+----------------+--------+--------+--------+--------+--------+----------+
| dtlb_walk | 63 | 75 | 62 | 73 | 69 | 68.4 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb | 2093 | 2189 | 2237 | 2036 | 2086 | 2128.2 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb_refill | 154 | 153 | 150 | 165 | 157 | 155.8 |
+----------------+--------+--------+--------+--------+--------+----------+
| l2d_tlb_refill | 161325 | 161403 | 161432 | 161580 | 161439 | 161435.8 |
+----------------+--------+--------+--------+--------+--------+----------+
After this series:
+----------------+--------+--------+--------+--------+--------+----------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. | Diff. |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| dtlb_walk | 67 | 59 | 60 | 58 | 53 | 59.4 | -13.16% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb | 6710 | 7120 | 6662 | 6626 | 6542 | 6732.0 | +216.32% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb_refill | 126 | 117 | 119 | 117 | 119 | 119.6 | -23.23% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l2d_tlb_refill | 506 | 489 | 485 | 506 | 489 | 495.0 | -99.69% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
## Results with SPE
Test command:
taskset -c 2 perf stat -C 10 -e cycles:u,instructions:u,dtlb_walk:u,l1d_tlb:u,l1d_tlb_refill:u,l2d_tlb_refill:u \
-- taskset -c 2 perf record -C 10 -m ,512M -e arm_spe_0/ts_enable=1,pa_enable=1,period=64,min_latency=0/ \
-- taskset -c 10 dd if=/dev/zero of=/dev/shm/dd_mem_test bs=1M count=1024 status=progress
The benchmark was run five times. CPU10 was isolated and dedicated to
running the workload while collecting the TLB statistics.
Before this series:
+----------------+--------+--------+--------+--------+--------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. |
+----------------+--------+--------+--------+--------+--------+----------+
| dtlb_walk | 2090 | 1709 | 1679 | 1519 | 1555 | 1710.4 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb | 254450 | 257227 | 252517 | 252535 | 254752 | 254296.2 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb_refill | 16023 | 16088 | 15944 | 15989 | 15956 | 16000.0 |
+----------------+--------+--------+--------+--------+--------+----------+
| l2d_tlb_refill | 5887 | 4204 | 3713 | 4556 | 5620 | 4796.0 |
+----------------+--------+--------+--------+--------+--------+----------+
After this series:
+----------------+--------+--------+--------+--------+--------+----------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. | Diff. |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| dtlb_walk | 1111 | 1301 | 1229 | 1166 | 1771 | 1315.6 | -23.08% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb | 257462 | 257420 | 257241 | 259968 | 261324 | 258683.0 | +1.73% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb_refill | 15954 | 15919 | 15948 | 15962 | 15968 | 15950.2 | -0.31% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l2d_tlb_refill | 2672 | 2558 | 2801 | 2478 | 4147 | 2931.2 | -38.88% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
^ permalink raw reply
* RE: [PATCH v2 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms
From: Michael Kelley @ 2026-06-26 15:04 UTC (permalink / raw)
To: Kameron Carr, Michael Kelley, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
In-Reply-To: <000801dd055c$2e375050$8aa5f0f0$@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Friday, June 26, 2026 4:09 AM
>
> On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:
> > From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Thursday,
> > June 25, 2026 10:35 AM
> > > We need to round up the memory allocated for the input/output pages to
> > > the nearest PAGE_SIZE, since set_memory_decrypted() requires the size to
> > > be a multiple of PAGE_SIZE. This only has an effect on ARM VMs that are
> > > using PAGE_SIZE larger than 4K.
> >
> > I think this change resulted from a Sashiko comment. My understanding is
> > that the ARM CCA architecture only supports CCA guests with 4 KiB page
> > size. Is that still the case, or has that restriction been lifted in a later version
> > of the architecture? I'm in favor of handling the larger page sizes, if only for
> > future proofing. But I wondered whether your intent is to always support
> > > 4 KiB page sizes even if CCA doesn't support them now. Another way to
> > put it: In reviewing code, should I flag issues related to page sizes > 4 KiB?
>
> I think you might be right. I'm looking at RMM spec 2.0 beta 2, and the RMI
> can have granule size 4KB, 16KB, 64KB, but the RSI is restricted to granule size
> 4KB.
>
> I'm open to suggestion on best way to move forward.
The best approach probably depends on whether the 4 KiB restriction is
likely to be lifted in a future version of the CCA architecture, and I don't have
any insight into that.
If it is likely to be lifted, then doing the initial implementation to support
larger page sizes probably makes sense (which is what you've done here).
It's less work than going back and adding later. But the commit message
and/or code comments should indicate that the larger page size support
is future-proofing work, so that someone doesn't get the wrong idea that
it should work with larger page sizes now.
The alternate approach is to not do any larger page size support now,
and to explicitly state that the code is assuming the current restriction
of 4 KiB page size only.
Whichever approach is chosen should be used consistently so there's
not a mishmash.
>
> > > @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
> > > }
> > >
> > > if (!ms_hyperv.paravisor_present &&
> > > - (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
> > > - ret = set_memory_decrypted((unsigned long)mem, pgcount);
> > > + (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
> > > + hv_isolation_type_cca())) {
> > > + ret = set_memory_decrypted((unsigned long)kasan_reset_tag(mem),
> > > + alloc_size >> PAGE_SHIFT);
> >
> > I don't know enough about KASAN or the tag situation on ARM64
> > to comment on this change. But this same sequence of allocating
> > memory and then decrypting it occurs in other places in Hyper-V
> > code. It seems like those places would also need the same
> > kasan_reset_tag() call.
>
> I'm not sure of the exact behavior of PAGE_END when there are
> KASAN tags, but it looks like tags could mess with the address
> comparison.
>
> I do see that __virt_to_phys_nodebug() and virt_addr_valid() in
> arch/arm64/include/asm/memory.h both reset tags before calling
> __is_lm_address().
>
> If there are many calls that follow this pattern, it may be better to
> add the tag reset in __set_memory_enc_dec().
I had the same thought.
>
> I can undo this change.
>
Unfortunately, I don't know whether undoing it is right or not. I
haven't taken the time to go learn about the whole scheme and its
implications.
Michael
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-26 15:01 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
This looks good to me. Linus: do you want me to take patch 2/2 as well? I'll
send it for v7.2-rc2.
Bart
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Vanshidhar Konda @ 2026-06-26 14:55 UTC (permalink / raw)
To: Pengjie Zhang
Cc: Will Deacon, catalin.marinas, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui,
linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <443104e2-ba6e-454e-8469-909f35817a99@huawei.com>
On Wed, May 20, 2026 at 10:55:54AM +0800, Pengjie Zhang wrote:
>
>On 5/19/2026 6:47 PM, Will Deacon wrote:
>>On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>>>Hi all,
>>>
>>>Gentle ping on this thread. It has been a while since I posted it.
>>>
>>>Could someone please take a look when you have time? If there is anything
>>>I should revise or any additional information needed, I'd be happy to
>>>update it.
>>It's hard to find active folks who have contributed meaningfully to the
>>cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
>>a look.
>>
>>Will
>Thanks Will, and thanks for adding Ionela and Jeremy.
>
>While waiting for further comments, I would like to add some
>test data to make the effect of this series clearer.
>
>On the test platform, the maximum frequency reported by the platform
>is 2300000. I sampled cpuinfo_cur_freq before and after applying this
>series.
>
>Before applying the series, the samples showed visible transient outliers.
>??The minimum value was 2154583 and the maximum value was 2491071.
>There were 8 samples above 2400000 and 8 samples below 2200000.
>The largest value exceeded the platform maximum by about 8.3%.
>
>After applying the series, the samples became much more stable.
>The minimum value was 2290243 and the maximum value was 2306310.
>There were no samples above 2400000 and no samples below 2200000.
>The largest value exceeded the platform maximum by only about 0.27%.
>
>A summary of the 96 samples is:
>
>?? ?? ?? ?? ?? ?? ?? ?? ?? ?? before?? ?? ?? ?? ?? after
>min?? ?? ?? ?? ?? ?? ?? 2154583?? ?? ?? ?? ??2290243
>max?? ?? ?? ?? ?? ?? ?? 2491071?? ?? ?? ?? ??2306310
>range?? ?? ?? ?? ?? ?? ??336488?? ?? ?? ?? ?? ??16067
>average?? ?? ?? ?? ?? 2298436.4?? ?? ?? ??2298479.4
>stddev?? ?? ?? ?? ?? ?? ??55184.1?? ?? ?? ?? ?? 2868.2
>samples > 2300000?? 26 / 96?? ?? ?? ?? ??16 / 96
>samples > 2400000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>samples < 2200000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>
>So this series does not try to clamp the value to the platform maximum.
>??Instead, it reduces the sampling skew between the delivered and reference
>feedback counters. The remaining small deviation around 2300000 is
>??much smaller than the previous transient spikes.
>
>One concern that may come up is that an FFH read may cause an idle
>target CPU to be woken, depending on the platform/vendor implementation.
>However, that behavior is not introduced by this series. It is already part
>of how FFH counter reads are implemented on such platforms. This series
>only changes the sampling form for the FFH feedback counters: when both
>delivered and reference counters are FFH counters, read them together
>instead of issuing two separate FFH reads.
>
>If the target CPU has to be involved for an FFH read, doing one paired
>read should be no worse than doing two separate reads, and it also
>narrows the sampling window between the two counters.
>
I agree with this point. It reduces the number of times the idle CPU
is woken up just to read counters.
>If there is any concern about the generic hook or the arm64 implementation,
>I would be happy to revise it.
>
>The raw data is as follows:
>before:
>2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
>2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
>2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
>2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
>2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
>2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
>2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
>2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
>2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
>2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
>2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
>2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
>
>after:
>2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
>2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
>2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
>2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
>2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
>2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
>2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
>2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
>2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
>2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
>2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
>2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708
I tested this series on Ampere AmpereOne A192-32X.
Tested-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Regards,
Vanshidhar Konda
>>>On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
>>>>The legacy CPPC feedback-counter path reads the delivered and reference
>>>>performance counters separately.
>>>>
>>>>On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
>>>>served through a cross-CPU counter read helper. Reading the counters
>>>>separately therefore widens the sampling window between them and can
>>>>skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
>>>>load, the skew is observable as transient values that may exceed the
>>>>platform maximum, as discussed in [1] and [2].
>>>>
>>>>This series adds a small generic hook for architectures that can obtain
>>>>both FFH feedback counters in one operation, while preserving the
>>>>existing per-register read path as the fallback.
>>>>
>>>>Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
>>>>Patch 2 implements the hook on arm64 by sampling both AMU counters in a
>>>>single operation on the target CPU.
>>>>
>>>>[1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>>>[2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>>
>>>>Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>>>
>>>>Pengjie Zhang (2):
>>>> ACPI: CPPC: add paired FFH feedback-counter read hook
>>>> arm64: topology: read CPPC FFH feedback counters in one operation
>>>>
>>>> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
>>>> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
>>>> include/acpi/cppc_acpi.h | 7 ++++
>>>> 3 files changed, 127 insertions(+), 13 deletions(-)
>>>>
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Shyam Saini @ 2026-06-26 14:54 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-mm, linux-doc, linux-kernel, akpm, tgopinath, bboscaccy,
kees, tony.luck, gpiccoli, bp, rdunlap, peterz, feng.tang,
dapeng1.mi, elver, enelsonmoore, kuba, lirongqing, ebiggers,
Catalin Marinas, Will Deacon, Ard Biesheuvel, David Hildenbrand,
linux-arm-kernel
In-Reply-To: <ajzovhWHcFQZ9d3l@kernel.org>
On 25 Jun 2026 11:37, Mike Rapoport wrote:
> Hi Shyam,
>
> On Wed, Jun 24, 2026 at 06:22:33PM -0700, Shyam Saini wrote:
> > On 21 Jun 2026 13:36, Mike Rapoport wrote:
> > > On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> > > > reserve_mem relies on dynamic memory allocation, this limits the
> > > > usecase where memory is required to be preserved across the boots.
> > > > Eg: ramoops memory reservation on ACPI platforms
> > > >
> > > > So add support to pass a pre-determined static address and reserve
> > > > memory at a specified location. This enables use case like ramoops
> > > > on ACPI platforms to reliably access ramoops region with previous
> > > > boot logs.
> > > >
> > > > Also skip the parsing of <align> when static address is passed.
> > > >
> > > > Example syntax for static address
> > > > reserve_mem=4M@0x1E0000000:oops
> > >
> > > reserve_mem is best effort by design because such hacks as well as memmap=
> > > cannot guarantee this memory is actually free.
> > >
> > > If you want to preserve ramoops reliably, use KHO with reserve_mem.
> > > The first kernel will allocate memory, this memory will be preserved by KHO
> > > and could be picked up by the second kernel.
> >
> > ok, On ARM64 DTS systems, we can reserve ramoops memory in the device tree during
> > the warm reboot.
>
> The cc list actually implied x86 ;-)
> Added arm64 folks now.
Thanks for adding ARM folks, I had just included whatever get_maintainer script
suggested, sorry.
> > For an equivalent ARM64 ACPI platform, what is the recommended way to reserve
> > and preserve that memory across the boots?
>
> I don't think it exists, but a command line option (be it memmap= or
> reserve_mem=) does not seem the right way to me.
>
> Most of the arguments that were made against adding memmap= to arm64 [1]
> apply here.
>
> If kexec is an option, KHO provides a reliable way to preserve memory
> across boots.
>
> If kexec is not an option, we should look for a generic way to specify
> something like DT's reserved_mem for ACPI/EFI systems.
>
> [1] https://lkml.kernel.org/lkml/20201118063314.22940-1-song.bao.hua@hisilicon.com/T/
>
Well, kexec is one of the option for my use case, it also requires
memory reservation during warm reboot, I think memory can be reserved in
the firmware but this will create a dependency on firmware for Linux
reservation.
It would be great to have a in kernel memory reservation mechanism for
ARM64 ACPI platforms. I believe some other use cases like PMEM
reservation would also benefit from this.
Thanks,
Shyam
^ permalink raw reply
* Re: [PATCH v2 00/11] iommu/arm-smmu-v3: Add PRI support
From: harsha.v @ 2026-06-26 14:54 UTC (permalink / raw)
To: Nicolin Chen, will, robin.murphy, jgg
Cc: joro, bhelgaas, praan, kevin.tian, kees, smostafa, baolu.lu,
linux-arm-kernel, iommu, linux-kernel, linux-pci, skaestle,
mmarrid, skolothumtho, bbiber
In-Reply-To: <cover.1779944354.git.nicolinc@nvidia.com>
Hi Nicolin Chen,
On 5/28/2026 1:29 PM, Nicolin Chen wrote:
> The SMMUv3 driver doesn't handle events on the PRI queue or respond to IOPF
> faults. This series adds the missing pieces, using the IOPF infrastructure,
> to convert PRI page requests into iopf_faults and issue CMDQ_OP_PRI_RESP.
>
> The iopf_queue_flush_dev() contract requires the driver to first drain the
> hardware PRI queue and synchronize using a threaded IRQ handler before the
> IOPF software flush. This drove the additional commits compared to v1:
> - arm_smmu_drain_queue_for_iopf() drains the hardware queue to the PROD
> snapshot
> - arm_smmu_attach_release() moves the teardown outside the global lock
> - synchronize_irq() closes the gap before the final flush
>
> This is on Github:
> https://github.com/nicolinc/iommufd/commits/smmuv3_pri-v2
>
> FWIW, engineers on the NVIDIA side have managed to verify the PRI feature.
>
> Changelog
> v2:
> * Allocate evtq.iopf for ARM_SMMU_FEAT_PRI
> * Pick up Jean's PRI stubs and PRI export patches
> * Enable PRI for PCI devices in arm_smmu_probe_device()
> * Add arm_smmu_drain_queue_for_iopf() for EVTQ and PRIQ
> * Add arm_smmu_attach_release() to rework the IOPF drain
> * Add IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS for STALL mode
> * Gate pci_enable_pri() on FEAT_PRI plus a non-NULL evtq.iopf
> * Deny unrecognised-StreamID PRG_LAST in arm_smmu_handle_ppr()
> * Disable PRI when no IRQ handler is registered (unique or combined IRQ)
> v1:
> https://lore.kernel.org/all/cover.1772568590.git.nicolinc@nvidia.com/
>
> Jean-Philippe Brucker (2):
> PCI/ATS: Add PRI stubs
> PCI/ATS: Export pci_enable_pri() and pci_reset_pri()
>
> Malak Marrid (1):
> iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event
>
> Nicolin Chen (8):
> iommu/arm-smmu-v3: Add arm_smmu_attach_release()
> iommu/arm-smmu-v3: Factor out __queue_empty() and __queue_consumed()
> iommu/arm-smmu-v3: Add arm_smmu_drain_queue_for_iopf() helper
> iommu/arm-smmu-v3: Drain in-flight fault handlers
> iommu/arm-smmu-v3: Support PRI Page Request in arm_smmu_handle_ppr()
> iommu/arm-smmu-v3: Disable PRI when no IRQ handler is registered
> iommu/arm-smmu-v3: Allocate IOPF queue for ARM_SMMU_FEAT_PRI
> iommu/arm-smmu-v3: Enable PRI for PCI device in
> arm_smmu_probe_device()
>
> drivers/iommu/arm/Kconfig | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 +
> include/linux/iommu.h | 1 +
> include/linux/pci-ats.h | 5 +
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 244 +++++++++++++++---
> drivers/pci/ats.c | 2 +
> 7 files changed, 221 insertions(+), 36 deletions(-)
>
>
> base-commit: 74fa4c177ad09800b007cba043370c887bb1b4e3
One thing I noticed while reviewing: when arm_smmu_priq_thread() detects
PRIQ overflow, partial faults (non-LAST pages stored via
report_partial_fault()) whose LAST page was lost in the overflow remain
permanently in iopf_param->partial. This is a monotonic memory leak —
it grows with each overflow event.
Intel VT-d handles this in prq_event_thread() (drivers/iommu/intel/prq.c):
if (head == tail) {
iopf_queue_discard_partial(iommu->iopf_queue);
writel(DMA_PRS_PRO, iommu->reg + DMAR_PRS_REG);
}
iopf_queue_discard_partial() was written for exactly this scenario.
Could we add the same here arm_smmu_priq_thread()
(drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c) ?
if (queue_sync_prod_in(q) == -EOVERFLOW) {
dev_err(smmu->dev, "PRIQ overflow detected -- requests lost\n");
+ iopf_queue_discard_partial(smmu->evtq.iopf);
}
At this point all surviving entries have already been consumed by the
loop above, so discarding unconditionally is safe — implicitly matching
Intel's "head == tail" guard.
Best Regards,
Harsha Vardhan V
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-06-26 14:48 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:16 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> This was reported on Khadas VIM3 and worked around for Amlogic by
> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping"), which marked the whole meson controller sleeping. That
> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
> no longer detects devices, because its IRQ-disabled read slot calls the
> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>
> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>
> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
> gating on gpiod_cansleep() change behaviour. No current device needs
> atomic (non-cansleep) value access on a shared GPIO -- every report
> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
> which is what the proxy exists to vote on; bit-banging that needs atomic
> access cannot work through voting anyway. An alternative that keeps
> atomic value access (split locking) is possible but adds a second lock
> and new race windows, so this series takes the simpler mutex-only
> approach.
>
> The two are a unit: patch 2 must not be applied without patch 1,
> otherwise the original VIM3 splat returns on boards that share a meson
> GPIO -- please keep the order. I have not Cc'd stable; I will request
> stable backports separately once both patches have landed.
>
> Changes since v1:
> - gpio: shared-proxy: open-code the descriptor mutex; drop the
> gpio_shared_desc_lock guard and the gpio_shared_lockdep_assert()
> helper, move the mutex rationale to the can_sleep assignment. No
> functional change.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-1-v@baodeep.com/
>
> Viacheslav Bocharov (2):
> gpio: shared-proxy: always serialize with a sleeping mutex
> pinctrl: meson: restore non-sleeping GPIO access
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++----------------
> drivers/gpio/gpiolib-shared.c | 9 +---
> drivers/gpio/gpiolib-shared.h | 28 +-----------
> drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
> 4 files changed, 30 insertions(+), 75 deletions(-)
>
>
> base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
> --
> 2.54.0
>
>
I have no idea what's wrong but I'm still getting two copies of each email
as separate messages to my inbox. I'm not seeing it with anyone else. I think
there's some issue with your setup.
Bart
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck
From: Quentin Schulz @ 2026-06-26 14:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Quentin Schulz, stable
From: Quentin Schulz <quentin.schulz@cherry.de>
According to the Jedec 5.1 specification, the device is held in reset
when RST_n is low, therefore the polarity of the line must be that, as
specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml).
Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162]
bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset
forever.
Cc: stable@vger.kernel.org
Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
PX30 Ringneck is affected by the same issue that Cobra and PP-1516 have
and for which patches[1][2] have already been sent.
Out of the other boards I own, RK3588 Tiger and Jaguar also have an
inverted polarity but I tried making the eMMC chip care about the reset
line polarity to no avail, therefore I'm not changing them until we
figure out a setup in which we can reproduce the issue.
There are a handful of other Rockchip boards with an inverted polarity
but I don't own any of them so I will not change them either.
[1] https://lore.kernel.org/linux-rockchip/20260609081728.30616-2-jakobunt@gmail.com/
[2] https://lore.kernel.org/linux-rockchip/20260612-pp1516-emmc-polarity-v1-1-4816c1c909f7@cherry.de/
---
arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
index 973b4c5880e24..29794216592d8 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
@@ -26,7 +26,7 @@ emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
pinctrl-0 = <&emmc_reset>;
pinctrl-names = "default";
- reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
};
leds {
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260626-ringneck-emmc-polarity-717003c6b802
Best regards,
--
Quentin Schulz <quentin.schulz@cherry.de>
^ permalink raw reply related
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Maxime Ripard @ 2026-06-26 14:38 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJJ1MPCEJGZD.UZM9183V6ZE5@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]
On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> >> > Hi,x
> >> >
> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> >> connector from different code paths.
> >> >> >
> >> >> > Same story here, explaining what you need later on that calls for that
> >> >> > change would be nice.
> >> >>
> >> >> Here's a more verbose version:
> >> >>
> >> >> Currently drm_bridge_connector_init() does two things:
> >> >>
> >> >> * allocate and initialize the drm_bridge_connector
> >> >> (which embeds a drm_connector)
> >> >> * initialize and register the embedded drm_connector
> >> >>
> >> >> For bridge hotplug we need to separate these two actions:
> >> >>
> >> >> * the drm_connector needs to be added and removed at any time based on
> >> >> hotplug events
> >> >> * the drm_bridge_connector is designated to create and remove the
> >> >> drm_connector, so it must be persistent for the card lifetime
> >> >>
> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
> >> >> different, we need to create them in different moments.
> >> >>
> >> >> In preparation to support that, split out from
> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> dedicated function. No functional changes, just moving code around for
> >> >> now. A future commit will make the drm_connector be created based on
> >> >> hotplug events.
> >> >>
> >> >> Looks good?
> >> >
> >> > The message itself, yes, thanks.
> >> >
> >> > However, I have questions now :)
> >> >
> >> > Do we really expect drm_bridge_connector to stick around when a bridge
> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
> >> > connector, and then swapping out the hotplugged part for an LVDS one?
> >> > Does the HDMI connector sticks around indefinitely?
> >>
> >> In your example, the HDMI drm_connector would be unregistered and put on
> >> hotunplug. Its allocation will stick around until the last put but that's
> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> >> drm_connector will be created and registered.
> >>
> >> > *Especially* if we're using overlays for this, I'd expect everything
> >> > after the first hotplugged bridge to be destroyed, no?
> >>
> >> As said, it would be unregistered immediately but might be freed later on
> >> if still refcounted.
> >>
> >> This is visible in patches 36+15, the path to follow is:
> >>
> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
> >> -> drm_bridge_connector_dynconn_release() [patch 15]
> >>
> >> Does this solve your concern?
> >
> > Not really, I'm talking about drm_bridge_connector. The fact that
> > bridges are destroyed make sense to me. The fact that
> > drm_bridge_connector sticks around doesn't. It's supposed to be a
> > connector for bridges. If you don't have bridges because they got
> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
>
> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
> this.
>
> I'd say with this series a "drm_bridge_connector" is just becoming
> something more (perhaps something else too). Somewhat as "a drm_bridge is
> either a bridge or something else". :)
>
>
> But let's leave names aside for a moment. If just looking at the current
> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
> having the same lifetime, which takes care of drm_connector
> creation/destruction at card probe/removal".
>
> What we need now is just the same plug " and on hotplug events" appended.
>
> So in both cases there needs to be "a handler persitent with the card".
>
> Do we agree so far?
Ish. If we go for that, then we need to update the name.
drm_bridge_connector for something that is neither a bridge or a
connector is not great.
But even then, I'm not even sure why we need to have that "manager" in
the first place. You want to make bridges be aware if they are the last
in the chain or not. Use that property in attach to either create a
drm_bridge_connector instance if you're last, or attach the next bridge
if you aren't.
And when a bridge is removed, drop everything after it in the chain,
drm_bridge_connector instance included.
And the encoder can take care of handling bridge remove and tearing down
the bridge chain itself.
Maximex
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH] soc: imx8m: fix clock reference leak in imx8m_soc_prepare()
From: Felix Gu @ 2026-06-26 14:37 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Peng Fan, Shawn Guo
Cc: imx, linux-arm-kernel, linux-kernel, Felix Gu
When clk_prepare_enable() fails, the error path does not release the
clock reference obtained by of_clk_get_by_name(). Add clk_put() to
the error path before iounmap().
Fixes: 390c01073f5d ("soc: imx8m: Cleanup with adding imx8m_soc_[un]prepare")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/soc/imx/soc-imx8m.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
index fc080e56f50d..de19972435f9 100644
--- a/drivers/soc/imx/soc-imx8m.c
+++ b/drivers/soc/imx/soc-imx8m.c
@@ -150,10 +150,12 @@ static int imx8m_soc_prepare(struct platform_device *pdev, const char *ocotp_com
ret = clk_prepare_enable(drvdata->clk);
if (ret)
- goto err_clk;
+ goto put_clk;
return 0;
+put_clk:
+ clk_put(drvdata->clk);
err_clk:
iounmap(drvdata->ocotp_base);
return ret;
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260626-soc-imx8m-938e89104044
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 8/8] arm64: dts: rockchip: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:36 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-8-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:08:00PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the rockchip device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
> arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> index 192791993f05..d58d6ee6241e 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> @@ -6,6 +6,7 @@
> /dts-v1/;
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include "px30.dtsi"
>
> @@ -413,7 +414,7 @@ camera@36 {
> dvdd-supply = <&vcc_cam_dvdd>;
> dovdd-supply = <&vcc_cam_dovdd>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0 &cam_pwdn>;
> reset-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> index 760d5139f95d..2168db9168a5 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> @@ -16,6 +16,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -185,7 +186,7 @@ camera@36 {
> dvdd-supply = <&cam_dvdd_1v2>;
> dovdd-supply = <&cam_dovdd_1v8>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0>;
> reset-gpios = <&pca9670 6 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> index 8d26bd9b7500..6608c777f185 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/linux-event-codes.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "rk3399-s.dtsi"
>
> / {
> @@ -455,7 +456,7 @@ wcam: camera@1a {
> reg = <0x1a>;
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK0, derived from CIF_CLKO */
> lens-focus = <&wcam_lens>;
> - orientation = <1>; /* V4L2_CAMERA_ORIENTATION_BACK */
> + orientation = <MEDIA_ORIENTATION_BACK>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera_rst_l>;
> reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;
> @@ -487,7 +488,7 @@ ucam: camera@36 {
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK1, derived from CIF_CLK0 */
> clock-names = "xvclk";
> dovdd-supply = <&vcc1v8_dvp>;
> - orientation = <0>; /* V4L2_CAMERA_ORIENTATION_FRONT */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera2_rst_l &dvp_pdn0_h>;
> powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> index ee9ecf68a886..8c9a4a1181e4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam0>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
> dvdd-supply = <&sdvdd_cam0>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam0>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam0_rstn &mipim0_camera3_clk>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> index 8a4cf3fdbf8e..0cc3d6a34cef 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ cam1_imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam1>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
> dvdd-supply = <&sdvdd_cam1>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam1>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam1_rstn &mipim0_camera4_clk>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:34 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-7-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:59PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the renesas device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> index 3acaf714cf24..b816382bba0a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j1>;
> VDDL-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> index a19bc0840392..4019b80a88b7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j1>;
> vddd-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> index 512810b861aa..fea1ef4a1178 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j2>;
> VDDL-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> index a31524b59834..177201a8a6d2 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j2>;
> vddd-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
--
Regards,
Laurent Pinchart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox