* [PATCH 1/3] dt-bindings: mfd: syscon: Document the LVDS_CMN syscon for the RZ/G3L
From: Biju @ 2026-04-17 17:52 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, devicetree, linux-kernel, linux-renesas-soc,
Prabhakar Mahadev Lad, Biju Das, Tommaso Merciai
In-Reply-To: <20260417175235.224809-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
The RZ/G3{E,L} SoCs have an LVDS Common (LVDS_CMN) region which is common
to all LVDS channels. The RZ/G3L has single-link, but the RZ/G3E has both
single and dual-link.
Use the syscon interface to access these registers for scalability.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e22867088063..9c81010d5a74 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -221,6 +221,7 @@ properties:
- nxp,s32g3-gpr
- qcom,apq8064-mmss-sfpb
- qcom,apq8064-sps-sic
+ - renesas,r9a08g046-lvds-cmn
- rockchip,px30-qos
- rockchip,rk3036-qos
- rockchip,rk3066-qos
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] Add support for Renesas RZ/G3L LVDS encoder
From: Biju @ 2026-04-17 17:52 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Tommaso Merciai, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Add support for the RZ/G3L LVDS encoder driver. It operates in single-link
mode with 4 lanes (Data) + 1 lane (Clock) and supports pixel clock rates
from 25 to 87 MHz. The LVDS module cannot be used at the same time as
MIPI-DSI. However, LVDS and the DSI interface share a peripheral clock and
the MIPI_DSI_PRESET_N reset signal. Also, the MIPI_DSI_CMN_RSTB and
MIPI_DSI_ARESET_N reset signals must be asserted before using the LVDS
module.
Biju Das (3):
dt-bindings: mfd: syscon: Document the LVDS_CMN syscon for the RZ/G3L
dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoder
drm: renesas: rz-du: Add support for RZ/G3L LVDS encoder
.../bridge/renesas,r9a08g046-lvds.yaml | 128 +++++++
.../devicetree/bindings/mfd/syscon.yaml | 1 +
drivers/gpu/drm/renesas/rz-du/Kconfig | 13 +
drivers/gpu/drm/renesas/rz-du/Makefile | 1 +
drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c | 333 ++++++++++++++++++
drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.h | 22 ++
.../gpu/drm/renesas/rz-du/rzg3l_lvds_regs.h | 26 ++
7 files changed, 524 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,r9a08g046-lvds.yaml
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg3l_lvds.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg3l_lvds_regs.h
--
2.43.0
^ permalink raw reply
* RE:[net-next v2 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Sai Krishna Gajula @ 2026-04-17 17:44 UTC (permalink / raw)
To: Minda Chen, Alexandre Torgue, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <20260417024523.107786-5-minda.chen@starfivetech.com>
> -----Original Message-----
> From: Minda Chen <minda.chen@starfivetech.com>
> Sent: Friday, April 17, 2026 8:15 AM
> To: Alexandre Torgue <alexandre.torgue@foss.st.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Emil Renner Berthing
> <emil.renner.berthing@canonical.com>; Rob Herring <robh+dt@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor@kernel.org>; netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-stm32@st-md-
> mailman.stormreply.com; devicetree@vger.kernel.org; Minda Chen
> <minda.chen@starfivetech.com>
> Subject: [net-next v2 4/5] net: stmmac: starfive: Add JHB100
> SGMII interface
>
> Add JHB100 compatible and SGMII support. JHB100 soc contains 2 SGMII
> interfaces and integrated with serdes PHY. SGMII with split TX/RX MAC clock
> and need to set 2. 5M/25M/125M TX/RX clock rate in 10M/100M/1000M
> speed mode. Signed-off-by:
> Add JHB100 compatible and SGMII support. JHB100 soc contains
> 2 SGMII interfaces and integrated with serdes PHY. SGMII with split TX/RX
> MAC clock and need to set 2.5M/25M/125M TX/RX clock rate in
> 10M/100M/1000M speed mode.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../ethernet/stmicro/stmmac/dwmac-starfive.c | 54 ++++++++++++++-----
> 1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
> index 16b955a6d77b..91698c763dac 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
> @@ -26,6 +26,7 @@ struct starfive_dwmac_data { struct starfive_dwmac {
> struct device *dev;
> const struct starfive_dwmac_data *data;
> + struct clk *sgmii_rx;
> };
>
> static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
> @@ -68,6 +69,24 @@ static int starfive_dwmac_set_mode(struct
> plat_stmmacenet_data *plat_dat)
> return 0;
> }
>
> +static int stmmac_starfive_sgmii_set_clk_rate(void *bsp_priv, struct clk
> *clk_tx_i,
> + phy_interface_t interface, int
> speed) {
phy_interface_t interface is likely unused in stmmac_starfive_sgmii_set_clk_rate → may need __maybe_unused or (void)interface to avoid -Werror=unused-parameter on strict builds.
> + struct starfive_dwmac *dwmac = (void *)bsp_priv;
> + long rate = rgmii_clock(speed);
> + int ret;
> +
> + /* MAC clock rate the same as RGMII */
> + if (rate < 0)
> + return 0;
> +
> + ret = clk_set_rate(clk_tx_i, rate);
> + if (ret)
> + return ret;
> +
> + return clk_set_rate(dwmac->sgmii_rx, rate); }
> +
> static int starfive_dwmac_probe(struct platform_device *pdev) {
> struct plat_stmmacenet_data *plat_dat; @@ -102,24 +121,34 @@
> static int starfive_dwmac_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, PTR_ERR(clk_gtx),
> "error getting gtx clock\n");
>
> - /* Generally, the rgmii_tx clock is provided by the internal clock,
> - * which needs to match the corresponding clock frequency according
> - * to different speeds. If the rgmii_tx clock is provided by the
> - * external rgmii_rxin, there is no need to configure the clock
> - * internally, because rgmii_rxin will be adaptively adjusted.
> - */
> - if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-
> clk"))
> - plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> + if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> + dwmac->sgmii_rx = devm_clk_get_enabled(&pdev->dev,
> "sgmii_rx");
> + if (IS_ERR(dwmac->sgmii_rx))
> + return dev_err_probe(&pdev->dev,
> + PTR_ERR(dwmac->sgmii_rx),
> + "error getting sgmii rx clock\n");
> + plat_dat->set_clk_tx_rate =
> stmmac_starfive_sgmii_set_clk_rate;
> + } else {
> + /*
> + * Generally, the rgmii_tx clock is provided by the internal
> clock,
> + * which needs to match the corresponding clock frequency
> according
> + * to different speeds. If the rgmii_tx clock is provided by the
> + * external rgmii_rxin, there is no need to configure the clock
> + * internally, because rgmii_rxin will be adaptively adjusted.
> + */
> + if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-
> rgmii-clk"))
> + plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
> +
> + err = starfive_dwmac_set_mode(plat_dat);
> + if (err)
> + return err;
> + }
>
> dwmac->dev = &pdev->dev;
> plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
> plat_dat->bsp_priv = dwmac;
> plat_dat->dma_cfg->dche = true;
>
> - err = starfive_dwmac_set_mode(plat_dat);
> - if (err)
> - return err;
> -
> return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res); }
>
> @@ -130,6 +159,7 @@ static const struct starfive_dwmac_data jh7100_data =
> { static const struct of_device_id starfive_dwmac_match[] = {
> { .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
> { .compatible = "starfive,jh7110-dwmac" },
> + { .compatible = "starfive,jhb100-dwmac" },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
> --
> 2.17.1
>
Reviewed-by: Sai Krishna <saikrishnag@marvell.com>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
From: Nickolay Goppen @ 2026-04-17 17:36 UTC (permalink / raw)
To: Ekansh Gupta, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <54b1be0d-1ec3-405c-b1ff-bc759b80e7bc@oss.qualcomm.com>
I'm assigning this region in the fourth patch
17 апреля 2026 г. 18:15:45 GMT+03:00, Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> wrote:
>On 15-04-2026 15:22, Konrad Dybcio wrote:
>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>> Downstream [1] this region is marked as shared and reusable so
>>> describe it that way.
>>>
>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>>
>> +Ekansh some insight, please?
>>
>> We're giving away that memory via qcom_scm_assign_mem() anyway
>> and I would assume that making it not-"no-map" could introduce issues
>> when the OS tries to access that region
>>
>With the current version and the upcoming planned enhancements, I don't
>see any major benefits of making this as not-"no-map".
>
>With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>entire memory-region to lpass VMIDs. and un-assign it only during
>fastrpc_rpmsg_remove(). There have been implementation in downstream
>where this memory is dumped in case of SSR or audio PDR using minidump,
>so marking it `reusable` might make sense there, but that dump logic is
>not added upstream.
>
>Upon checking the DT, I see a bigger problem here, this memory-region
>looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>Please correct me if I am wrong about this point.
>
>[1]
>https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
>[2]
>https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
>
>//Ekansh
>> Konrad
>>
>>
>>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> index 4b47efdb57b2..13094b5e9339 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>> };
>>>
>>> adsp_mem: adsp-region@f6000000 {
>>> + compatible = "shared-dma-pool";
>>> reg = <0x0 0xf6000000 0x0 0x800000>;
>>> - no-map;
>>> + reusable;
>>> };
>>>
>>> qseecom_mem: qseecom-region@f6800000 {
>>>
Best regards
Nickolay
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-17 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <0d80dcbe-cb46-45e5-821a-de5299d6a663@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]
Hi Arnd,
Thanks for your comments.
> Am 17.04.2026 um 11:59 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>>
>> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
>> stable regardless of the other enabled UARTs. UART0, as the name
>> implies, has a lower MMIO address, but uart1 is the one that usually has
>> the boot output and console.
>
> I'm not sure I'm following here. You generally want to either make
> sure the alias matches whatever number is printed on the product
> if there are multiple numbered ports, or you just use 'serial0'
> as the only alias if there is only one port.
Not all boards have their uart pins labeled, but those that do have the pins that connect to the UART at 0x01408000 named UART1RX/UART1TX. Most boards have only one though. I have seen a picture of only one that has UART0 and UART1. I could not test that board myself yet.
My original reason is one of developer convenience: If I have
uart0=serial@131000{
reg = <0x00131000 0x1000>;
...
status = "disabled";
};
uart1=serial@1408000{
reg = <0x01408000 0x1000>;
...
status = "okay";
};
cmdline="... console=ttyAMA{0/1} ..."
changing uart0.status between disabled and okay (e.g. to experiment with uart0 and pinctrl) required changing the command line to match. I found that pretty annoying and the aliases seemed like the best way to avoid this.
Either way I am open to do whatever. I can keep the current naming for the reasons stated above, I can name serial@1408000 "uart0" and leave the others without an alias or I can drop the alias altogether.
> Either way, the alias should go into the board specific file, not
> the general SoC file, as a board might be using a different
> set of UARTs.
That works for me, I'll move them. The aliases will most likely be the same for all boards based on this chipset, meaning duplicate code, but matching the alias to the board labels makes sense to me.
> Since you know the addresses of the other uart instances, I would
> suggest you add all of them at the same time.
Will do.
I'll hold off for a bit before I resend the patches to see if some other comments come up.
Cheers,
Stefan
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: cpufreq: add mt8189 cpufreq hw dt-bindings
From: Conor Dooley @ 2026-04-17 16:40 UTC (permalink / raw)
To: Binbin Shi
Cc: Rafael J . Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hector Yuan, linux-pm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, vince-wl.liu
In-Reply-To: <20260417080648.3692438-1-binbin.shi@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On Fri, Apr 17, 2026 at 04:06:17PM +0800, Binbin Shi wrote:
> Add mt8189 cpufreq hw compatible in dt-bindings.
Why's this not compatible with the existing device? You've got no driver
change with this so I can't even guess as why. The incompatibility should
be explained in the commit message.
pw-bot: changes-requested
Cheers,
Conor.
>
> Signed-off-by: Binbin Shi <binbin.shi@mediatek.com>
> ---
> .../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> index d0aecde2b89b..cff52fffc6b8 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
> @@ -16,7 +16,9 @@ description:
>
> properties:
> compatible:
> - const: mediatek,cpufreq-hw
> + enum:
> + - mediatek,cpufreq-hw
> + - mediatek,mt8189-cpufreq-hw
>
> reg:
> minItems: 1
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Enable and configure i2c MCU node to get fan working on Khadas VIM4.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 69d6118ba57e7..5d7f5390f3a66 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,19 @@ wifi32k: wifi32k {
};
};
+&i2c_m_ao_a {
+ status = "okay";
+ pinctrl-0 = <&i2c0_ao_d_pins>;
+ pinctrl-names = "default";
+
+ khadas_mcu: system-controller@18 {
+ compatible = "khadas,vim4-mcu";
+ reg = <0x18>;
+ fan-supply = <&vcc5v>;
+ #cooling-cells = <2>;
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
--
2.49.0
^ permalink raw reply related
* [PATCH v3 7/8] arm64: dts: amlogic: t7: Add i2c controller node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 i2c controller node used by the Khadas VIM4
for MCU communication.
Use amlogic,meson-axg-i2c as fallback compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index e96fe10b251a0..560c9dce35266 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -711,6 +711,16 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ i2c_m_ao_a: i2c@76000 {
+ compatible = "amlogic,t7-i2c", "amlogic,meson-axg-i2c";
+ reg = <0x0 0x76000 0x0 0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_periphs CLKID_SYS_I2C_AO_A>;
+ status = "disabled";
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.49.0
^ permalink raw reply related
* [PATCH v3 6/8] arm64: dts: amlogic: t7: Add i2c pinctrl node
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 pinctrl used by the Khadas VIM4 for MCU communication.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed623..e96fe10b251a0 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -376,6 +376,16 @@ mux {
};
};
+ i2c0_ao_d_pins: i2c0-ao-d {
+ mux {
+ groups = "i2c0_ao_sck_d",
+ "i2c0_ao_sda_d";
+ function = "i2c0_ao";
+ bias-disable;
+ drive-strength-microamp = <3000>;
+ };
+ };
+
pwm_a_pins: pwm-a {
mux {
groups = "pwm_a";
--
2.49.0
^ permalink raw reply related
* [PATCH v3 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Replace the hardcoded MAX_LEVEL constant and fan register
with values read from platform_data (fan_reg, max_level),
as new MCUs need different values.
Optionally acquire and enable a "fan" regulator supply
at probe time and on resume,
so boards that gate fan power through a regulator are handled.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/khadas_mcu_fan.c | 49 +++++++++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
index d35e5313bea41..24559bf65de46 100644
--- a/drivers/thermal/khadas_mcu_fan.c
+++ b/drivers/thermal/khadas_mcu_fan.c
@@ -13,13 +13,15 @@
#include <linux/regmap.h>
#include <linux/sysfs.h>
#include <linux/thermal.h>
-
-#define MAX_LEVEL 3
+#include <linux/regulator/consumer.h>
struct khadas_mcu_fan_ctx {
struct khadas_mcu *mcu;
+ unsigned int fan_reg;
unsigned int level;
+ unsigned int max_level;
struct thermal_cooling_device *cdev;
+ struct regulator *power;
};
static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
@@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
{
int ret;
- ret = regmap_write(ctx->mcu->regmap, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
- level);
+ ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
if (ret)
return ret;
@@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- *state = MAX_LEVEL;
+ struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
+
+ *state = ctx->max_level;
return 0;
}
@@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
{
struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
- if (state > MAX_LEVEL)
+ if (state > ctx->max_level)
return -EINVAL;
if (state == ctx->level)
@@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct khadas_mcu_fan_ctx *ctx;
int ret;
+ const struct khadas_mcu_fan_pdata *pdata = dev_get_platdata(&pdev->dev);
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+
ctx->mcu = mcu;
+ ctx->fan_reg = pdata->fan_reg;
+ ctx->max_level = pdata->max_level;
+
+ ctx->power = devm_regulator_get_optional(dev->parent, "fan");
+ if (IS_ERR(ctx->power)) {
+ if (PTR_ERR(ctx->power) == -ENODEV)
+ ctx->power = NULL;
+ else
+ return PTR_ERR(ctx->power);
+ }
+
+ if (ctx->power) {
+ ret = regulator_enable(ctx->power);
+ if (ret) {
+ dev_err(dev, "Failed to enable fan power supply: %d\n", ret);
+ return ret;
+ }
+ }
+
platform_set_drvdata(pdev, ctx);
cdev = devm_thermal_of_cooling_device_register(dev->parent,
@@ -124,12 +148,25 @@ static int khadas_mcu_fan_suspend(struct device *dev)
ctx->level = level_save;
+ if (ctx->power) {
+ ret = regulator_disable(ctx->power);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
static int khadas_mcu_fan_resume(struct device *dev)
{
struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
+ int ret;
+
+ if (ctx->power) {
+ ret = regulator_enable(ctx->power);
+ if (ret)
+ return ret;
+ }
return khadas_mcu_fan_set_level(ctx, ctx->level);
}
--
2.49.0
^ permalink raw reply related
* [PATCH v3 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Refactor probe() to use per-variant khadas_mcu_data
instead of hardcoded globals.
Add dedicated regmap configuration and device data for the VIM4 MCU,
with its own volatile/writeable registers.
Add the fan control register
(0–100 levels vs 0–3 for previous supported boards).
Add a new compatible string "khadas,vim4-mcu".
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 95 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
index ba981a7886921..b36b3b3ab73c0 100644
--- a/drivers/mfd/khadas-mcu.c
+++ b/drivers/mfd/khadas-mcu.c
@@ -75,15 +75,91 @@ static const struct regmap_config khadas_mcu_regmap_config = {
.cache_type = REGCACHE_MAPLE,
};
+static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
+ .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
+ .max_level = 3,
+};
+
static struct mfd_cell khadas_mcu_fan_cells[] = {
/* VIM1/2 Rev13+ and VIM3 only */
- { .name = "khadas-mcu-fan-ctrl", },
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_mcu_fan_pdata,
+ .pdata_size = sizeof(khadas_mcu_fan_pdata),
+ },
};
static struct mfd_cell khadas_mcu_cells[] = {
{ .name = "khadas-mcu-user-mem", },
};
+static const struct khadas_mcu_data khadas_mcu_data = {
+ .regmap_config = &khadas_mcu_regmap_config,
+ .cells = khadas_mcu_cells,
+ .ncells = ARRAY_SIZE(khadas_mcu_cells),
+ .fan_cells = khadas_mcu_fan_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells),
+};
+
+static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_PWR_OFF_CMD_REG:
+ case KHADAS_MCU_VIM4_REST_CONF_REG:
+ case KHADAS_MCU_WOL_INIT_START_REG:
+ case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
+ case KHADAS_MCU_VIM4_FAN_CTRL_REG:
+ case KHADAS_MCU_VIM4_WDT_EN_REG:
+ case KHADAS_MCU_VIM4_SYS_RST_REG:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case KHADAS_MCU_VERSION_0_REG:
+ case KHADAS_MCU_VERSION_1_REG:
+ case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static const struct regmap_config khadas_mcu_vim4_regmap_config = {
+ .reg_bits = 8,
+ .reg_stride = 1,
+ .val_bits = 8,
+ .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
+ .volatile_reg = khadas_mcu_vim4_reg_volatile,
+ .writeable_reg = khadas_mcu_vim4_reg_writeable,
+ .cache_type = REGCACHE_MAPLE,
+};
+
+static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
+ .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
+ .max_level = 0x64,
+};
+
+static const struct mfd_cell khadas_mcu_vim4_cells[] = {
+ {
+ .name = "khadas-mcu-fan-ctrl",
+ .platform_data = &khadas_vim4_fan_pdata,
+ .pdata_size = sizeof(khadas_vim4_fan_pdata),
+ },
+};
+
+static const struct khadas_mcu_data khadas_vim4_mcu_data = {
+ .regmap_config = &khadas_mcu_vim4_regmap_config,
+ .cells = NULL,
+ .ncells = 0,
+ .fan_cells = khadas_mcu_vim4_cells,
+ .nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells),
+};
+
static int khadas_mcu_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
@@ -94,28 +170,35 @@ static int khadas_mcu_probe(struct i2c_client *client)
if (!ddata)
return -ENOMEM;
+ ddata->data = i2c_get_match_data(client);
+ if (!ddata->data)
+ return -EINVAL;
+
i2c_set_clientdata(client, ddata);
ddata->dev = dev;
- ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
+ ddata->regmap = devm_regmap_init_i2c(client,
+ ddata->data->regmap_config);
if (IS_ERR(ddata->regmap)) {
ret = PTR_ERR(ddata->regmap);
dev_err(dev, "Failed to allocate register map: %d\n", ret);
return ret;
}
- ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_cells,
- ARRAY_SIZE(khadas_mcu_cells),
- NULL, 0, NULL);
- if (ret)
- return ret;
+ if (ddata->data->cells && ddata->data->ncells) {
+ ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
+ ddata->data->cells,
+ ddata->data->ncells,
+ NULL, 0, NULL);
+ if (ret)
+ return ret;
+ }
if (of_property_present(dev->of_node, "#cooling-cells"))
return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
- khadas_mcu_fan_cells,
- ARRAY_SIZE(khadas_mcu_fan_cells),
+ ddata->data->fan_cells,
+ ddata->data->nfan_cells,
NULL, 0, NULL);
return 0;
@@ -123,7 +206,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
#ifdef CONFIG_OF
static const struct of_device_id khadas_mcu_of_match[] = {
- { .compatible = "khadas,mcu", },
+ { .compatible = "khadas,mcu", .data = &khadas_mcu_data },
+ { .compatible = "khadas,vim4-mcu", .data = &khadas_vim4_mcu_data },
{},
};
MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
--
2.49.0
^ permalink raw reply related
* [PATCH v3 3/8] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Introduce a per-variant configuration structure (khadas_mcu_data)
holding the regmap config and MFD cells,
selected at probe time via the of_device_id match data.
This makes adding other variants straightforward.
Also introduce khadas_mcu_fan_pdata to pass fan register address and
maximum level to the fan sub-driver, removing the hardcoded constants.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/mfd/khadas-mcu.h | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
index a99ba2ed0e4e0..75e275d3fa8d9 100644
--- a/include/linux/mfd/khadas-mcu.h
+++ b/include/linux/mfd/khadas-mcu.h
@@ -70,6 +70,13 @@
#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
+/* VIM4 specific registers */
+#define KHADAS_MCU_VIM4_REST_CONF_REG 0x2c /* WO - reset EEPROM */
+#define KHADAS_MCU_VIM4_LED_ON_RAM_REG 0x89 /* WO - LED volatile */
+#define KHADAS_MCU_VIM4_FAN_CTRL_REG 0x8a /* WO */
+#define KHADAS_MCU_VIM4_WDT_EN_REG 0x8b /* WO */
+#define KHADAS_MCU_VIM4_SYS_RST_REG 0x91 /* WO */
+
enum {
KHADAS_BOARD_VIM1 = 0x1,
KHADAS_BOARD_VIM2,
@@ -82,10 +89,38 @@ enum {
* struct khadas_mcu - Khadas MCU structure
* @device: device reference used for logs
* @regmap: register map
+ * @data: pointer to variant-specific config
*/
struct khadas_mcu {
- struct device *dev;
- struct regmap *regmap;
+ struct device *dev;
+ struct regmap *regmap;
+ const struct khadas_mcu_data *data;
+};
+
+/**
+ * struct khadas_mcu_data - per-variant configuration
+ * @regmap_config: regmap configuration
+ * @cells: MFD sub-devices
+ * @ncells: number of sub-devices
+ * @fan_cells: MFD fan sub-devices
+ * @nfan_cells: number of fan sub-devices
+ */
+struct khadas_mcu_data {
+ const struct regmap_config *regmap_config;
+ const struct mfd_cell *cells;
+ int ncells;
+ const struct mfd_cell *fan_cells;
+ int nfan_cells;
+};
+
+/**
+ * struct khadas_mcu_fan_pdata - fan sub-driver configuration
+ * @fan_reg: register address to write the fan level
+ * @max_level: maximum fan level
+ */
+struct khadas_mcu_fan_pdata {
+ unsigned int fan_reg;
+ unsigned int max_level;
};
#endif /* MFD_KHADAS_MCU_H */
--
2.49.0
^ permalink raw reply related
* [PATCH v3 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH v3 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..a80718f7595ce 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu # Different MCU variant, not discoverable
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,6 +26,10 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
--
2.49.0
^ permalink raw reply related
* [PATCH v3 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v3:
- PATCH 1: adding comment on vim4 compatible saying it is not discoverable,
thanks to Rob's and Neil's feedback.
- Link to v2: https://lore.kernel.org/r/20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr
Changes in v2:
- PATCH 5: Add regulator_disable on suspend thanks to Neil's feedback.
- Link to v1: https://lore.kernel.org/r/20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 5 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 49 ++++++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 222 insertions(+), 23 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-17 16:34 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2000470.6tgchFWduM@phil>
Hi Heiko,
On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> Hi Cristian,
>
> the comments below apply sort of to all patches in that series.
>
> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>
>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>> adjusting the bias when transitioning between TMDS and FRL operating
>> modes.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> index 749f0a54b478..93ae37699366 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> @@ -140,10 +140,7 @@ regulator-state-mem {
>>
>> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
>> compatible = "regulator-fixed";
>> - enable-active-high;
>> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
>> - pinctrl-names = "default";
>> - pinctrl-0 = <&hdmi_con_en>;
>> + regulator-always-on;
>> regulator-min-microvolt = <5000000>;
>> regulator-max-microvolt = <5000000>;
>> regulator-name = "vcc_5v0_hdmi";
>
> I think this regulator was sort of a complete hack, to set that
> gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
>
> Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
> is completely functionless now, the whole thing could be removed?
Ack, let's just drop it.
>
>
>> @@ -231,6 +228,8 @@ &gpu {
>> };
>>
>> &hdmi {
>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>
> this should be sorted the other way around I think.
>
> Also please provide a pinctrl-names property too. If for whatever reason
> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> board DTs are staying in the "old" compatible mode until they are adapted.
Just to make sure I fully understand, the convention is that
pinctrl-names = "default";
should be always provided, even when the node overrides an existing pinctrl-0
property?
E.g. in rk3576.dtsi we have:
hdmi: hdmi@27da0000 {
...
pinctrl-names = "default";
pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
...
}
Hence I omitted pinctrl-names which doesn't change and just appended
&hdmi_frl_en to pinctrl-0's original value.
>
>
>> status = "okay";
>> };
>>
>> @@ -655,7 +654,7 @@ &pcie0 {
>>
>> &pinctrl {
>> hdmi {
>> - hdmi_con_en: hdmi-con-en {
>> + hdmi_frl_en: hdmi-frl-en {
>
> pinctrl names should ideally match the naming in schematics, for example the
> "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to> go from DT
> to schematics and back.
I opted for a more descriptive name that could be used consistently across all
boards, given that not all schematics are publicly available.
You make a fair point though, we should probably stick with the pretty terrible
hdmi[N]_tx_on_h naming instead.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Conor Dooley @ 2026-04-17 16:24 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260417-dev_max20830-v3-1-0cb8d56067aa@analog.com>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Fri, Apr 17, 2026 at 04:27:13PM +0800, Alexis Czezar Torreno wrote:
> Add device tree documentation for MAX20830 step-down DC-DC switching
> regulator with PMBus interface.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
In the future, please relax a bit with new revisions, particularly
during the merge window when nothing is gonna get applied and there's no
urgency.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Conor Dooley @ 2026-04-17 16:22 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260417100519.1043-2-jianhua.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3203 bytes --]
On Fri, Apr 17, 2026 at 06:05:17PM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..fd895688a038 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,20 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
This should be restricted to only the new platform.
>
> power-domains:
> maxItems: 1
> @@ -60,6 +67,31 @@ required:
> - power-domains
> - iommus
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8189-jpgdec
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 1
Constraints that duplicate the outtermost ones don't need to
be/shouldn't be repeated here. You only need the maxItems here and the
minItems in the else.
pw-bot: changes-requested
Cheers,
COnor.
> + clock-names:
> + minItems: 1
> + maxItems: 1
> + required:
> + - mediatek,larb
> + else:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + clock-names:
> + minItems: 2
> + maxItems: 2
> +
> additionalProperties: false
>
> examples:
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: display: panel: Add compatibles for Zhunyi Z40046
From: Conor Dooley @ 2026-04-17 16:19 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: dri-devel, Jagan Teki, Neil Armstrong, Jessica Zhang,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
devicetree, linux-kernel
In-Reply-To: <20260417104740.259689-2-l.scorcia@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
On Fri, Apr 17, 2026 at 11:46:30AM +0100, Luca Leonardo Scorcia wrote:
> The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
> Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
> x04g, apparently in two different variants.
>
> The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
> JD9365DA-H3, it just uses a different initialization sequence.
>
> Since this is the first supported device from this vendor, document its
> name to the vendor-prefixes.yaml file as well.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> .../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 2 ++
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> index e39efb44ed42..158388a284d9 100644
> --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> @@ -24,6 +24,8 @@ properties:
> - radxa,display-10hd-ad001
> - radxa,display-8hd-ad002
> - taiguanck,xti05101-01a
> + - zhunyikeji,z40046-ctc
> + - zhunyikeji,z40046-boe
> - const: jadard,jd9365da-h3
>
> reg:
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 6339988e3805..debaec59e9a0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1923,6 +1923,8 @@ patternProperties:
> description: Zealz
> "^zeitec,.*":
> description: ZEITEC Semiconductor Co., LTD.
> + "^zhunyikeji,.*":
> + description: Shenzhen Zhunyi Technology Co., Ltd.
> "^zidoo,.*":
> description: Shenzhen Zidoo Technology Co., Ltd.
> "^zii,.*":
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: timer: econet: Update EN751627 for multi-IRQ
From: Conor Dooley @ 2026-04-17 16:17 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, naseefkm, daniel.lezcano, tglx, robh, krzk+dt,
conor+dt, linux-kernel, devicetree
In-Reply-To: <20260416175101.958073-2-cjd@cjdns.fr>
[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]
On Thu, Apr 16, 2026 at 05:51:00PM +0000, Caleb James DeLisle wrote:
> From conception, this driver supported EN751627 as it is the same
> hardware that is used in EN751221. However, it was expected that
> EN751627 would use a percpu IRQ as does EN751221, this is how it
> works in vendor code. However upon finding that the "mti,gic" intc
> works on EN751627 with no modification - but it provides a unique
> interrupt per-timer, it is deemed best to make this driver use
> multiple IRQs when on the EN751627 platform.
Please drop mention of drivers here, bindings are about hardware,
whether or not the driver uses 1 or 4 interrupts doesn't matter, the
binding should have 4 because the hardware has 4.
pw-bot: changes-requested
Otherwise, this looks fine, so with that stuff culled
Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> .../bindings/timer/econet,en751221-timer.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> index c1e7c2b6afde..f338739e039c 100644
> --- a/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> @@ -28,8 +28,8 @@ properties:
> maxItems: 2
>
> interrupts:
> - maxItems: 1
> - description: A percpu-devid timer interrupt shared across CPUs.
> + minItems: 1
> + maxItems: 4
>
> clocks:
> maxItems: 1
> @@ -52,21 +52,31 @@ allOf:
> items:
> - description: VPE timers 0 and 1
> - description: VPE timers 2 and 3
> + interrupts:
> + description: An interrupt for each timer (one per VPE)
> + minItems: 4
> else:
> properties:
> reg:
> items:
> - description: VPE timers 0 and 1
> + interrupts:
> + description: A percpu-devid timer interrupt shared across timers
> + maxItems: 1
>
> additionalProperties: false
>
> examples:
> - |
> + #include <dt-bindings/interrupt-controller/mips-gic.h>
> timer@1fbf0400 {
> compatible = "econet,en751627-timer", "econet,en751221-timer";
> reg = <0x1fbf0400 0x100>, <0x1fbe0000 0x100>;
> interrupt-parent = <&intc>;
> - interrupts = <30>;
> + interrupts = <GIC_SHARED 30 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 29 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 37 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 36 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&hpt_clock>;
> };
> - |
> --
> 2.39.5
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: counter: add gpio-quadrature-encoder binding
From: Conor Dooley @ 2026-04-17 16:13 UTC (permalink / raw)
To: Wadim Mueller
Cc: wbg, robh, krzk+dt, conor+dt, linux-iio, devicetree, linux-kernel
In-Reply-To: <1663eb2f4bf4c826cd190fa9974fb55c321e7073.1776372319.git.wafgo01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]
On Thu, Apr 16, 2026 at 10:48:17PM +0200, Wadim Mueller wrote:
> Add devicetree binding documentation for the GPIO-based quadrature
> encoder counter driver. The driver reads A/B quadrature signals and
> an optional index pulse via edge-triggered GPIO interrupts, supporting
> X1, X2, X4 quadrature decoding and pulse-direction mode.
>
> This is useful on SoCs that lack a dedicated hardware quadrature
> decoder or where the encoder is wired to generic GPIO pins.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
> .../counter/gpio-quadrature-encoder.yaml | 69 +++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
>
> diff --git a/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml b/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
> new file mode 100644
> index 000000000..a52deaab6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/counter/gpio-quadrature-encoder.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO-based Quadrature Encoder
> +
> +maintainers:
> + - Wadim Mueller <wadim.mueller@cmblu.de>
> +
> +description: |
> + A generic GPIO-based quadrature encoder counter. Reads A/B quadrature
> + signals and an optional index pulse via edge-triggered GPIO interrupts.
> + Supports X1, X2, X4 quadrature decoding and pulse-direction mode.
> +
> + This driver is useful on SoCs that lack a dedicated hardware quadrature
> + decoder (eQEP, QEI, etc.) or where the encoder is wired to generic GPIO
> + pins rather than to a dedicated peripheral.
Idea seems okay to me. Please rephrase this section to avoid talking
about drivers...
> +
> +properties:
> + compatible:
> + const: gpio-quadrature-encoder
> +
> + encoder-a-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the encoder's A (phase A) output.
> +
> + encoder-b-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the encoder's B (phase B) output.
> +
> + encoder-index-gpios:
> + maxItems: 1
> + description:
> + Optional GPIO connected to the encoder's index (Z) output.
> + When the index input is enabled via sysfs, the count resets
> + to zero on each index pulse.
...and this to stop talking about sysfs and driver behaviour though.
Bindings are about hardware.
pw-bot: changes-requested
> +
> +required:
> + - compatible
> + - encoder-a-gpios
> + - encoder-b-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + quadrature-encoder-0 {
> + compatible = "gpio-quadrature-encoder";
> + encoder-a-gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
> + encoder-b-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
> + };
> +
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + quadrature-encoder-1 {
> + compatible = "gpio-quadrature-encoder";
> + encoder-a-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
> + encoder-b-gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> + encoder-index-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + };
I think this example alone is sufficient btw.
Cheers,
Conor.
> +
> +...
> --
> 2.52.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
From: Conor Dooley @ 2026-04-17 16:09 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-3-thierry.reding@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Fri, Apr 17, 2026 at 03:15:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Peter sadly passed away a while ago, so change the maintainers for BPMP
> SHMEM to Jon and myself.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: Conor Dooley @ 2026-04-17 16:08 UTC (permalink / raw)
To: David Lechner
Cc: Ariana Lazar, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Conor Dooley,
Jonathan Cameron, linux-iio, devicetree, linux-kernel
In-Reply-To: <120a34be-bc0d-4202-9996-c5da8cf15963@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On Fri, Apr 17, 2026 at 10:26:42AM -0500, David Lechner wrote:
> On 4/17/26 8:38 AM, Ariana Lazar wrote:
> > Change maxItems value from 8 to 1 for the channel number reg property.
>
> The commit message needs to explain why this is the correct thing to do.
With that,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
>
> >
> > Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> > Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
> > Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> > ---
> > Changes in v2:
> > - keep just maxItems value update in this patch
> > - remove Reported-by from commit message
> > - Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
> > ---
> > Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
> > --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > @@ -161,8 +161,7 @@ patternProperties:
> > properties:
> > reg:
> > description: The channel number.
> > - minItems: 1
> > - maxItems: 8
> > + maxItems: 1
> >
> > label:
> > description: Unique name to identify which channel this is.
> >
> > ---
> > base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
> > change-id: 20260416-mcp47feb02-fix5-26994c5b428c
> >
> > Best regards,
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-17 16:06 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252EB0C2A1A3313DE49406B8B202@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
On Fri, Apr 17, 2026 at 02:20:25AM +0000, Billy Tsai wrote:
> > > + properties:
> > > + function:
> > > + enum:
> > > + - EMMC
> > > + - JTAGDDR
> > > + - JTAGM0
> > > + - JTAGPCIEA
> > > + - JTAGPCIEB
> > > + - JTAGPSP
> > > + - JTAGSSP
> > > + - JTAGTSP
> > > + - JTAGUSB3A
> > > + - JTAGUSB3B
> > > + - PCIERC0PERST
> > > + - PCIERC1PERST
> > > + - TSPRSTN
> > > + - UFSCLKI
> > > + - USB2AD0
> > > + - USB2AD1
> > > + - USB2AH
> > > + - USB2AHP
> > > + - USB2AHPD0
> > > + - USB2AXH
> > > + - USB2AXH2B
> > > + - USB2AXHD1
> > > + - USB2AXHP
> > > + - USB2AXHP2B
> > > + - USB2AXHPD1
> > > + - USB2BD0
> > > + - USB2BD1
> > > + - USB2BH
> > > + - USB2BHP
> > > + - USB2BHPD0
> > > + - USB2BXH
> > > + - USB2BXH2A
> > > + - USB2BXHD1
> > > + - USB2BXHP
> > > + - USB2BXHP2A
> > > + - USB2BXHPD1
> > > + - USB3AXH
> > > + - USB3AXH2B
> > > + - USB3AXHD
> > > + - USB3AXHP
> > > + - USB3AXHP2B
> > > + - USB3AXHPD
> > > + - USB3BXH
> > > + - USB3BXH2A
> > > + - USB3BXHD
> > > + - USB3BXHP
> > > + - USB3BXHP2A
> > > + - USB3BXHPD
> > > + - VB
> > > + - VGADDC
> > > +
> > > + groups:
> > > + enum:
> > > + - EMMCCDN
> > > + - EMMCG1
> > > + - EMMCG4
> > > + - EMMCG8
> > > + - EMMCWPN
> > > + - JTAG0
> > > + - PCIERC0PERST
> > > + - PCIERC1PERST
> > > + - TSPRSTN
> > > + - UFSCLKI
> > > + - USB2A
> > > + - USB2AAP
> > > + - USB2ABP
> > > + - USB2ADAP
> > > + - USB2AH
> > > + - USB2AHAP
> > > + - USB2B
> > > + - USB2BAP
> > > + - USB2BBP
> > > + - USB2BDBP
> > > + - USB2BH
> > > + - USB2BHBP
> > > + - USB3A
> > > + - USB3AAP
> > > + - USB3ABP
> > > + - USB3B
> > > + - USB3BAP
> > > + - USB3BBP
> > > + - VB0
> > > + - VB1
> > > + - VGADDC
> > > + pins:
> > > + enum:
> > > + - AB13
> > > + - AB14
> > > + - AC13
> > > + - AC14
> > > + - AD13
> > > + - AD14
> > > + - AE13
> > > + - AE14
> > > + - AE15
> > > + - AF13
> > > + - AF14
> > > + - AF15
>
> > Why do you have groups and pins?
>
> > Is it valid in your device to have groups and pins in the same node?
>
> The intent is to support both group-based mux selection and
> configuration, as well as per-pin configuration.
>
> In our hardware:
>
> - `function` + `groups` are used for pinmux selection.
> - `pins` is used for per-pin configuration (e.g. drive strength,
> bias settings).
> - `groups` may also be used for group-level configuration.
>
> As a result, both `groups` and `pins` may appear in the same node,
> but they serve different purposes and do not conflict:
>
> - `groups` selects the mux function and may apply configuration to
> the entire group.
> - `pins` allows overriding or specifying configuration for individual
> pins.
>
> In most cases, only one of them is needed, but both are allowed when
> both group-level and per-pin configuration are required.
To be honest, that sounds like your groups are not sufficiently
granular and should be reduced such that you can use them for pin
settings.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 08/11] media: iris: Add power sequence for Glymur
From: Vishnu Reddy @ 2026-04-17 16:04 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu
In-Reply-To: <1de1a366-a325-428e-9dcc-1333bb85ed82@oss.qualcomm.com>
On 4/14/2026 3:19 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> Add power sequence hooks for controller, vcodec and vcodec1. reuse the
>> existing code where ever is possible. add vcodec1 power on and off code
>> separately which has different power domains and clocks.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 9 ++
>> drivers/media/platform/qcom/iris/iris_vpu3x.c | 123 +++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
>> .../platform/qcom/iris/iris_vpu_register_defines.h | 7 ++
>> 4 files changed, 140 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 30e9d4d288c6..e3c1aff770dd 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -61,6 +61,9 @@ enum platform_clk_type {
>> IRIS_VPP0_HW_CLK,
>> IRIS_VPP1_HW_CLK,
>> IRIS_APV_HW_CLK,
>> + IRIS_AXI_VCODEC1_CLK,
>> + IRIS_VCODEC1_CLK,
>> + IRIS_VCODEC1_FREERUN_CLK,
>> };
>>
>> struct platform_clk_data {
>> @@ -208,6 +211,12 @@ enum platform_pm_domain_type {
>> IRIS_CTRL_POWER_DOMAIN,
>> IRIS_VCODEC_POWER_DOMAIN,
>> IRIS_VPP0_HW_POWER_DOMAIN,
>> + /*
>> + * On Glymur, vcodec1 power domain is at the same index in pd_devs[]
>> + * as IRIS_VPP0_HW_POWER_DOMAIN. Alias it so that the Glymur power
>> + * domain table is indexed correctly.
>> + */
>> + IRIS_VCODEC1_POWER_DOMAIN = IRIS_VPP0_HW_POWER_DOMAIN,
> This feels really fragile..
I'm thinking to add wrapper and use the power domain name to find the
index from the
platform data instead of using the enum values. I'll try this if that works.
> [...]
>
>> +static bool iris_vpu36_hw1_power_collapsed(struct iris_core *core)
>> +{
>> + u32 value, pwr_status;
>> +
>> + value = readl(core->reg_base + WRAPPER_CORE_POWER_STATUS);
>> + pwr_status = value & BIT(4);
>> +
>> + return pwr_status ? false : true;
> return !pwr_status
Ack.
Thanks,
Vishnu Reddy.
> Konrad
^ 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