* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 12:47 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260326-add-airoha-an8801-support-v2-4-1a42d6b6050f@collabora.com>
> +static int an8801r_led_blink_set(struct phy_device *phydev, u8 index,
> + unsigned long *delay_on,
> + unsigned long *delay_off)
> +{
...
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EN, blink ? LED_ON_EN : 0);
> + if (ret)
> + return ret;
> +
> + return 0;
Just
return phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
LED_ON_EN, blink ? LED_ON_EN : 0);
> + if (!led_trigger)
> + continue;
> +
> + ret = an8801r_led_hw_control_set(phydev, led_id, led_trigger);
> + if (ret)
> + return ret;
> + }
> + return 0;
> +}
Please take a look at all your functions. Can the last error check be
removed and just use return ret, etc.
> +static int an8801r_of_init_leds(struct phy_device *phydev, u8 *led_cfg)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *leds;
> + u32 function_enum_idx;
> + int ret;
> +
> + if (!np)
> + return 0;
> +
> + /* If devicetree is present, leds configuration is required */
> + leds = of_get_child_by_name(np, "leds");
> + if (!leds)
> + return 0;
> +
> + for_each_available_child_of_node_scoped(leds, led) {
> + u32 led_idx;
> +
> + ret = of_property_read_u32(led, "reg", &led_idx);
> + if (ret)
> + goto out;
> +
> + if (led_idx >= AN8801R_NUM_LEDS) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = of_property_read_u32(led, "function-enumerator",
> + &function_enum_idx);
> + if (ret)
> + function_enum_idx = AN8801R_LED_FN_NONE;
> +
What is this doing? Is this documented in the binding?
> + if (function_enum_idx >= AN8801R_LED_FN_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + led_cfg[led_idx] = function_enum_idx;
> + }
> +out:
> + of_node_put(leds);
> + return ret;
> +}
> +static int an8801r_read_status(struct phy_device *phydev)
> +{
> + int prev_speed, ret;
> + u32 val;
> +
> + prev_speed = phydev->speed;
> +
> + ret = genphy_read_status(phydev);
> + if (ret)
> + return ret;
> +
> + if (phydev->link && prev_speed != phydev->speed) {
> + val = phydev->speed == SPEED_1000 ?
> + AN8801_BPBUS_LINK_MODE_1000 : 0;
> +
> + return an8801_buckpbus_reg_rmw(phydev,
> + AN8801_BPBUS_REG_LINK_MODE,
> + AN8801_BPBUS_LINK_MODE_1000,
> + val);
> + };
This is unusual. What is it doing? Please add a comment.
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/3] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
From: Will Deacon @ 2026-03-26 12:49 UTC (permalink / raw)
To: Fuad Tabba
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose,
Alexandru Elisei, Yabin Cui
In-Reply-To: <CA+EHjTxcc2FArmi1hu17LW3BHUZ5zTnqbaQP0kbV39HXZfp9+Q@mail.gmail.com>
On Wed, Mar 25, 2026 at 07:27:32PM +0000, Fuad Tabba wrote:
> On Fri, 27 Feb 2026 at 21:22, Will Deacon <will@kernel.org> wrote:
> >
> > The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace
> > generation in guest context when self-hosted TRBE is in use by the host.
> >
> > Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing
> > TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but
> > per R_YCHKJ the Trace Buffer Unit will still be enabled if
> > TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the
> > Trace Buffer Unit can perform address translation for the "owning
> > exception level" even when it is out of context.
> >
> > Consequently, we can end up in a state where TRBE performs speculative
> > page-table walks for a host VA/IPA in guest/hypervisor context depending
> > on the value of MDCR_EL2.E2TB, which changes over world-switch. The
> > potential result appears to be a heady mixture of SErrors, data
> > corruption and hardware lockups.
> >
> > Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after
> > draining the buffer, restoring the register on return to the host. This
> > unfortunately means we need to tackle CPU errata #2064142 and #2038923
> > which add additional synchronisation requirements around manipulations
> > of the limit register. Hopefully this doesn't need to be fast.
> >
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Oliver Upton <oupton@kernel.org>
> > Cc: James Clark <james.clark@linaro.org>
> > Cc: Leo Yan <leo.yan@arm.com>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Fuad Tabba <tabba@google.com>
> > Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> > Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host")
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 1 +
> > arch/arm64/kvm/hyp/nvhe/debug-sr.c | 73 ++++++++++++++++++++++++++----
> > arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
> > 3 files changed, 66 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 5d5a3bbdb95e..1532ad2b2ec2 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -770,6 +770,7 @@ struct kvm_host_data {
> > u64 pmscr_el1;
> > /* Self-hosted trace */
> > u64 trfcr_el1;
> > + u64 trblimitr_el1;
> > /* Values of trap registers for the host before guest entry. */
> > u64 mdcr_el2;
> > u64 brbcr_el1;
> > diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> > index 2a1c0f49792b..3dbdee1148d3 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> > @@ -57,12 +57,56 @@ static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
> > write_sysreg_el1(new_trfcr, SYS_TRFCR);
> > }
> >
> > -static bool __trace_needs_drain(void)
> > +static void __trace_drain_and_disable(void)
> > {
> > - if (is_protected_kvm_enabled() && host_data_test_flag(HAS_TRBE))
> > - return read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E;
> > + u64 *trblimitr_el1 = host_data_ptr(host_debug_state.trblimitr_el1);
> >
> > - return host_data_test_flag(TRBE_ENABLED);
> > + *trblimitr_el1 = 0;
> > +
> > + if (is_protected_kvm_enabled()) {
> > + if (!host_data_test_flag(HAS_TRBE))
> > + return;
> > + } else {
> > + if (!host_data_test_flag(TRBE_ENABLED))
> > + return;
> > + }
>
> Can we simplify this? e.g.,
>
> + bool needs_drain = is_protected_kvm_enabled() ?
> host_data_test_flag(HAS_TRBE) : host_data_test_flag(TRBE_ENABLED);
> ....
Good idea. I tend to avoid 'bool's as they often make the code less
readable in my experience, but in this case it would be a lot better
than the nested conditionals I have. I'll spin a v3!
> That said:
>
> Tested-by: Fuad Tabba <tabba@google.com>
> Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
Will
^ permalink raw reply
* Re: [PATCH] ARM: dts: renesas: rza2mevb: Drop RTL8211F PHY C22 compatible string
From: Marek Vasut @ 2026-03-26 12:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdVwa47N2VsvH8pBkAD215dr3M-qkA0SXed0vhLS2-aoKA@mail.gmail.com>
On 3/26/26 10:45 AM, Geert Uytterhoeven wrote:
Hello Geert,
> On Thu, 26 Mar 2026 at 05:54, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Realtek RTL8211F PHY schema indicates that compatible string
>> "ethernet-phy-id001c.c916" must not be followed by any other
>
> This is actually RTL8201F / c816; I will fix this while applying.
Ouf ... thank you.
^ permalink raw reply
* Re: [PATCH v5 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Neil Armstrong @ 2026-03-26 12:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-1-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..36d13371f56ba 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc-clk-gate {
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard-clk-gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux {
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio-clk-gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2 0/2] mmc: hisilicon: Convert dw-mshc bindings and fix dtbs
From: Wei Xu @ 2026-03-26 12:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Bhargav Joshi, devicetree, linux-arm-kernel, robh, krzk+dt,
conor+dt, zhangfei.gao, linux-mmc, daniel.baluta, simona.toaca,
d-gole, m-chawdhry, linux-kernel
In-Reply-To: <CAPDyKFq6F3PZgqTtHXZPQPPBvdPhsQPtUVHiZV6X-QXvS42+CA@mail.gmail.com>
Hi Uffe,
On 2026/3/26 20:39, Ulf Hansson wrote:
> On Thu, 26 Mar 2026 at 12:19, Wei Xu <xuwei5@hisilicon.com> wrote:
>>
>> Hi Bhargav,
>>
>> On 2026/3/26 6:54, Bhargav Joshi wrote:
>>> This series converts the Hisilicon dw-mshc text bindings to DT schema
>>> format and cleans up legacy node names in Hisilicon board files.
>>>
>>> While testing the new YAML schema, dtbs_check flagged the hi3660,
>>> hi3670, and hi6220 SoC files for using the non-standard 'dwmmc' node
>>> name prefix. resulting in warnings.
>>>
>>> Patch 1 Convert to DT schema
>>> Patch 2 updates the Hisilicon dtsi files to use standard 'mmc'
>>> node name.
>>>
>>> Changes in v2:
>>> - Patch 1:
>>> - Grouped compatible strings into an enum.
>>> - Replaced raw numbers with proper flags.
>>> - Fixed property order and removed invalid hex values.
>>> - Added explanation for clock order change in commit message.
>>> - Collected Acked-by tag.
>>> - Patch 2:
>>> - No code changes.
>>> - Collected Acked-by and Reviewed-by tags.
>>>
>>> Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
>>> ---
>>> Note: this patch is part of the process for applying to GSoC device
>>> tree bindings conversion project #
>>> https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>>>
>>> - The file is enabled by arm64 defconfig (CONFIG_MMC_DW_K3=y)
>>> - It is used in following
>>> /arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>>> -included by /arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>>> /arch/arm64/boot/dts/hisilicon/hi3670.dtsi
>>> -included by /arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
>>>
>>> Bhargav Joshi (2):
>>> dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
>>> arm64: dts: hisilicon: Rename dwmmc nodes to mmc
>>>
>>> .../mmc/hisilicon,hi3660-dw-mshc.yaml | 117 ++++++++++++++++++
>>> .../devicetree/bindings/mmc/k3-dw-mshc.txt | 73 -----------
>>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 +-
>>> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 +-
>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 6 +-
>>> 5 files changed, 124 insertions(+), 80 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
>>> delete mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>>>
>>
>> Series applied to the HiSilicon arm64 dt tree.
>> Thanks!
>>
>> Best Regards,
>> Wei
>
> Usually I pick DT bindings (patch1/2) for mmc via my mmc tree and I
> also just did. Would it be possible for you to drop patch1/2 from your
> tree?
So I will drop them.
Thanks!
Best Regards,
Wei
>
> Kind regards
> Uffe
>
> .
>
^ permalink raw reply
* Re: [PATCH v5 8/9] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Neil Armstrong @ 2026-03-26 12:55 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-8-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> Add bcm43752 compatible with its bcm4329 compatible fallback.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index 3be7576787644..81fd3e37452a6 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> @@ -42,6 +42,7 @@ properties:
> - brcm,bcm4356-fmac
> - brcm,bcm4359-fmac
> - brcm,bcm4366-fmac
> + - brcm,bcm43752-fmac
> - cypress,cyw4373-fmac
> - cypress,cyw43012-fmac
> - infineon,cyw43439-fmac
>
I'll apply all the other DT patches, please send this one alone with the [PATCH net-next] prefix so it gets picked by the wireless/net people.
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v5 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Neil Armstrong @ 2026-03-26 12:56 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-3-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> Add device tree nodes for the three MMC controllers available
> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 36d13371f56ba..fe1ced0a58967 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
> reg = <0x0 0x10220 0x0 0x140>;
> amlogic,has-chip-id;
> };
> +
> + sd_emmc_a: mmc@88000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x88000 0x0 0x800>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
> + <&clkc_periphs CLKID_SD_EMMC_A>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> +
> + sd_emmc_b: mmc@8a000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8a000 0x0 0x800>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
> + <&clkc_periphs CLKID_SD_EMMC_B>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> +
> + sd_emmc_c: mmc@8c000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8c000 0x0 0x800>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
> + <&clkc_periphs CLKID_SD_EMMC_C>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> };
>
> };
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* [PATCH v4 0/2] Support TQMa8QM
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
Hi,
this series adds support for TQ's TQMa8QM. In v4 several prepatory have been
merged already. So this series include only the two missing patches:
1. platform DT
2. Workaround for missing "ERR050104: Arm/A53: Cache coherency issue"
workaround. See [1] for details. Split into separate commit for easy revert
once an errata workaround has been integrated.
Changes in v4:
* Reduced recipient audience due to reduced patches
* Sorted nodes by name (not by phandle)
Changes in v3:
* Small cleanups in patch 1 & 4
Changes in v2:
The need for clock-output-names properties for renesas,9fgv0441 has
been removed by reworkging the PCIe clocking
Best regards,
Alexander
[1] https://lore.kernel.org/all/20230420112952.28340-1-iivanov@suse.de/
Alexander Stein (2):
arm64: dts: freescale: add initial device tree for TQMa8x
arm64: dts: imx8qm-tqma8qm-mba8x: Disable Cortex-A72 cluster
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 871 ++++++++++++++++++
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 325 +++++++
3 files changed, 1197 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
--
2.43.0
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: imx8qm-tqma8qm-mba8x: Disable Cortex-A72 cluster
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326130225.1406806-1-alexander.stein@ew.tq-group.com>
Due to missing workaround for "ERR050104: Arm/A53: Cache coherency issue"
disable the whole Cortex-A72 cluster.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v4:
* None
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 39 -------------------
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 13 +++++--
2 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
index bf972010a88e7..ab3b244b684fd 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
@@ -298,45 +298,6 @@ map3 {
};
};
};
-
- cpu1-thermal {
- trips {
- soc_active1_0: trip-active0 {
- temperature = <40000>;
- hysteresis = <5000>;
- type = "active";
- };
-
- soc_active1_1: trip-active1 {
- temperature = <48000>;
- hysteresis = <3000>;
- type = "active";
- };
-
- soc_active1_2: trip-active2 {
- temperature = <60000>;
- hysteresis = <10000>;
- type = "active";
- };
- };
-
- cooling-maps {
- map1 {
- trip = <&soc_active1_0>;
- cooling-device = <&fan0 1 1>;
- };
-
- map2 {
- trip = <&soc_active1_1>;
- cooling-device = <&fan0 2 2>;
- };
-
- map3 {
- trip = <&soc_active1_2>;
- cooling-device = <&fan0 3 3>;
- };
- };
- };
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
index d94605c999915..f0e398eb2aad7 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
@@ -15,6 +15,13 @@ / {
model = "TQ-Systems i.MX8QM TQMa8QM";
compatible = "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+ /* Due to missing workaround for ERR050104 */
+ cpus {
+ /delete-node/ cpu-map;
+ /delete-node/ cpu@100;
+ /delete-node/ cpu@101;
+ };
+
memory@80000000 {
device_type = "memory";
/*
@@ -174,6 +181,8 @@ &mu2_m0 {
};
&thermal_zones {
+ /delete-node/ cpu1-thermal;
+
pmic0-thermal {
polling-delay-passive = <250>;
polling-delay = <2000>;
@@ -199,9 +208,7 @@ map0 {
<&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A72_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A72_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] arm64: dts: freescale: add initial device tree for TQMa8x
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326130225.1406806-1-alexander.stein@ew.tq-group.com>
This adds support for TQMa8QM module on MBa8x board, based on i.MX8 SoC.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v4:
* Sorted nodes by node name, not by phandle
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 910 ++++++++++++++++++
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 318 ++++++
3 files changed, 1229 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 04cf176fc1d81..c58b97522e7f0 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -404,6 +404,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-eval-v1.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-mek.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qm-tqma8qm-mba8x.dtb
imx8qm-mek-ov5640-csi0-dtbs := imx8qm-mek.dtb imx8qm-mek-ov5640-csi0.dtbo
dtb-${CONFIG_ARCH_MXC} += imx8qm-mek-ov5640-csi0.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
new file mode 100644
index 0000000000000..bf972010a88e7
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
@@ -0,0 +1,910 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2019-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "imx8qm-tqma8qm.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8QM TQMa8QM on MBa8x";
+ compatible = "tq,imx8qm-tqma8qm-mba8x", "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+
+ adc {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>;
+ };
+
+ aliases {
+ rtc0 = &pcf85063;
+ rtc1 = &rtc;
+ };
+
+ chosen {
+ stdout-path = &lpuart0;
+ };
+
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiokeys>;
+ autorepeat;
+
+ switch-1 {
+ label = "SWITCH_A";
+ linux,code = <BTN_0>;
+ gpios = <&lsio_gpio2 11 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ switch-2 {
+ label = "SWITCH_B";
+ linux,code = <BTN_1>;
+ gpios = <&lsio_gpio1 0 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioled>;
+
+ user-led0 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_HEARTBEAT;
+ gpios = <&lsio_gpio5 20 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ user-led1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&lsio_gpio5 19 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwmfan>;
+ fan-supply = <®_pwm_fan>;
+ #cooling-cells = <2>;
+ /* typical 25 kHz -> 40.000 nsec */
+ pwms = <&lsio_pwm3 0 40000 PWM_POLARITY_INVERTED>;
+ cooling-levels = <0 32 64 128 196 240>;
+ pulses-per-revolution = <2>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ status = "disabled";
+ };
+
+ reg_mba8x_12v: regulator-mba8x-12v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_mba8x_12v>;
+ regulator-name = "MBa8x-V12";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ enable-active-high;
+ gpio = <&lsio_gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_mba8x_v3v3: regulator-mba8x-v3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3_MB";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_pwm_fan: regulator-pwm-fan {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_regpwmfan>;
+ regulator-name = "FAN_PWR";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&lsio_gpio2 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <®_mba8x_12v>;
+ };
+
+ reg_usb_phy: regulator-usb-phy {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <3000000>;
+ regulator-min-microvolt = <3000000>;
+ regulator-name = "usb-phy-dummy";
+ };
+
+ reg_v1v5_pcie: regulator-v1v5-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_pcie_v1v5>;
+ regulator-name = "V_1V5_MPCIE";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ vin-supply = <®_mba8x_v3v3>;
+ enable-active-high;
+ gpio = <&lsio_gpio0 31 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_v1v8: regulator-v1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "MBa8x-V1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_v3v3_pcie: regulator-v3v3-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_pcie_v3v3>;
+ regulator-name = "V_3V3_MPCIE";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <®_mba8x_v3v3>;
+ enable-active-high;
+ gpio = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_v3v3_sd: regulator-v3v3-sd {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_v3v3_sd>;
+ regulator-name = "V3V3_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <®_mba8x_v3v3>;
+ gpio = <&lsio_gpio4 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+ off-on-delay-us = <200000>;
+ };
+
+ reg_vref_v1v8: regulator-vref-v1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VREF_V1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /*
+ * global autoconfigured region for contiguous allocations
+ * must not exceed memory size and region
+ */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x3c000000>;
+ alloc-ranges = <0 0x96000000 0 0x3c000000>;
+ linux,cma-default;
+ };
+
+ decoder_boot: decoder-boot@84000000 {
+ reg = <0 0x84000000 0 0x2000000>;
+ no-map;
+ };
+
+ encoder1_boot: encoder1-boot@86000000 {
+ reg = <0 0x86000000 0 0x200000>;
+ no-map;
+ };
+
+ encoder2_boot: encoder2-boot@86200000 {
+ reg = <0 0x86200000 0 0x200000>;
+ no-map;
+ };
+
+ decoder_rpc: decoder-rpc@92000000 {
+ reg = <0 0x92000000 0 0x100000>;
+ no-map;
+ };
+
+ encoder1_rpc: encoder1-rpc@92100000 {
+ reg = <0 0x92100000 0 0x700000>;
+ no-map;
+ };
+
+ encoder2_rpc: encoder1-rpc@92800000 {
+ reg = <0 0x92800000 0 0x700000>;
+ no-map;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ ssi-controller = <&sai1>;
+ audio-codec = <&tlv320aic3x04>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "imx-audio-dp";
+ audio-cpu = <&sai5>;
+ hdmi-out;
+ };
+
+ thermal-zones {
+ cpu0-thermal {
+ trips {
+ soc_active0_0: trip-active0 {
+ temperature = <40000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+
+ soc_active0_1: trip-active1 {
+ temperature = <48000>;
+ hysteresis = <3000>;
+ type = "active";
+ };
+
+ soc_active0_2: trip-active2 {
+ temperature = <60000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&soc_active0_0>;
+ cooling-device = <&fan0 1 1>;
+ };
+
+ map2 {
+ trip = <&soc_active0_1>;
+ cooling-device = <&fan0 2 2>;
+ };
+
+ map3 {
+ trip = <&soc_active0_2>;
+ cooling-device = <&fan0 3 3>;
+ };
+ };
+ };
+
+ cpu1-thermal {
+ trips {
+ soc_active1_0: trip-active0 {
+ temperature = <40000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+
+ soc_active1_1: trip-active1 {
+ temperature = <48000>;
+ hysteresis = <3000>;
+ type = "active";
+ };
+
+ soc_active1_2: trip-active2 {
+ temperature = <60000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&soc_active1_0>;
+ cooling-device = <&fan0 1 1>;
+ };
+
+ map2 {
+ trip = <&soc_active1_1>;
+ cooling-device = <&fan0 2 2>;
+ };
+
+ map3 {
+ trip = <&soc_active1_2>;
+ cooling-device = <&fan0 3 3>;
+ };
+ };
+ };
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ nvmem-cells = <&fec_mac0>;
+ nvmem-cell-names = "mac-address";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ethphy0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&lsio_gpio2 6 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec2>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy3>;
+ nvmem-cells = <&fec_mac1>;
+ nvmem-cell-names = "mac-address";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy3: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ethphy3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&lsio_gpio2 4 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ };
+ };
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&hsio_phy {
+ fsl,hsio-cfg = "pciea-pcieb-sata";
+ fsl,refclk-pad-mode = "input";
+ status = "okay";
+};
+
+/* no refclock gating */
+&hsio_refa_clk {
+ compatible = "fixed-factor-clock";
+ clocks = <&pcieclk 0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ /delete-property/ enable-gpios;
+};
+
+&hsio_refb_clk {
+ compatible = "fixed-factor-clock";
+ clocks = <&pcieclk 0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ /delete-property/ enable-gpios;
+};
+
+&i2c1 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "mclk";
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;
+ ldoin-supply = <®_mba8x_v3v3>;
+ iov-supply = <®_v1v8>;
+ };
+
+ sensor1: temperature-sensor@1c {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x1c>;
+ };
+
+ eeprom2: eeprom@54 {
+ compatible = "nxp,se97b", "atmel,24c02";
+ reg = <0x54>;
+ pagesize = <16>;
+ vcc-supply = <®_mba8x_v3v3>;
+ };
+
+ pcieclk: clock-generator@68 {
+ compatible = "renesas,9fgv0441";
+ reg = <0x68>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+};
+
+&lpspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi0 &pinctrl_lpspi0_cs>;
+ cs-gpios = <&lsio_gpio3 5 GPIO_ACTIVE_LOW>, <&lsio_gpio3 6 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi1 &pinctrl_lpspi1_cs>;
+ cs-gpios = <&lsio_gpio3 24 GPIO_ACTIVE_LOW>, <&lsio_gpio3 25 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi2 &pinctrl_lpspi2_cs>;
+ cs-gpios = <&lsio_gpio3 10 GPIO_ACTIVE_LOW>, <&lsio_gpio3 11 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpuart0 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart0>;
+ status = "okay";
+};
+
+&lpuart1 {
+ /* X62 pin header */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart1>;
+ status = "okay";
+};
+
+&lpuart2 {
+ /* mikroBUS */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart2>;
+ status = "okay";
+};
+
+&lsio_gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio2>;
+ gpio-line-names = "", "", "", "",
+ "", "PCIE0_DISABLE#", "", "";
+
+ pcie0-wdisable1-hog {
+ gpio-hog;
+ gpios = <5 0>;
+ output-high;
+ line-name = "PCIE0_DISABLE#";
+ };
+
+ pcie-clk-pd-hog {
+ gpio-hog;
+ gpios = <10 0>;
+ output-high;
+ line-name = "PCIE_CLK_PD#";
+ };
+};
+
+&lsio_pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lsio_pwm3>;
+ status = "okay";
+};
+
+&pciea {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pciea>;
+ phys = <&hsio_phy 0 PHY_TYPE_PCIE 0>;
+ phy-names = "pcie-phy";
+ reset-gpio = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pcieb {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcieb>;
+ phys = <&hsio_phy 1 PHY_TYPE_PCIE 1>;
+ phy-names = "pcie-phy";
+ reset-gpio = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai1>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ status = "okay";
+};
+
+&sai5 {
+ status = "okay";
+};
+
+&sai5_lpcg {
+ status = "okay";
+};
+
+&sata {
+ status = "okay";
+};
+
+&usbphy1 {
+ phy-3p0-supply = <®_usb_phy>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1>;
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ power-active-high;
+ over-current-active-low;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb3_phy {
+ status = "okay";
+};
+
+&usbotg3 {
+ /* over-current disabled by default */
+ status = "okay";
+};
+
+&usbotg3_cdns3 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbhub>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&lsio_gpio2 7 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_mba8x_v3v3>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&lsio_gpio2 7 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_mba8x_v3v3>;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ bus-width = <4>;
+ cd-gpios = <&lsio_gpio5 22 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&lsio_gpio5 21 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_v3v3_sd>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio>;
+
+ pinctrl_adc0: adc0grp {
+ fsl,pins = <IMX8QM_ADC_IN1_DMA_ADC0_IN1 0x02000060>,
+ <IMX8QM_ADC_IN2_DMA_ADC0_IN2 0x02000060>;
+ };
+
+ pinctrl_ethphy0: ethphy0grp {
+ fsl,pins = <IMX8QM_ESAI1_SCKR_LSIO_GPIO2_IO06 0x00000041>,
+ <IMX8QM_ESAI1_TX0_LSIO_GPIO2_IO08 0x00000021>;
+ };
+
+ pinctrl_ethphy3: ethphy3grp {
+ fsl,pins = <IMX8QM_ESAI1_FSR_LSIO_GPIO2_IO04 0x00000041>;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <IMX8QM_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB_PAD 0x000014a0>,
+ <IMX8QM_ENET0_MDC_CONN_ENET0_MDC 0x06000041>,
+ <IMX8QM_ENET0_MDIO_CONN_ENET0_MDIO 0x06000041>,
+ <IMX8QM_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3 0x00000041>,
+ <IMX8QM_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3 0x00000040>;
+ };
+
+ pinctrl_fec2: fec2grp {
+ fsl,pins = <IMX8QM_COMP_CTL_GPIO_1V8_3V3_ENET_ENETA_PAD 0x000014a0>,
+ <IMX8QM_ENET1_MDC_CONN_ENET1_MDC 0x06000041>,
+ <IMX8QM_ENET1_MDIO_CONN_ENET1_MDIO 0x06000041>,
+ <IMX8QM_ENET1_RGMII_TX_CTL_CONN_ENET1_RGMII_TX_CTL 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXC_CONN_ENET1_RGMII_TXC 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD0_CONN_ENET1_RGMII_TXD0 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD1_CONN_ENET1_RGMII_TXD1 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD2_CONN_ENET1_RGMII_TXD2 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD3_CONN_ENET1_RGMII_TXD3 0x00000041>,
+ <IMX8QM_ENET1_RGMII_RXC_CONN_ENET1_RGMII_RXC 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RX_CTL_CONN_ENET1_RGMII_RX_CTL 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD0_CONN_ENET1_RGMII_RXD0 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD1_CONN_ENET1_RGMII_RXD1 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD2_CONN_ENET1_RGMII_RXD2 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD3_CONN_ENET1_RGMII_RXD3 0x00000040>;
+ };
+
+ pinctrl_flexcan1: flexcan0grp {
+ fsl,pins = <IMX8QM_FLEXCAN0_TX_DMA_FLEXCAN0_TX 0x00000021>,
+ <IMX8QM_FLEXCAN0_RX_DMA_FLEXCAN0_RX 0x00000021>;
+ };
+
+ pinctrl_flexcan2: flexcan1grp {
+ fsl,pins = <IMX8QM_FLEXCAN1_TX_DMA_FLEXCAN1_TX 0x00000021>,
+ <IMX8QM_FLEXCAN1_RX_DMA_FLEXCAN1_RX 0x00000021>;
+ };
+
+ pinctrl_gpio2: gpio2grp {
+ fsl,pins = <IMX8QM_ESAI1_FST_LSIO_GPIO2_IO05 0x00000021>,
+ <IMX8QM_ESAI1_TX2_RX3_LSIO_GPIO2_IO10 0x00000021>;
+ };
+
+ pinctrl_gpio: gpiogrp {
+ fsl,pins = /* GPIO0_05 on X62:26 */
+ <IMX8QM_SIM0_GPIO0_00_LSIO_GPIO0_IO05 0x00000021>,
+ /* GPIO1_14 on X64:21 */
+ <IMX8QM_LVDS1_I2C1_SCL_LSIO_GPIO1_IO14 0x00000021>,
+ /* GPIO1_15 on X64:23 */
+ <IMX8QM_LVDS1_I2C1_SDA_LSIO_GPIO1_IO15 0x00000021>,
+ /* GPIO2_17 on X63:37 */
+ <IMX8QM_SPI3_SCK_LSIO_GPIO2_IO17 0x00000021>,
+ /* GPIO2_21 on X63:39 */
+ <IMX8QM_SPI3_CS1_LSIO_GPIO2_IO21 0x00000021>,
+ /* GPIO4_12 on X61:24 */
+ <IMX8QM_USDHC2_CD_B_LSIO_GPIO4_IO12 0x00000021>,
+ /* GPIO4_11 on X61:26 */
+ <IMX8QM_USDHC2_WP_LSIO_GPIO4_IO11 0x00000021>,
+ /* GPIO4_10 on X61:28 */
+ <IMX8QM_USDHC2_VSELECT_LSIO_GPIO4_IO10 0x00000021>,
+ /* GPIO4_09 on X61:30 */
+ <IMX8QM_USDHC2_RESET_B_LSIO_GPIO4_IO09 0x00000021>,
+ /* GPIO5_23 on X62:24 */
+ <IMX8QM_USDHC1_STROBE_LSIO_GPIO5_IO23 0x00000021>,
+ /* GPIO5_24 on X61:15 */
+ <IMX8QM_USDHC2_CLK_LSIO_GPIO5_IO24 0x00000021>,
+ /* GPIO5_25 on X61:17 */
+ <IMX8QM_USDHC2_CMD_LSIO_GPIO5_IO25 0x00000021>,
+ /* GPIO5_26 on X61:19 */
+ <IMX8QM_USDHC2_DATA0_LSIO_GPIO5_IO26 0x00000021>,
+ /* GPIO5_27 on X61:21 */
+ <IMX8QM_USDHC2_DATA1_LSIO_GPIO5_IO27 0x00000021>,
+ /* GPIO5_28 on X61:23 */
+ <IMX8QM_USDHC2_DATA2_LSIO_GPIO5_IO28 0x00000021>,
+ /* GPIO5_29 on X61:25 */
+ <IMX8QM_USDHC2_DATA3_LSIO_GPIO5_IO29 0x00000021>;
+ };
+
+ pinctrl_gpiokeys: gpiokeysgrp {
+ fsl,pins = <IMX8QM_ESAI1_TX3_RX2_LSIO_GPIO2_IO11 0x00000021>,
+ <IMX8QM_SCU_GPIO0_04_LSIO_GPIO1_IO00 0x00000021>;
+ };
+
+ pinctrl_gpioled: gpioledgrp {
+ fsl,pins = <IMX8QM_USDHC1_DATA4_LSIO_GPIO5_IO19 0x00000021>,
+ <IMX8QM_USDHC1_DATA5_LSIO_GPIO5_IO20 0x00000021>;
+ };
+
+ pinctrl_lpspi0_cs: lpspi0csgrp {
+ fsl,pins = <IMX8QM_SPI0_CS0_LSIO_GPIO3_IO05 0x00000021>,
+ <IMX8QM_SPI0_CS1_LSIO_GPIO3_IO06 0x00000021>;
+ };
+
+ pinctrl_lpspi0: lpspi0grp {
+ fsl,pins = <IMX8QM_SPI0_SCK_DMA_SPI0_SCK 0x0600004d>,
+ <IMX8QM_SPI0_SDO_DMA_SPI0_SDO 0x0600004d>,
+ <IMX8QM_SPI0_SDI_DMA_SPI0_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi1_cs: lpspi1csgrp {
+ fsl,pins = <IMX8QM_ADC_IN6_LSIO_GPIO3_IO24 0x00000021>,
+ <IMX8QM_ADC_IN7_LSIO_GPIO3_IO25 0x00000021>;
+ };
+
+ pinctrl_lpspi1: lpspi1grp {
+ fsl,pins = <IMX8QM_ADC_IN3_DMA_SPI1_SCK 0x0600004d>,
+ <IMX8QM_ADC_IN4_DMA_SPI1_SDO 0x0600004d>,
+ <IMX8QM_ADC_IN5_DMA_SPI1_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi2: lpspi2grp {
+ fsl,pins = <IMX8QM_SPI2_SCK_DMA_SPI2_SCK 0x0600004d>,
+ <IMX8QM_SPI2_SDO_DMA_SPI2_SDO 0x0600004d>,
+ <IMX8QM_SPI2_SDI_DMA_SPI2_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi2_cs: lpspi2sgrp {
+ fsl,pins = <IMX8QM_SPI2_CS0_LSIO_GPIO3_IO10 0x00000021>,
+ <IMX8QM_SPI2_CS1_LSIO_GPIO3_IO11 0x00000021>;
+ };
+
+ pinctrl_lpuart0: lpuart0grp {
+ fsl,pins = <IMX8QM_UART0_RX_DMA_UART0_RX 0x06000021>,
+ <IMX8QM_UART0_TX_DMA_UART0_TX 0x06000021>,
+ <IMX8QM_UART0_CTS_B_DMA_UART0_CTS_B 0x00000021>,
+ <IMX8QM_UART0_RTS_B_DMA_UART0_RTS_B 0x00000021>;
+ };
+
+ pinctrl_lpuart1: lpuart1grp {
+ fsl,pins = <IMX8QM_UART1_RX_DMA_UART1_RX 0x06000021>,
+ <IMX8QM_UART1_TX_DMA_UART1_TX 0x06000021>,
+ <IMX8QM_UART1_CTS_B_DMA_UART1_CTS_B 0x00000021>,
+ <IMX8QM_UART1_RTS_B_DMA_UART1_RTS_B 0x00000021>;
+ };
+
+ pinctrl_lpuart2: lpuart2grp {
+ fsl,pins = <IMX8QM_LVDS0_I2C1_SDA_DMA_UART2_RX 0x06000021>,
+ <IMX8QM_LVDS0_I2C1_SCL_DMA_UART2_TX 0x06000021>;
+ };
+
+ pinctrl_lsio_pwm3: lsiopwm3grp {
+ fsl,pins = <IMX8QM_GPT0_COMPARE_LSIO_PWM3_OUT 0x00000021>;
+ };
+
+ pinctrl_pciea: pcieagrp {
+ fsl,pins = <IMX8QM_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO29 0x06000021>,
+ <IMX8QM_PCIE_CTRL0_CLKREQ_B_HSIO_PCIE0_CLKREQ_B 0x06000021>,
+ <IMX8QM_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO28 0x04000021>;
+ };
+
+ pinctrl_pcieb: pciebgrp {
+ fsl,pins = <IMX8QM_PCIE_CTRL1_PERST_B_LSIO_GPIO5_IO00 0x06000021>,
+ <IMX8QM_PCIE_CTRL1_CLKREQ_B_HSIO_PCIE1_CLKREQ_B 0x06000021>,
+ <IMX8QM_PCIE_CTRL1_WAKE_B_LSIO_GPIO4_IO31 0x04000021>;
+ };
+
+ pinctrl_pwmfan: pwmfangrp {
+ fsl,pins = <IMX8QM_SPI3_CS0_LSIO_GPIO2_IO20 0x30>;
+ };
+
+ pinctrl_reg_mba8x_12v: regmba12vgrp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_06_LSIO_GPIO1_IO02 0x00000021>;
+ };
+
+ pinctrl_reg_pcie_v1v5: regpcie1v5grp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31 0x00000021>;
+ };
+
+ pinctrl_reg_pcie_v3v3: regpcie3v3grp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_05_LSIO_GPIO1_IO01 0x00000021>;
+ };
+
+ pinctrl_regpwmfan: regpwmfangrp {
+ fsl,pins = <IMX8QM_ESAI1_TX4_RX1_LSIO_GPIO2_IO12 0x00000021>;
+ };
+
+ pinctrl_reg_v3v3_sd: regv3v3sdgrp {
+ fsl,pins = <IMX8QM_USDHC1_RESET_B_LSIO_GPIO4_IO07 0x00000021>;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <IMX8QM_SAI1_RXD_AUD_SAI1_RXD 0x06000041>,
+ <IMX8QM_SAI1_RXC_AUD_SAI1_RXC 0x06000041>,
+ <IMX8QM_SAI1_RXFS_AUD_SAI1_RXFS 0x06000041>,
+ <IMX8QM_SAI1_TXD_AUD_SAI1_TXD 0x06000061>,
+ <IMX8QM_SAI1_TXC_AUD_SAI1_TXC 0x06000041>,
+ <IMX8QM_MCLK_OUT0_AUD_ACM_MCLK_OUT0 0x0600004d>;
+ };
+
+ pinctrl_usbhub: usbhubgrp {
+ fsl,pins = <IMX8QM_ESAI1_SCKT_LSIO_GPIO2_IO07 0x00000021>;
+ };
+
+ pinctrl_usbotg1: usbotg1grp {
+ fsl,pins = <IMX8QM_USB_SS3_TC2_CONN_USB_OTG1_OC 0x00000021>,
+ <IMX8QM_USB_SS3_TC0_CONN_USB_OTG1_PWR 0x00000021>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <IMX8QM_USDHC1_DATA6_LSIO_GPIO5_IO21 0x00000021>,
+ <IMX8QM_USDHC1_DATA7_LSIO_GPIO5_IO22 0x00000021>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
new file mode 100644
index 0000000000000..d94605c999915
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2019-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+#include <dt-bindings/firmware/imx/rsrc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/thermal/thermal.h>
+
+#include "imx8qm.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8QM TQMa8QM";
+ compatible = "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+
+ memory@80000000 {
+ device_type = "memory";
+ /*
+ * DRAM base addr, size : 1024 MiB DRAM
+ * should be corrected by bootloader
+ */
+ reg = <0x00000000 0x80000000 0 0x40000000>;
+ };
+
+ reg_tqma8x_v3v3: regulator-tqma8x-v3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ /* SW7 controlled by SCU */
+ reg_1v8_io1: regulator-v1v8-io1 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_1V8_IO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ /* LDO4 controlled by SCU */
+ reg_3v3_emmc: regulator-v3v3-emmc {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3_EMMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&acm {
+ status = "okay";
+};
+
+&adc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0>;
+ vref-supply = <®_vref_v1v8>;
+ status = "okay";
+};
+
+/* TQMa8QM only uses industrial grade, reduce trip points accordingly */
+&cpu_alert0 {
+ temperature = <95000>;
+};
+
+&cpu_crit0 {
+ temperature = <100000>;
+};
+
+&cpu_alert1 {
+ temperature = <95000>;
+};
+
+&cpu_crit1 {
+ temperature = <100000>;
+};
+
+&gpu_alert0 {
+ temperature = <95000>;
+};
+
+&gpu_crit0 {
+ temperature = <100000>;
+};
+
+&gpu_alert1 {
+ temperature = <95000>;
+};
+
+&gpu_crit1 {
+ temperature = <100000>;
+};
+
+&drc_alert0 {
+ temperature = <95000>;
+};
+
+&drc_crit0 {
+ temperature = <100000>;
+};
+/* end of temperature grade adjustments */
+
+&flexspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ status = "okay";
+
+ flash0: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <66000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <®_1v8_io1>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1gpio>;
+ scl-gpios = <&lsio_gpio0 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio0 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ se97: temperature-sensor@1b {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x1b>;
+ };
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ };
+
+ at24c02: eeprom@53 {
+ compatible = "nxp,se97b", "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ read-only;
+ vcc-supply = <®_tqma8x_v3v3>;
+ };
+
+ m24c64: eeprom@57 {
+ compatible = "atmel,24c64";
+ reg = <0x57>;
+ pagesize = <32>;
+ vcc-supply = <®_tqma8x_v3v3>;
+ };
+};
+
+&mu_m0 {
+ status = "okay";
+};
+
+&mu1_m0 {
+ status = "okay";
+};
+
+&mu2_m0 {
+ status = "okay";
+};
+
+&thermal_zones {
+ pmic0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+
+ trips {
+ pmic_alert0: trip0 {
+ temperature = <110000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ pmic_crit0: trip1 {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&pmic_alert0>;
+ cooling-device =
+ <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A72_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A72_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ vmmc-supply = <®_3v3_emmc>;
+ vqmmc-supply = <®_1v8_io1>;
+ no-sd;
+ no-sdio;
+ non-removable;
+ status = "okay";
+};
+
+&vpu {
+ compatible = "nxp,imx8qm-vpu";
+ status = "okay";
+};
+
+&vpu_core0 {
+ memory-region = <&decoder_boot>, <&decoder_rpc>;
+ status = "okay";
+};
+
+&vpu_core1 {
+ memory-region = <&encoder1_boot>, <&encoder1_rpc>;
+ status = "okay";
+};
+
+&vpu_core2 {
+ memory-region = <&encoder2_boot>, <&encoder2_rpc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <IMX8QM_GPT0_CAPTURE_DMA_I2C1_SDA 0x0600004d>,
+ <IMX8QM_GPT0_CLK_DMA_I2C1_SCL 0x0600004d>;
+ };
+
+ pinctrl_lpi2c1gpio: lpi2c1gpiogrp {
+ fsl,pins = <IMX8QM_GPT0_CAPTURE_LSIO_GPIO0_IO15 0x0600004d>,
+ <IMX8QM_GPT0_CLK_LSIO_GPIO0_IO14 0x0600004d>;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000040>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000040>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <IMX8QM_QSPI0A_DATA0_LSIO_QSPI0A_DATA0 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA1_LSIO_QSPI0A_DATA1 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA2_LSIO_QSPI0A_DATA2 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA3_LSIO_QSPI0A_DATA3 0x0000004d>,
+ <IMX8QM_QSPI0A_DQS_LSIO_QSPI0A_DQS 0x0000004d>,
+ <IMX8QM_QSPI0A_SS0_B_LSIO_QSPI0A_SS0_B 0x0000004d>,
+ <IMX8QM_QSPI0A_SS1_B_LSIO_QSPI0A_SS1_B 0x0000004d>,
+ <IMX8QM_QSPI0A_SCLK_LSIO_QSPI0A_SCLK 0x0000004d>,
+ <IMX8QM_QSPI0B_SCLK_LSIO_QSPI0B_SCLK 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA0_LSIO_QSPI0B_DATA0 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA1_LSIO_QSPI0B_DATA1 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA2_LSIO_QSPI0B_DATA2 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA3_LSIO_QSPI0B_DATA3 0x0000004d>,
+ <IMX8QM_QSPI0B_DQS_LSIO_QSPI0B_DQS 0x0000004d>,
+ <IMX8QM_QSPI0B_SS0_B_LSIO_QSPI0B_SS0_B 0x0000004d>,
+ <IMX8QM_QSPI0B_SS1_B_LSIO_QSPI0B_SS1_B 0x0000004d>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-26 13:07 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <3979783.tdWV9SEqCh@workhorse>
On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > +enum drm_connector_color_format {
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > + * semantics.
> > > > > > > + *
> > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > + * YCbCr 4:2:0.
> > > > > > > + *
> > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > + * how HDMI does it).
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > + * not subsampled)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > + * with horizontal subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > >
> > > > > > Seems like this should document what the quantization range
> > > > > > should be for each format.
> > > > > >
> > > > >
> > > > > I don't think so? If you want per-component bit depth values,
> > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > enum is more abstract than that, and is there to communicate
> > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > by other properties.
> > > > >
> > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > be added; no digital display protocol standard supports it to my
> > > > > knowledge, and hopefully none ever will.
> > > >
> > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > >
> > > > The i915 behaviour is that YCbCr is always limited range,
> > > > RGB can either be full or limited range depending on the
> > > > "Broadcast RGB" property and other related factors.
> > >
> > > So far the HDMI state has both the format and quantization range as
> > > different fields. I'm not sure we need to document the range in the
> > > format field, maybe only mention it's not part of the format but has a
> > > field of its own?
> >
> > I think we only have it for RGB (on some drivers only?). For YCbCr
> > I think the assumption is limited range everywhere.
> >
> > But I'm not really concerned about documenting struct members.
> > What I'm talking about is the *uapi* docs. Surely userspace
> > will want to know what the new property actually does so the
> > uapi needs to be documented properly. And down the line some
> > new driver might also implement the wrong behaviour if there
> > is no clear specification.
> >
> > So I'm thinking (or perhaps hoping) the rule might be something like:
> > - YCbCr limited range
> > - RGB full range if "Broadcast RGB" property is not present
> > - RGB full or limited range based on the "Broadcast RGB" property
> > if it's present
> >
> > I think the "Broadcast RGB" property itself might also be lacking
> > proper uapi docs, so that may need to be remedied as well.
> >
> >
>
> Alright, so in v12 I'll do the following:
>
> - Add a line to all YCBCR connector formats that specifies they're
> limited range as long as Broadcast RGB is limited. Whether it's limited
> range when Broadcast RGB is full is purposefully left undefined.
"Broadcast RGB", as the name implies, only affects RGB output.
> In the future, we can expand this to state they're limited range by
> default unless some other property is set. If we're not re-using
> Broadcast RGB for that, this will work out fine, because users who
> don't know about the eventual new property won't have this behaviour
> changed. If we do re-use "Broadcast RGB" for that, then only users
> relying on things we explicitly left undefined will get surprise
> full range YCBCR.
> - Add a line to the RGB connector format that specifies its range
> depends on the "Broadcast RGB" property
>
> This is a bit of a mess, because it's entirely reasonable that a
> future YCBCR range property would want to default to full range
> so that users get the most color out of their monitors. But with
> this description of the connector color formats, we can't do that.
>
> If there are alternate suggestions, I'm open for them. We can't
> really rename "Broadcast RGB" but if I had a time machine, that'd
> be my first choice.
>
> Kind regards,
> Nicolas Frattaroli
>
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:08 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
[4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
[6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] clocksource/drivers/timer-mediatek: initialize GPT6 as system counter
From: Akari Tsuyukusa @ 2026-03-26 13:08 UTC (permalink / raw)
To: rva333
Cc: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260326-archtimer-v1-1-5328574e5935@protonmail.com>
On Thu, Mar 26, 2026 at 10:00 AM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
> On certain MediaTek SoCs like mt6572 (likely before the CPUXGPT was
> introduced), the generic arch timer is fed by the GPT6. Some bootloaders
> don't initialize it properly, leading to dead arch timer.
>
> Fix this by configuring GPT6 when the MediaTek timer is probed. This
> makes arch timer work properly and removes IPI overhead from MediaTek
> timer broadcast when arch timer is used.
>
> If the timer was configured by the bootloader, this change is no-op.
>
> Tested-by: Akari Tsuyukusa <akkun11.open@gmail.com> # MT6589
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/clocksource/timer-mediatek.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 7bcb4a3f26fb..7de34cace572 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -22,6 +22,8 @@
>
> #define TIMER_SYNC_TICKS (3)
>
> +#define TIMER_SYSCNT (6)
> +
> /* gpt */
> #define GPT_IRQ_EN_REG 0x00
> #define GPT_IRQ_ENABLE(val) BIT((val) - 1)
> @@ -335,6 +337,9 @@ static int __init mtk_gpt_init(struct device_node *node)
>
> mtk_gpt_enable_irq(&to, TIMER_CLK_EVT);
>
> + /* Configure GPT6 to feed arch timer */
> + mtk_gpt_setup(&to, TIMER_SYSCNT, GPT_CTRL_OP_FREERUN);
> +
> return 0;
> }
> TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
>
> ---
Although it has already been written,
I tested this patch on MT6589 (Lenovo YOGA Tablet 10 Wi-Fi),
and I have confirmed that MediaTek's timer and Arm Generic Timer are
working properly as before the patch was applied.
Therefore,
Tested-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Best regards,
Akari Tsuyukusa
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <177453048347.439230.1647215482099213609.b4-ty@linaro.org>
On 3/26/26 14:08, Neil Armstrong wrote:
> Hi,
>
> On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
>> This patch series depends on Jian's SCMI clock patches yet to merge
>> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>>
>> This series adds device tree support for the MMC, SD card and SDIO
>> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>>
>> The first patches add the necessary building blocks in the T7 SoC
>> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
>> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
>> strings are introduced with fallbacks to existing drivers, avoiding
>> the need for new driver code.
>>
>> [...]
>
> Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
>
> [1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
> https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
> [4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
> https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
> [6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
> https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
I'll pick patch 3,5,7 & 9 once patches 1 & 2 from [1] are merged.
[1] https://lore.kernel.org/all/20260326092645.1053261-1-jian.hu@amlogic.com/
Thanks,
Neil
>
> These changes has been applied on the intermediate git tree [1].
>
> The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
> for inclusion in their intermediate git branches in order to be sent to Linus during
> the next merge window, or sooner if it's a set of fixes.
>
> In the cases of fixes, those will be merged in the current release candidate
> kernel and as soon they appear on the Linux master branch they will be
> backported to the previous Stable and Long-Stable kernels [2].
>
> The intermediate git branches are merged daily in the linux-next tree [3],
> people are encouraged testing these pre-release kernels and report issues on the
> relevant mailing-lists.
>
> If problems are discovered on those changes, please submit a signed-off-by revert
> patch followed by a corrective changeset.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-26 13:14 UTC (permalink / raw)
To: cw00.choi, myungjoo.ham, kyungmin.park, tianyaxiong
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260326123428.800407-1-zhanjie9@hisilicon.com>
On 3/26/2026 8:34 PM, Jie Zhan wrote:
> When compiled as a kernel module, the governor module can be dynamically
> inserted or removed. 'devfreq->governor' would become NULL if the governor
> module is removed when it's in use, and NULL pointer dereference would be
> triggered. A similar issue was also reported in [1].
>
> To address this issue:
>
> Patch 1-5 rework mutex, factor out a common governor setting function, and
> clean up some unreachable code.
>
> Patch 6-8 prevent a governor module in use from being removed (except for
> force unload) by getting/putting a refcount of the governor's module when
> switching governors.
>
> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
> when a governor module in use is force unloaded.
>
> Note that this series is based on [1] or devfreq-next, otherwise code
sorry, based on [2] or devfreq-next
> would conflict.
>
> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH V2 4/5] dt-bindings: dma: xlnx,axi-dma: Add "xlnx,include-stscntrl-strm" property
From: Rob Herring (Arm) @ 2026-03-26 13:22 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Radhey Shyam Pandey, Michal Simek, Frank Li, devicetree, git,
Conor Dooley, Vinod Koul, Tomi Valkeinen, Suraj Gupta,
Abin Joseph, Thomas Gessler, Folker Schwesinger, linux-kernel,
Krzysztof Kozlowski, linux-arm-kernel, dmaengine, Kees Cook
In-Reply-To: <20260313062533.421249-5-srinivas.neeli@amd.com>
On Fri, 13 Mar 2026 11:55:32 +0530, Srinivas Neeli wrote:
> Add an optional boolean DT property "xlnx,include-stscntrl-strm" to
> indicate that the AXI DMA IP is configured with the AXI4-Stream status
> and control interface. This enables the use of APP fields in DMA
> descriptors for metadata reporting.
>
> This property is distinct from "xlnx,axistream-connected" and serves a
> different purpose:
>
> - "xlnx,include-stscntrl-strm": Indicates whether APP fields are present
> in DMA descriptors. When enabled, the driver can access status/control
> metadata through these descriptor fields.
>
> - "xlnx,axistream-connected": Indicates whether a streaming IP (client)
> is connected to the DMA IP.
>
> These two configurations are independent of each other. For example, in
> TSN (Time-Sensitive Networking) designs, a streaming client may be
> connected to the DMA IP, but the status/control stream interface is not
> enabled. In such cases, "xlnx,axistream-connected" would be present while
> "xlnx,include-stscntrl-strm" would be absent.
>
> Adding this property allows the driver to correctly determine descriptor
> layout and access APP fields only when the hardware supports them.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> .../devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: hejunhao @ 2026-03-26 13:26 UTC (permalink / raw)
To: Shuai Xue, Rafael J. Wysocki, Luck, Tony
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Linuxarm, Junhao He
In-Reply-To: <96f505ac-dc5e-45df-8641-deabb973b5f3@linux.alibaba.com>
On 2026/3/25 20:40, Shuai Xue wrote:
>
>
> On 3/25/26 5:24 PM, hejunhao wrote:
>>
>>
>> On 2026/3/25 10:12, Shuai Xue wrote:
>>> Hi, junhao
>>>
>>> On 3/24/26 6:04 PM, hejunhao wrote:
>>>> Hi shuai xue,
>>>>
>>>>
>>>> On 2026/3/3 22:42, Shuai Xue wrote:
>>>>> Hi, junhao,
>>>>>
>>>>> On 2/27/26 8:12 PM, hejunhao wrote:
>>>>>>
>>>>>>
>>>>>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>>>>>
>>>>>>>
>>>>>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>>>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>>>>>
>>>>>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>>>>>> error will be reprocessed.
>>>>>>>>>
>>>>>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>>>>>> memory corruption. If the same SEA error appears multiple times
>>>>>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>>>>>> return a failure when encountering the same error again, and then proceed
>>>>>>>>> to arm64_do_kernel_sea for further processing.
>>>>>
>>>>> There is no such function in the arm64 tree. If apei_claim_sea() returns
>>>>
>>>> Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
>>>> be arm64_notify_die().
>>>>
>>>>> an error, the actual fallback path in do_sea() is arm64_notify_die(),
>>>>> which sends SIGBUS?
>>>>>
>>>>
>>>> If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
>>>> followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
>>>
>>> So the process is expected to killed by SIGBUS?
>>
>> Yes. The devmem process is expected to terminate upon receiving a SIGBUS signal, you can
>> see this at the last line of the test log after the patch is applied.
>> For other processes whether it terminates depends on whether it catches the signal; the kernel is
>> responsible for sending it immediately.
>>
>>>
>>>>
>>>>>>>>>
>>>>>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>>>>>> the SEA error exception handler. All such handlers will call
>>>>>>>>> memory_failure() to handle the faulty page.
>>>>>>>>>
>>>>>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>>>>>
>>>>>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>>>>>> scenario occurs:
>>>>>>>>>
>>>>>>>>> When a user process directly requests and accesses a page with hardware
>>>>>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>>>>>> However, since the process does not request the page through the kernel's
>>>>>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>>>>>> result, these processes continues to access the faulty page, causing
>>>>>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>>>>>> an SEA error interrupt storm.
>>>>>
>>>>> In such case, the user process which accessing the poisoned page will be killed
>>>>> by memory_fauilre?
>>>>>
>>>>> // memory_failure():
>>>>>
>>>>> if (TestSetPageHWPoison(p)) {
>>>>> res = -EHWPOISON;
>>>>> if (flags & MF_ACTION_REQUIRED)
>>>>> res = kill_accessing_process(current, pfn, flags);
>>>>> if (flags & MF_COUNT_INCREASED)
>>>>> put_page(p);
>>>>> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>>>>> goto unlock_mutex;
>>>>> }
>>>>>
>>>>> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
>>>>> fix infinite UCE for VM_PFNMAP pfn").
>>>>>
>>>>> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
>>>>> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
>>>>> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
>>>>> the UCE was handled properly while the process was never actually killed.
>>>>>
>>>>> Did you try the lastest kernel version?
>>>>>
>>>>
>>>> I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
>>>>
>>>>
>>>> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>>>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>>>
>>>> /* This error has been reported before, don't process it again. */
>>>> - if (ghes_estatus_cached(estatus))
>>>> + if (ghes_estatus_cached(estatus)) {
>>>> + pr_info("This error has been reported before, don't process it again.\n");
>>>> goto no_work;
>>>> + }
>>>>
>>>> the test log Only some debug logs are retained here.
>>>>
>>>> [2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
>>>> [2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
>>>> [2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>> [2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
>>>> [2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
>>>> [2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
>>>> [2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
>>>> [2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>> [2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
>>>> [2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
>>>> [2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
>>>> [2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
>>>> [2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
>>>> [2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
>>>> [2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
>>>> [2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
>>>> [2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
>>>> [2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
>>>> [2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>> [2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
>>>> [2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
>>>> [2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>> [2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
>>>> [2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
>>>> [2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
>>>> [2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
>>>> [2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>> [2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
>>>> [2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
>>>> [2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
>>>> [2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
>>>> [2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
>>>> [2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
>>>> [2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
>>>> [2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
>>>> [2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
>>>> [2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
>>>> [2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>> [2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>> [2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
>>>> [2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
>>>
>>> Did you cut off some logs here?
>>
>> I just removed some duplicate debug logs: "This error has already been...", these were added by myself.
Hi, Shuai
Compared to the original commit message and the logs reproducing this issue
on kernel v7.0.0-rc4, perhaps you are asking whether the current log is missing
information such as 'NOTICE: SEA Handle'?
These miss logs are from the firmware. To reduce serial output, the firmware has
hidden these debug prints. However, using my own custom debug logs, I can
still see that the kernel's do_sea() process is continuously running during the
10-second cache timeout. Although only one debug log is retained per second.
This confirms that the issue is still present on the latest kernel v7.0.0-rc4.
>>> The error log also indicates that the SIGBUS is delivered as expected.
>>
>> An SError occurs at kernel time 130.558038. Then, after 10 seconds, the kernel
>> can re-enter the SEA processing flow and send the SIGBUS signal to the process.
>> This 10-second delay corresponds to the cache timeout threshold of the
>> ghes_estatus_cached() feature.
>> Therefore, the purpose of this patch is to send the SIGBUS signal to the process
>> immediately, rather than waiting for the timeout to expire.
>
> Hi, hejun,
>
> Sorry, but I am still not convinced by the log you provided.
>
> As I understand your commit message, there are two different cases being discussed:
>
> Case 1: memory error interrupt first, then SEA
>
> When hardware memory corruption occurs, a memory error interrupt is
> triggered first. If the kernel later accesses the corrupted data, it may
> then enter the SEA handler. In this case, the faulty page would already
> have been marked poisoned by the memory error interrupt path, and the SEA
> handling path would eventually send SIGBUS to the task accessing that page.
>
> Case 2: SEA first, then memory error interrupt
>
> Your commit message describes this as the problematic scenario:
>
> A user process directly accesses hardware-corrupted memory through a
> PFNMAP-style mapping such as devmem. The page may still be in the free
> buddy state when SEA is handled first. In that case, memory_failure()
> poisons the page during SEA handling, but the process is not killed
> immediately. Since the task continues accessing the same corrupted
> location, it keeps re-entering the SEA handler, leading to an SEA storm.
> Later, the memory error interrupt path also cannot kill the task, so the
> system remains stuck in this repeated SEA loop.
Yes.
>
> My concern is that your recent explanation and log seem to demonstrate
> something different from what the commit message claims to fix.
>
> From the log, what I can see is:
>
> the first SEA occurs,
> the page is marked poisoned as a free buddy page,
> repeated SEAs are suppressed by ghes_estatus_cached(),
> after the cache timeout expires, the SEA path runs again,
> then memory_failure() reports "already hardware poisoned" and SIGBUS is
> sent to the busybox devmem process.
> This seems to show a delayed SIGBUS delivery caused by the GHES cache
> timeout, rather than clearly demonstrating the SEA storm problem described
> in the commit message.
>
> So I think there is still a mismatch here:
>
> If the patch is intended to fix the SEA storm described in case 2,
> then I would expect evidence that the storm still exists on the latest
> kernel and that this patch is what actually breaks that loop.
> If instead the patch is intended to avoid the 10-second delay before
> SIGBUS delivery, then that should be stated explicitly, because that is
> a different problem statement from what the current commit message says.
> Also, regarding the devmem/PFNMAP case: I previously pointed to commit
> 2e6053fea379 ("mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn"),
> which was meant to address the failure to kill tasks accessing poisoned
> VM_PFNMAP mappings.
>
This patch was already merged prior to kernel v7.0.0-rc4, therefore, it cannot fix this issue.
I reverted the patch on kernel v7.0.0-rc4 to reproduce the issue.
The debug logs show that the message 'This error has already been...' persists
for more than 10 seconds, and the printing cannot be stopped. so it fixes other issue.
> So my main question is:
>
> Does the SEA storm issue still exist on the latest kernel version, or is
> the remaining issue only that SIGBUS is delayed by the GHES estatus cache
> timeout?
We should not treat them separately.
In case 2, First SEA can only poisons the page, and then re-enter the SEA processing flow.
Due to the reporting throttle of the ghes_estatus_cached(), SEA cannot timely invoke
memory_failure() to kill the task, the task will continues accessing the same corrupted
location, then re-enter the SEA processing flow loop, so causing the SEA storm...
Perhaps I never clearly explained why the SEA storm occurred.
Best regards,
Junhao.
>
> I think the answer to that question is important before deciding whether
> this patch is correct, and before finalizing the commit message.
>
> Thanks,
> Shuai
>
> .
>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-26 13:26 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acUvg3Y7kMf2qioK@intel.com>
On Thursday, 26 March 2026 14:07:15 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > +enum drm_connector_color_format {
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > + * semantics.
> > > > > > > > + *
> > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > + *
> > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > + * how HDMI does it).
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > + * not subsampled)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > + * with horizontal subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > +
> > > > > > > > + /**
> > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > + */
> > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > >
> > > > > > > Seems like this should document what the quantization range
> > > > > > > should be for each format.
> > > > > > >
> > > > > >
> > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > enum is more abstract than that, and is there to communicate
> > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > by other properties.
> > > > > >
> > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > be added; no digital display protocol standard supports it to my
> > > > > > knowledge, and hopefully none ever will.
> > > > >
> > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > >
> > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > RGB can either be full or limited range depending on the
> > > > > "Broadcast RGB" property and other related factors.
> > > >
> > > > So far the HDMI state has both the format and quantization range as
> > > > different fields. I'm not sure we need to document the range in the
> > > > format field, maybe only mention it's not part of the format but has a
> > > > field of its own?
> > >
> > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > I think the assumption is limited range everywhere.
> > >
> > > But I'm not really concerned about documenting struct members.
> > > What I'm talking about is the *uapi* docs. Surely userspace
> > > will want to know what the new property actually does so the
> > > uapi needs to be documented properly. And down the line some
> > > new driver might also implement the wrong behaviour if there
> > > is no clear specification.
> > >
> > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > - YCbCr limited range
> > > - RGB full range if "Broadcast RGB" property is not present
> > > - RGB full or limited range based on the "Broadcast RGB" property
> > > if it's present
> > >
> > > I think the "Broadcast RGB" property itself might also be lacking
> > > proper uapi docs, so that may need to be remedied as well.
> > >
> > >
> >
> > Alright, so in v12 I'll do the following:
> >
> > - Add a line to all YCBCR connector formats that specifies they're
> > limited range as long as Broadcast RGB is limited. Whether it's limited
> > range when Broadcast RGB is full is purposefully left undefined.
>
> "Broadcast RGB", as the name implies, only affects RGB output.
Alright, I'll scratch the overcomplicated undefined behaviour thing
and just say it's limited range, and in the future, we can extend it
to limited range by default but full range if another new property is
set.
>
> > In the future, we can expand this to state they're limited range by
> > default unless some other property is set. If we're not re-using
> > Broadcast RGB for that, this will work out fine, because users who
> > don't know about the eventual new property won't have this behaviour
> > changed. If we do re-use "Broadcast RGB" for that, then only users
> > relying on things we explicitly left undefined will get surprise
> > full range YCBCR.
> > - Add a line to the RGB connector format that specifies its range
> > depends on the "Broadcast RGB" property
> >
> > This is a bit of a mess, because it's entirely reasonable that a
> > future YCBCR range property would want to default to full range
> > so that users get the most color out of their monitors. But with
> > this description of the connector color formats, we can't do that.
> >
> > If there are alternate suggestions, I'm open for them. We can't
> > really rename "Broadcast RGB" but if I had a time machine, that'd
> > be my first choice.
> >
> > Kind regards,
> > Nicolas Frattaroli
> >
>
>
^ permalink raw reply
* [GIT PULL] Qualcomm driver fixes for v7.0
From: Bjorn Andersson @ 2026-03-26 13:31 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Konrad Dybcio,
Mukesh Ojha
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-fixes-for-7.0
for you to fetch changes up to a343fb1e03cfc9f6dc83a5efb2a8d33e9cdaf6b9:
soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition (2026-03-18 21:51:11 -0500)
----------------------------------------------------------------
Qualcomm driver fixes for v7.0
Fix the length of the PD restart reason string in pd-mapper to avoid
QMI decoding errors, resulting in the notification being dropped.
Fix the newly introduce handling of TBT/USB4 notifications in pmic_glink
altmode driver, as it broke the handling of non-TBT/USB4 DisplayPort
unplug events.
----------------------------------------------------------------
Konrad Dybcio (2):
soc: qcom: pmic_glink_altmode: Fix SVID=DP && unconnected edge case
soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition
Mukesh Ojha (1):
soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei
drivers/soc/qcom/pdr_internal.h | 2 +-
drivers/soc/qcom/pmic_glink_altmode.c | 39 +++++++++++++++++++++++++----------
drivers/soc/qcom/qcom_pdr_msg.c | 2 +-
include/linux/soc/qcom/pdr.h | 1 +
4 files changed, 31 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 05/17] firmware: arm_scmi: Add Telemetry protocol support
From: Cristian Marussi @ 2026-03-26 13:32 UTC (permalink / raw)
To: Elif Topuz
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, lukasz.luba,
philip.radford, souvik.chakravarty
In-Reply-To: <02534a48-6795-4948-9348-fe507e8810fd@arm.com>
On Fri, Jan 23, 2026 at 11:00:46AM +0000, Elif Topuz wrote:
>
> Hi Cristian,
HI Elif,
a long overdue reply from me !
Thanks for having a look at this series...
>
> On 14/01/2026 11:46, Cristian Marussi wrote:
> > Add basic support for SCMI V4.0 Telemetry protocol including SHMTI,
> > FastChannels, Notifications and Single Sample Reads collection methods.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > v1 --> v2
> > - Add proper ioread accessors for TDCF areas
> > - Rework resource allocation logic and lifecycle
> > - Introduce new resources accessors and res_get() operation to
> > implement lazy enumeration
> > - Support boot-on telemetry:
> > + Add DE_ENABLED_LIST cmd support
> > + Add CONFIG_GET cmd support
> > + Add TDCF_SCAN for best effort enumeration
> > + Harden driver against out-of-spec FW with out of spec cmds
> > - Use FCs list
> > - Rework de_info_lookup to a moer general de_lookup
> > - Fixed reset to use CONFIG_GET and DE_ENABLED_LIST to gather initial
> > state
> > - Using sign_extend32 helper
> > - Added counted_by marker where appropriate
> > ---
> > drivers/firmware/arm_scmi/Makefile | 2 +-
> > drivers/firmware/arm_scmi/driver.c | 2 +
> > drivers/firmware/arm_scmi/protocols.h | 1 +
> > drivers/firmware/arm_scmi/telemetry.c | 2671 +++++++++++++++++++++++++
> > include/linux/scmi_protocol.h | 188 +-
> > 5 files changed, 2862 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/firmware/arm_scmi/telemetry.c
> >
[snip]
> > + /* Build composing DES string */
> > + for (int i = 0; i < ti->info.base.num_groups; i++) {
> > + struct scmi_telemetry_group *grp = &rinfo->grps[i];
> > + size_t bufsize = grp->info->num_des * 11 + 1;
> > + char *buf = grp->des_str;
> > +
> > + for (int j = 0; j < grp->info->num_des; j++) {
> > + char term = j != (grp->info->num_des - 1) ? ' ' : '\0';
> > + int len;
> > +
> > + len = scnprintf(buf, bufsize, "0x%04X%c",
>
> I think it should be 0x%08X%c to print 8 bytes.
>
Good catch ! I will fix..
> > + rinfo->des[grp->des[j]]->info->id, term);
> > +
> > + buf += len;
> > + bufsize -= len;
> > + }
> > + }
> > +
[snip]
> > +
> > +static int scmi_telemetry_tdcf_line_parse(struct telemetry_info *ti,
> > + struct payload __iomem *payld,
> > + struct telemetry_shmti *shmti,
> > + enum scan_mode mode)
> > +{
> > + int used_qwords;
> > +
> > + used_qwords = (USE_LINE_TS(payld) && TS_VALID(payld)) ?
> > + QWORDS_TS_LINE_DATA_PAYLD : QWORDS_LINE_DATA_PAYLD;
>
> If I understand correctly from the "chat with ATG" comments below, when
> timestamp is disabled (after DE is enabled with timestamp), physically ts line
> is still there (use_line_ts = 1 and ts_valid = 0). That's why I think we need to
> drop TS_VALID(payld) check. Otherwise qwords will be QWORDS_LINE_DATA_PAYLD
> although ts line exists.
>
> Also, for the alpha version of the spec, the combination of use_line_ts = 1 and
> ts_valid = 0 doesn't seem to be possible as I understand. But I think beta
> version allows us?
Yes indeed ALPHA_0 definition of TS Line fields was ambiguos but now in
BETA the field is more explicitly called as LineExtension bit field...so
the code in the upcoming V3 will change accordingly.
>
> > +
> > + /* Invalid lines are not an error, could simply be disabled DEs */
> > + if (DATA_INVALID(payld))
> > + return used_qwords;
> > +
> > + if (!IS_BLK_TS(payld))
> > + scmi_telemetry_tdcf_data_parse(ti, payld, shmti, mode);
> > + else
> > + scmi_telemetry_tdcf_blkts_parse(ti, payld, shmti);
> > +
> > + return used_qwords;
> > +}
> > +
> > +static int scmi_telemetry_shmti_scan(struct telemetry_info *ti,
> > + unsigned int shmti_id, u64 ts,
> > + enum scan_mode mode)
>
> ts is not used in the function.
>
Yes indeed I have removed it in V3.
> > +{
> > + struct telemetry_shmti *shmti = &ti->shmti[shmti_id];
> > + struct tdcf __iomem *tdcf = shmti->base;
> > + int retries = SCMI_TLM_TDCF_MAX_RETRIES;
> > + u64 startm = 0, endm = TDCF_BAD_END_SEQ;
> > + void *eplg = SHMTI_EPLG(shmti);
> > +
> > + if (!tdcf)
> > + return -ENODEV;
> > +
[snip]
> > +
> > + de_id = le32_to_cpu(payld->id);
> > + de = xa_load(&ti->xa_des, de_id);
> > + if (!de || !de->enabled) {
> > + dev_err(ti->ph->dev,
> > + "MSG - Received INVALID DE - ID:%u enabled:%d\n",
>
> enabled:%c?
>
Yep
> > + de_id, de ? (de->enabled ? 'Y' : 'N') : 'X');
> > + continue;
[snip]
> > struct scmi_power_state_changed_report {
> > @@ -1114,4 +1292,12 @@ struct scmi_powercap_meas_changed_report {
> > unsigned int domain_id;
> > unsigned int power;
> > };
> > +
> > +struct scmi_telemetry_update_report {
> > + ktime_t timestamp;
> > + unsigned int agent_id;
> > + int status;
> > + unsigned int num_dwords;
> > + unsigned int dwords[];
> > +};
> > #endif /* _LINUX_SCMI_PROTOCOL_H */
>
> Thanks,
> Elif
Thanks for the review !
Cristian
PS: (nitpick) you should trim your review replies to remove all the long
bunch of code that you are not comenting on (leaving a [snip] placeholder
as I did above)... it helps finding your comments in the sea of code...
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: connector: add pd-disable dependency
From: Frank Li @ 2026-03-26 13:36 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, amitsd,
gregkh, kyletso, Xu Yang
Cc: devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260312071609.388047-1-xu.yang_2@nxp.com>
On Thu, 12 Mar 2026 15:16:08 +0800, Xu Yang wrote:
> When Power Delivery is not supported, the source is unable to obtain the
> current capability from the Source PDO. As a result, typec-power-opmode
> needs to be added to advertise such capability.
>
>
Applied, thanks!
[2/2] arm64: dts: freescale: imx8mp-moduline-display-106: add typec-power-opmode property
commit: 057756df6770c033eb8ebbc9b0066f6602e99b08
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [GIT PULL] Qualcomm Arm64 DeviceTree fixes for v7.0
From: Bjorn Andersson @ 2026-03-26 13:38 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Sumit Garg,
Loic Poulain, Daniel J Blueman, Ravi Hothi
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-fixes-for-7.0
for you to fetch changes up to 2c409e03fc04b5cded81b7add9ce509706c922e3:
arm64: dts: qcom: agatti: Fix IOMMU DT properties (2026-03-23 22:31:40 -0500)
----------------------------------------------------------------
Qualcomm Arm64 DeviceTree fixes for v7.0
Fix the idle exit latency numbers on Hamoa, to resolve the issue that
Linux points out that the numbers are incorrect.
Fix the WCD9370 reset polarity on QCM6490 IDP.
Correct the Monaco UART10 pinconf, to apply to the correct pins.
Add reserved-memory region for Gunyah in Monaco, as the entry in UEFI
memory map is incomplete.
Fix the iommu stream specifiers for display, GPU, and video codec as the
current values aren't accepted on systems with Gunyah.
----------------------------------------------------------------
Daniel J Blueman (1):
arm64: dts: qcom: hamoa/x1: fix idle exit latency
Loic Poulain (2):
arm64: dts: qcom: monaco: Fix UART10 pinconf
arm64: dts: qcom: monaco: Reserve full Gunyah metadata region
Ravi Hothi (1):
arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity
Sumit Garg (3):
dt-bindings: display: msm: qcm2290-mdss: Fix iommus property
dt-bindings: media: venus: Fix iommus property
arm64: dts: qcom: agatti: Fix IOMMU DT properties
.../devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 6 ++----
.../devicetree/bindings/media/qcom,qcm2290-venus.yaml | 7 ++-----
arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
arch/arm64/boot/dts/qcom/monaco.dtsi | 9 +++++++--
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 2 +-
6 files changed, 16 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Dave Stevenson @ 2026-03-26 13:39 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acUi6NEPJ0p48a3U@intel.com>
On Thu, 26 Mar 2026 at 12:13, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Mar 26, 2026 at 11:16:12AM +0000, Dave Stevenson wrote:
> > On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli
> > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > >
> > > > > Add a new general DRM property named "color format" which can be used by
> > > > > userspace to request the display driver to output a particular color
> > > > > format.
> > > > >
> > > > > Possible options are:
> > > > > - auto (setup by default, driver internally picks the color format)
> > > > > - rgb
> > > > > - ycbcr444
> > > > > - ycbcr422
> > > > > - ycbcr420
> > > > >
> > > > > Drivers should advertise from this list which formats they support.
> > > > > Together with this list and EDID data from the sink we should be able
> > > > > to relay a list of usable color formats to users to pick from.
> > > > >
> > > > > Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
> > > > > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > > > > Co-developed-by: Andri Yngvason <andri@yngvason.is>
> > > > > Signed-off-by: Andri Yngvason <andri@yngvason.is>
> > > > > Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
> > > > > Reviewed-by: Maxime Ripard <mripard@kernel.org>
> > > > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_helper.c | 5 ++
> > > > > drivers/gpu/drm/drm_atomic_uapi.c | 11 ++++
> > > > > drivers/gpu/drm/drm_connector.c | 108 ++++++++++++++++++++++++++++++++++++
> > > > > include/drm/drm_connector.h | 104 ++++++++++++++++++++++++++++++++++
> > > > > 4 files changed, 228 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 26953ed6b53e..b7753454b777 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > > > > if (old_connector_state->max_requested_bpc !=
> > > > > new_connector_state->max_requested_bpc)
> > > > > new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > + if (old_connector_state->color_format !=
> > > > > + new_connector_state->color_format)
> > > > > + new_crtc_state->connectors_changed = true;
> > > > > +
> > > > > }
> > > > >
> > > > > if (funcs->atomic_check)
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > index 5bd5bf6661df..dee510c85e59 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > @@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > state->privacy_screen_sw_state = val;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > state->hdmi.broadcast_rgb = val;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
> > > > > + drm_dbg_atomic(connector->dev,
> > > > > + "[CONNECTOR:%d:%s] unknown color format %llu\n",
> > > > > + connector->base.id, connector->name, val);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + state->color_format = val;
> > > > > } else if (connector->funcs->atomic_set_property) {
> > > > > return connector->funcs->atomic_set_property(connector,
> > > > > state, property, val);
> > > > > @@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> > > > > *val = state->privacy_screen_sw_state;
> > > > > } else if (property == connector->broadcast_rgb_property) {
> > > > > *val = state->hdmi.broadcast_rgb;
> > > > > + } else if (property == connector->color_format_property) {
> > > > > + *val = state->color_format;
> > > > > } else if (connector->funcs->atomic_get_property) {
> > > > > return connector->funcs->atomic_get_property(connector,
> > > > > state, property, val);
> > > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > > > index 47dc53c4a738..e848374dee0b 100644
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
> > > > > BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
> > > > >
> > > > > +static const u32 hdmi_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > +static const u32 dp_colorformats =
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
> > > > > + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
> > > > > +
> > > > > /*
> > > > > * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
> > > > > * Format Table 2-120
> > > > > @@ -2940,6 +2952,102 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
> > > > > }
> > > > > EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
> > > > >
> > > > > +/**
> > > > > + * drm_connector_attach_color_format_property - create and attach color format property
> > > > > + * @connector: connector to create the color format property on
> > > > > + * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
> > > > > + * values the connector supports
> > > > > + *
> > > > > + * Called by a driver to create a color format property. The property is
> > > > > + * attached to the connector automatically on success.
> > > > > + *
> > > > > + * @supported_color_formats should only include color formats the connector
> > > > > + * type can actually support.
> > > > > + *
> > > > > + * Returns:
> > > > > + * 0 on success, negative errno on error
> > > > > + */
> > > > > +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> > > > > + unsigned long supported_color_formats)
> > > > > +{
> > > > > + struct drm_device *dev = connector->dev;
> > > > > + struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
> > > > > + unsigned int i = 0;
> > > > > + unsigned long fmt;
> > > > > +
> > > > > + if (connector->color_format_property)
> > > > > + return 0;
> > > > > +
> > > > > + if (!supported_color_formats) {
> > > > > + drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
> > > > > + drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + switch (connector->connector_type) {
> > > > > + case DRM_MODE_CONNECTOR_HDMIA:
> > > > > + case DRM_MODE_CONNECTOR_HDMIB:
> > > > > + if (supported_color_formats & ~hdmi_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + case DRM_MODE_CONNECTOR_DisplayPort:
> > > > > + case DRM_MODE_CONNECTOR_eDP:
> > > > > + if (supported_color_formats & ~dp_colorformats) {
> > > > > + drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
> > > > > + connector->base.id, connector->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + enum_list[0].name = "AUTO";
> > > > > + enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
> > > > > +
> > > > > + for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
> > > > > + switch (fmt) {
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > > > > + break;
> > > > > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > > + enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > > > > + break;
> > > > > + default:
> > > > > + drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
> > > > > + fmt, connector->base.id, connector->name);
> > > > > + continue;
> > > > > + }
> > > > > + enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
> > > > > + }
> > > > > +
> > > > > + connector->color_format_property =
> > > > > + drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
> > > > > + enum_list, i + 1);
> > > > > +
> > > > > + if (!connector->color_format_property)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + drm_object_attach_property(&connector->base, connector->color_format_property,
> > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_connector_attach_color_format_property);
> > > > > +
> > > > > /**
> > > > > * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
> > > > > * @old_state: old connector state to compare
> > > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > > --- a/include/drm/drm_connector.h
> > > > > +++ b/include/drm/drm_connector.h
> > > > > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > > > > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > > > > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > > > > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > > > > + * Number of valid output color format values in this enum
> > > > > */
> > > > > enum drm_output_color_format {
> > > > > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > > > > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * enum drm_connector_color_format - Connector Color Format Request
> > > > > + *
> > > > > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > > > > + * for a specific color format on a connector through the DRM "color format"
> > > > > + * property. The difference is that it has an "AUTO" value to specify that
> > > > > + * no specific choice has been made.
> > > > > + */
> > > > > +enum drm_connector_color_format {
> > > > > + /**
> > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > + * semantics.
> > > > > + *
> > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > + * YCbCr 4:2:0.
> > > >
> > > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> > >
> > > On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth
> > > compared to 8bpc 4:4:4.
> >
> > It does save bandwidth against 10 or 12bpc RGB 4:4:4.
> >
> > Or is the implication that max_bpc = 12 and
> > DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select
> > RGB in preference to selecting 4:2:2?
>
> Yeah, YCbCr has all kinds of extra complications compared to RGB, so
> the policy is to use RGB if possible, and only fall back to YCbCr as a
> last resort. And in that case 4:2:0 is the only thing that can help.
So a media player wanting to do 12bpc HDR playback at 4k60 over HDMI
2.0 ends up with 8bpc RGB regardless. That sucks.
I guess at least an override is being added so userspace can take control.
I'd missed that vc4 had its behaviour changed with the
drm_hdmi_state_helper update :-(
Dave
^ permalink raw reply
* [GIT PULL] Qualcomm clock fix for v7.0
From: Bjorn Andersson @ 2026-03-26 13:45 UTC (permalink / raw)
To: Stephen Boyd, linux-clk; +Cc: linux-arm-msm, linux-arm-kernel, Dmitry Baryshkov
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-fixes-for-7.0
for you to fetch changes up to 141af1be817c42c7f1e1605348d4b1983d319bea:
clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source (2026-02-23 10:45:35 -0600)
----------------------------------------------------------------
Qualcomm clock fix for v7.0
Fix the clock ops for SM8450 DPTX1 aux clock src to ensure DisplayPort
works.
----------------------------------------------------------------
Dmitry Baryshkov (1):
clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source
drivers/clk/qcom/dispcc-sm8450.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-26 13:47 UTC (permalink / raw)
To: Alice Ryhl, Christian Schrefl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas
Cc: Russell King (Oracle), Miguel Ojeda, a.hindborg, acourbot, akpm,
anton.ivanov, bjorn3_gh, boqun.feng, dakr, david, gary, johannes,
justinstitt, linux-arm-kernel, linux-kbuild, linux-kernel,
linux-mm, linux-um, llvm, lossin, mark.rutland, mmaurer, morbo,
nathan, nick.desaulniers+lkml, nicolas.schier, nsc, peterz,
richard, rust-for-linux, tmgross, urezki
In-Reply-To: <acUGAsjYvNvTEO92@google.com>
On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> I noticed that the Makefile currently uses the arm-unknown-linux-gnueabi
> target. It should probably not be -linux target to avoid this? Probably
> it should just be armv7a-none-eabi, right? We gate HAVE_RUST on
> CPU_32v7, so we should not need to consider the other variants.
I think Christian tried several targets back then and eventually
picked that one.
Christian: what was the reason to pick the `-linux-` one? e.g. was
there something you wanted to rely on that target spec that you
couldn't enable or disable via `rustc` flags or similar?
Cc'ing a few folks.
Thanks!
Cheers,
Miguel
^ 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