* Re: [PATCH v2 0/3] Fix MMC pin pull configurations
From: Vignesh Raghavendra @ 2026-03-27 4:56 UTC (permalink / raw)
To: Nishanth Menon, Judith Mendez
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel, Moteen Shah, Andrew Davis
In-Reply-To: <20260223233731.2690472-1-jm@ti.com>
Hi Judith Mendez,
On Mon, 23 Feb 2026 17:37:28 -0600, Judith Mendez wrote:
> This series corrects MMC pin pull-up/pull-down configurations across
> TI AM62L EVM, AM62P SK, & AM62 LP SK boards to properly match their
> hardware design.
>
> Most boards have external pull-ups on MMC pins, but DT configuration
> was also enabling internal pulls. Having both internal and external
> pulls active causes several issues:
> - Unnecessary power consumption due to stronger pull resistance
> - Floating pins violating SPEC recommendations
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/3] arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins
commit: 6d4441be969bea89bb9702781f5dfb3a8f2a02a4
[2/3] arm64: dts: ti: k3-am62l-evm: Disable MMC1 internal pulls on data pins
commit: 02532ba56362907b6aca3e8289c4a9247ef83325
[3/3] arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins
commit: ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721e: Fix QSGMII overlay by adding SERDES PHY
From: Vignesh Raghavendra @ 2026-03-27 5:15 UTC (permalink / raw)
To: Chintan Vankar
Cc: Andrew Davis, Siddharth Vadapalli, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, Tero Kristo,
Vignesh Raghavendra, Nishanth Menon, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20260326072237.1324027-1-c-vankar@ti.com>
On Thu, 26 Mar 2026 12:52:37 +0530, Chintan Vankar <c-vankar@ti.com> wrote:
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> index 8376fa4b6ee1..d403a3db0265 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> @@ -42,7 +42,8 @@ &cpsw0_port2 {
> phy-handle = <&cpsw9g_phy1>;
> phy-mode = "qsgmii";
> mac-address = [00 00 00 00 00 00];
> - phys = <&cpsw0_phy_gmii_sel 2>;
> + phys = <&cpsw0_phy_gmii_sel 2>, <&serdes0_qsgmii_link>;
> + phy-names = "mac", "serdes";
Dont you need this for all the other ports as well, just like in J784s4
overlay?
--
Vignesh
^ permalink raw reply
* Re: [PATCH v3 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: cristian_ci @ 2026-03-27 5:26 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <87943afd-2601-423e-878d-36b69ac3d6c3@oss.qualcomm.com>
On Thursday, March 26th, 2026 at 13:08, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> On 3/24/26 12:18 PM, cristian_ci wrote:
> > On Monday, March 23rd, 2026 at 11:52, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> >
> >> On 3/21/26 5:23 PM, Cristian Cozzolino via B4 Relay wrote:
> >>> From: Cristian Cozzolino <cristian_ci@protonmail.com>
> >>>
> >>> Add the description for the display panel found on this phone.
> >>> And with this done we can also enable the GPU and set the zap shader
> >>> firmware path.
> >>>
> >>> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> + panel_default: panel-default-state {
> >>> + pins = "gpio61";
> >>> + function = "gpio";
> >>> + drive-strength = <8>;
> >>> + bias-disable;
> >>> + output-high;
> >>
> >> This says "by default, actively drive the pin not to reset the display
> >> panel". Is this actually necessary?
> >
> > I've tried to remove panel pinctrl stuff from the panel and the device still boots/works exactly like before. So, have I to submit v4 without pinctrl at all for the panel?
>
> No, the pin config is useful, I'm specifically referencing the output-high
> property
I've commented out "output-high" property and (apparently) the device
boots and works like before.
> Konrad
>
^ permalink raw reply
* Re: [PATCH net-next 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Joris Vaisvila @ 2026-03-27 6:00 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <acW9G8vrMz89Enss@makrotopia.org>
Hi Daniel, thanks for the feedback
On Thu, Mar 26, 2026 at 11:11:23PM +0000, Daniel Golle wrote:
> > [...]
> > + port@6 {
> > + reg = <6>;
> > + ethernet = <ðernet>;
> > + phy-mode = "rgmii";
>
> Is this actually RGMII internally? Or some unknown internal way to
> wire the switch CPU port to the CPU MAC? In this case, "internal"
> should be used here as well.
I don't know how to find this out for sure.
In the MT7628 doc (https://vonger.cn/upload/MT7628_Full.pdf) port 6 is
refered to as RGMII port 1 (RGMII port 0 being the non-existent port 5),
but there are no clock registers to be seen.
In RT3050 docs there are RGMII clock registers for port 5, but nothing
for port 6, so maybe the CPU port is really using some mystery internal
connection and only uses "RGMII" as a way to say it's a Gigabit port?
On the hardware I'm testing on, it works fine with the port set to
"internal" or "rgmii". Would it make more sense to set "internal" then?
Thanks,
Joris
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Shengjiu Wang @ 2026-03-27 6:06 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li, s.hauer,
kernel, festevam, linux-sound, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260327031504.497650-1-chancel.liu@nxp.com>
On Fri, Mar 27, 2026 at 11:15 AM Chancel Liu <chancel.liu@nxp.com> wrote:
>
> Existing i.MX audio sound card described by this binding use codecs
> that operate in i2s or dsp_b formats. The newly added CS42448 codec
> requires dsp_a for its TDM interface. To properly describe such
> hardware in DT, the binding needs to allow dsp_a DAI format.
>
> Only i2s, dsp_b and dsp_a are included because these are the formats
> actually used by the hardware supported by this binding. Other formats
> such as left_j, right_j, ac97 are not used or required by the hardware
"pdm", "left_j", "right_j" are supported by SAI, so I think they should be added
from the hardware point of view.
Best regards
Shengjiu Wang
Shengjiu Wang
> currently covered by this binding, so they are intentionally not added.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
> Changes in v3:
> - Rewrote commit message completely to describe hardware requirements.
> Explicitly documented why only dsp_a is added and why other formats
> are not included.
> - Rebased on latest code base. No functional changes.
>
> Changes in v2:
> - Updated commit message to explain current support for i2s and dsp_b
> formats and new support for dsp_a. No code changes.
>
> Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> index 5424d4f16f52..75757fbccd89 100644
> --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> @@ -37,6 +37,7 @@ patternProperties:
> items:
> enum:
> - i2s
> + - dsp_a
> - dsp_b
>
> dai-tdm-slot-num: true
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Krzysztof Kozlowski @ 2026-03-27 6:39 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <bc22bad4-9825-829d-1df0-a801ebd933d6@loongson.cn>
On 27/03/2026 04:09, Hongliang Wang wrote:
> The initial idea was that this patch could be used for both ACPI and DTS.
>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>> platform, parse
>>>> the same parameters regardless of dts or acpi parameter passing, So
>>>> clock-input
>>>> and clock-div attributes are defined to describe input clock of i2c
>>>> controller and
>>>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
>>> And you cannot use them in DTS.
> OK
>> I need to keep guessing what you want to achieve, because neither your
>> message nor commit text was explicit
> What I want to achieve is to describe the input clock and divisor of I2C
> controller
Input clocks are defined as clock inputs obviously in DT, not as
integers. Bindings need to describe the hardware, so start with that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Krzysztof Kozlowski @ 2026-03-27 6:45 UTC (permalink / raw)
To: Sibi Sankar, Gopikrishna Garmidi, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rajendra.nayak
In-Reply-To: <328a120e-e9e0-4b3d-a2c0-04eb471c0937@oss.qualcomm.com>
On 26/03/2026 17:55, Sibi Sankar wrote:
>
> On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
>> On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
>>> The display, peripherals (touchpad/touchscreen/keypad), usb and their
>>> dependent device nodes are common to both Glymur and Mahua CRDs,
>>> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
>>> reuse.
>>>
>> Same questions as for earlier tries (why this has to be repeated?), e.g.
>> x1-crd: Please describe here what is the actual common hardware. In
>> terms of physical hardware, not what you want to share.
>
>
> There seems to be some kind of confusion here. This patch doesn't
Indeed!
> introduce the common board file rather it just moves the nodes
> mentioned in the commit message to the common board file.
>
> https://lore.kernel.org/lkml/20260318124100.212992-3-gopikrishna.garmidi@oss.qualcomm.com/
The question stays. The common DTSI represented actual shared
motherboard design between these, so I would like to still see the
answers here. I just don't trust such commits because they mimic
downstream approach (and they were actually copying downstream in the past).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: lemans-evk: Enable mdss1 display Port
From: Gopi Botlagunta @ 2026-03-27 6:51 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
venkata.valluru, jessica.zhang
In-Reply-To: <98730ff5-05b7-4275-be1d-1f9506adeac7@oss.qualcomm.com>
On Thu, Feb 19, 2026 at 02:41:27PM +0100, Konrad Dybcio wrote:
> On 2/19/26 2:36 PM, Gopi Botlagunta wrote:
> > This change enables DP controllers, DPTX0 and DPTX1 alongside
> > their corresponding PHYs of mdss1 which corresponds to edp2
> > and edp3.
> >
> > Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +&mdss1_dp0 {
> > + pinctrl-0 = <&dp2_hot_plug_det>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > +};
> > +
> > +&mdss1_dp1 {
> > + pinctrl-0 = <&dp3_hot_plug_det>;
> > + pinctrl-names = "default";
> > + status = "okay";
>
> Nit: a \n before 'status' is customary and it's present in all other
> nodes in this file
>
> [...]
>
I’ll fix the formatting in the next revision.
> > ---
> > base-commit: 1a0829927afbfe654c632eb2e779fa32df825b06
> > change-id: 20260219-enable-edp2-3-lemans-evk-mezzanine-1bef9932ee6d
> > prerequisite-message-id: 20260203193848.123307-2-umang.chheda@oss.qualcomm.com
> > prerequisite-patch-id: baf07fce333b86c35c3d4cefbba5800a519952a3
> > prerequisite-message-id: 20260217071420.2240380-1-mkuntuma@qti.qualcomm.com
> > prerequisite-patch-id: 74a76fd6a1129cdbbd32d91d2a119d693dba78a7
> > prerequisite-patch-id: f4a858f7e707c8e330daf2ea1f4da58b4da00f05
>
> This is really long and scattered across multiple people, effectively
> making it a chaos for tracking. Could you please coordinate with Mani
> who submitted the changes for the SoC as well as the ride board to
> send these patches together?
>
> Konrad
Sure, I’ve coordinated with Mani. This will be addressed in the next
revision of the dependent patch series: https://lore.kernel.org/all/20260226111322.250176-1-quic_mkuntuma@quicinc.com/
^ permalink raw reply
* Re: [PATCH v5] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Krzysztof Kozlowski @ 2026-03-27 6:54 UTC (permalink / raw)
To: Karthikeyan Mitran, Arnd Bergmann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Prasad Bolisetty, Tzu-Hao Wei,
Axiado Reviewers
Cc: devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Drew Fustini, Linus Walleij, Harshit Shah
In-Reply-To: <20260326-maintainers-addition-and-axiado-ax3000_dtsi-update-v5-1-648dfe9bff29@axiado.com>
On 26/03/2026 21:50, Karthikeyan Mitran wrote:
> From: Prasad Bolisetty <pbolisetty@axiado.com>
>
> Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
> and adding a group reviewer entry for review coverage,
> Removed previous maintainer as the previous maintainer moved from project
...
> ---
> MAINTAINERS | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 55af015174a5..49f47e8c2ec3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2605,7 +2605,10 @@ F: arch/arm/mach-aspeed/
> N: aspeed
>
> ARM/AXIADO ARCHITECTURE
> -M: Harshit Shah <hshah@axiado.com>
> +M: Prasad Bolisetty <pbolisetty@axiado.com>
> +M: Tzu-Hao Wei <twei@axiado.com>
> +M: Karthikeyan Mitran <kmitran@axiado.com>
> +R: Axiado Reviewers <linux-maintainer@axiado.com>
How many entries do you need? You already have three, so who is in
Axiado reviewers? And what is "review coverage" you mentioned in the
commit msg.
I skimmed through https://lore.kernel.org/all/?q=f%3Aaxiado.com and I do
not see reviews from any of these addresses, so it all looks like you
add some corporate structure, because some managers want to see what is
posted.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: Enable MCTP and FRU for NIC
From: Andy Chung via B4 Relay @ 2026-03-27 6:59 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Andy Chung, Andy Chung
From: Andy Chung <Andy.Chung@amd.com>
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
---
.../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 67 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 221af858cb6b..138b081be049 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -584,38 +584,67 @@ eeprom@56 {
// R Bridge Board
&i2c10 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c10mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
};
i2c10mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch5: i2c@5 {
reg = <5>;
@@ -661,38 +690,72 @@ i2c10mux0ch7: i2c@7 {
// L Bridge Board
&i2c11 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c11mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // FE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch5: i2c@5 {
reg = <5>;
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260327-dts_enable_nic_mctp-e35a5765b176
Best regards,
--
Andy Chung <Andy.Chung@amd.com>
^ permalink raw reply related
* Re: [PATCH v2 2/7] dt-bindings: dmaengine: Add SpacemiT K3 DMA compatible string
From: Troy Mitchell @ 2026-03-27 7:04 UTC (permalink / raw)
To: Conor Dooley, Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk
In-Reply-To: <20260326-explode-surplus-24c0e0813099@spud>
Hi Conor,
On Fri Mar 27, 2026 at 2:34 AM CST, Conor Dooley wrote:
> On Thu, Mar 26, 2026 at 04:17:17PM +0800, Troy Mitchell wrote:
>> From: Guodong Xu <guodong@riscstar.com>
>>
>> Add k3 compatible string.
>
> That's obvious. What you need to explain is why it is not compatible with
> the existing k1.
>
Thanks for the review.
The SpacemiT K3 PDMA requires a new compatible string because it is not fully
backward compatible with the K1 implementation due to two main hardware differences:
- Variable extended DRCMR base: The DRCMR (DMA Request/Command Register) base
address for extended DMA request numbers (>= 64) is different in the K3 hardware
implementation.
- Memory addressing capabilities: Unlike the K1 SoC, where some DMA masters had
memory addressing limitations (restricted to the 0-4GB space) and required a
dedicated dma-bus, the K3 DMA masters have full memory addressing capabilities.
I will update the commit message in the v3 series.
-Troy
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: lemans-evk: Enable mdss1 display Port
From: Gopi Botlagunta @ 2026-03-27 7:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
venkata.valluru, jessica.zhang
In-Reply-To: <d54f4b17-a137-494b-b103-2734987c4f14@kernel.org>
On Thu, Feb 19, 2026 at 03:24:24PM +0100, Krzysztof Kozlowski wrote:
> On 19/02/2026 14:36, Gopi Botlagunta wrote:
> > This change enables DP controllers, DPTX0 and DPTX1 alongside
>
>
> Please do not use "This commit/patch/change", but imperative mood. See
> longer explanation here:
> https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
>
I’ll update the commit text in the next revision.
> >
> > ---
> > base-commit: 1a0829927afbfe654c632eb2e779fa32df825b06
> > change-id: 20260219-enable-edp2-3-lemans-evk-mezzanine-1bef9932ee6d
> > prerequisite-message-id: 20260203193848.123307-2-umang.chheda@oss.qualcomm.com
> > prerequisite-patch-id: baf07fce333b86c35c3d4cefbba5800a519952a3
> > prerequisite-message-id: 20260217071420.2240380-1-mkuntuma@qti.qualcomm.com
> > prerequisite-patch-id: 74a76fd6a1129cdbbd32d91d2a119d693dba78a7
> > prerequisite-patch-id: f4a858f7e707c8e330daf2ea1f4da58b4da00f05
> >
>
> Why do you have so many dependencies? Why isn't this merged there?
>
The following changes will be included in the next revision of the
dependent patch series: https://lore.kernel.org/all/20260226111322.250176-1-quic_mkuntuma@quicinc.com/
> Was this patch tested (see internal testing guideline) prior to posting?
>
yes, changes were tested together with the dependent patches before posting
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v11] arm64: dts: imx8ulp: Add CSI and ISI Nodes
From: guoniu.zhou @ 2026-03-27 7:11 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel, Frank Li
Cc: linux-media, devicetree, imx, linux-arm-kernel, linux-kernel,
G . N . Zhou
From: Guoniu Zhou <guoniu.zhou@nxp.com>
The CSI-2 in the i.MX8ULP is almost identical to the version present
in the i.MX8QXP/QM and is routed to the ISI. Add both the ISI and CSI
nodes and mark them as disabled by default since capture is dependent
on an attached camera.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
---
This was previously sent as patch 5/5 in the v10 series based on media
tree [1]. Patches 1-4 have already been applied to linux-next tree, but
not yet to media tree . This v11 addresses the conflict with the removal
of include/dt-bindings/reset/imx8ulp-pcc-reset.h.
Changes in v11:
- Rebased on latest media/next
- Removed #include <dt-bindings/reset/imx8ulp-pcc-reset.h> which was
deleted by Rob's dt-bindings cleanup series [2]
- Replaced reset macros with numeric values and added comments to
document the reset indices
- Link to v10: https://lore.kernel.org/r/20251205-csi2_imx8ulp-v10-5-190cdadb20a3@nxp.com
Changes in v6:
- Update compatible string in dts for csi node.
- Link to v5: https://lore.kernel.org/r/20250901-csi2_imx8ulp-v5-4-67964d1471f3@nxp.com
Changes in v4:
- Change csr clock name to pclk which is more readability.
- Link to v3: https://lore.kernel.org/all/20250825-csi2_imx8ulp-v3-4-35885aba62bc@nxp.com
Changes in v3:
- Change pclk clock name to csr to match IP port name.
- Link to v2: https://lore.kernel.org/all/20250822-csi2_imx8ulp-v2-4-26a444394965@nxp.com
Changes in v2:
- Move dts patch as the last one.
- Add "fsl,imx8qxp-mipi-csi2" to compatible string list of csi node.
- Link to v1: https://lore.kernel.org/all/20250812081923.1019345-3-guoniu.zhou@oss.nxp.com
[1] https://lore.kernel.org/all/20251205-csi2_imx8ulp-v10-0-190cdadb20a3@nxp.com/
[2] https://lore.kernel.org/all/20251212231203.727227-1-robh@kernel.org/
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 9b5d98766512..84f05c83c702 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -859,6 +859,72 @@ spdif: spdif@2dab0000 {
dma-names = "rx", "tx";
status = "disabled";
};
+
+ isi: isi@2dac0000 {
+ compatible = "fsl,imx8ulp-isi";
+ reg = <0x2dac0000 0x10000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc5 IMX8ULP_CLK_ISI>,
+ <&cgc2 IMX8ULP_CLK_LPAV_AXI_DIV>;
+ clock-names = "axi", "apb";
+ power-domains = <&scmi_devpd IMX8ULP_PD_ISI>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ isi_in: endpoint {
+ remote-endpoint = <&mipi_csi_out>;
+ };
+ };
+ };
+ };
+
+ mipi_csi: csi@2daf0000 {
+ compatible = "fsl,imx8ulp-mipi-csi2";
+ reg = <0x2daf0000 0x10000>,
+ <0x2dad0000 0x10000>;
+ clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ clock-names = "core", "esc", "ui", "pclk";
+ assigned-clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ assigned-clock-parents = <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV1>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV2>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD0_DIV1>;
+ assigned-clock-rates = <200000000>,
+ <80000000>,
+ <100000000>,
+ <79200000>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_MIPI_CSI>;
+ resets = <&pcc5 5>, /* PCC5_CSI_REGS_SWRST */
+ <&pcc5 6>; /* PCC5_CSI_SWRST> */
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_csi_out: endpoint {
+ remote-endpoint = <&isi_in>;
+ };
+ };
+ };
+ };
};
gpiod: gpio@2e200000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-27 7:23 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-2-jian.hu@amlogic.com>
On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>
> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
From: Krzysztof Kozlowski @ 2026-03-27 7:26 UTC (permalink / raw)
To: Sumit Gupta
Cc: treding, jonathanh, robh, krzk+dt, conor+dt, devicetree,
linux-tegra, linux-kernel, bbasu
In-Reply-To: <20260325125726.2694144-2-sumitg@nvidia.com>
On Wed, Mar 25, 2026 at 06:27:25PM +0530, Sumit Gupta wrote:
> Add compatible strings for CBB v2.0 based fabrics in Tegra238:
> - nvidia,tegra238-ape-fabric
> - nvidia,tegra238-aon-fabric
> - nvidia,tegra238-bpmp-fabric
> - nvidia,tegra238-cbb-fabric
So you just pasted diff contents here. What's the point?
Comit msg is not a copy of the diff. We can read the diff.
Drop.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: dmaengine: Add SpacemiT K1 DMA request definitions
From: Krzysztof Kozlowski @ 2026-03-27 7:27 UTC (permalink / raw)
To: Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk
In-Reply-To: <20260326-k3-pdma-v2-1-ca94ca7bb595@linux.spacemit.com>
On Thu, Mar 26, 2026 at 04:17:16PM +0800, Troy Mitchell wrote:
> From: Guodong Xu <guodong@riscstar.com>
>
> Add the DMA request numbers for non-secure peripherals of the K1 SoC
> from SpacemiT.
>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> ---
No changelog - neither here, nor in commit msg.
> include/dt-bindings/dma/k1-pdma.h | 56 +++++++++++++++++++++++++++++++++++++++
So previous review applies, no? Was there such?
> 1 file changed, 56 insertions(+)
>
> diff --git a/include/dt-bindings/dma/k1-pdma.h b/include/dt-bindings/dma/k1-pdma.h
> new file mode 100644
> index 000000000000..061748c177dc
> --- /dev/null
> +++ b/include/dt-bindings/dma/k1-pdma.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * This header provides DMA request number for non-secure peripherals of
> + * SpacemiT K1 PDMA.
> + *
> + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> + */
> +
> +#ifndef __DT_BINDINGS_DMA_K1_PDMA_H__
> +#define __DT_BINDINGS_DMA_K1_PDMA_H__
> +
> +#define K1_PDMA_UART0_TX 3
abstract IDs start from 0 or 1.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: dmaengine: Add SpacemiT K1 DMA request definitions
From: Krzysztof Kozlowski @ 2026-03-27 7:28 UTC (permalink / raw)
To: Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk
In-Reply-To: <20260326-k3-pdma-v2-1-ca94ca7bb595@linux.spacemit.com>
On Thu, Mar 26, 2026 at 04:17:16PM +0800, Troy Mitchell wrote:
> From: Guodong Xu <guodong@riscstar.com>
>
> Add the DMA request numbers for non-secure peripherals of the K1 SoC
> from SpacemiT.
>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> ---
> include/dt-bindings/dma/k1-pdma.h | 56 +++++++++++++++++++++++++++++++++++++++
Also, this is not a separate commit.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: dmaengine: Add SpacemiT K3 DMA request definitions
From: Krzysztof Kozlowski @ 2026-03-27 7:30 UTC (permalink / raw)
To: Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk,
liyeshan
In-Reply-To: <20260326-k3-pdma-v2-3-ca94ca7bb595@linux.spacemit.com>
On Thu, Mar 26, 2026 at 04:17:18PM +0800, Troy Mitchell wrote:
> From: liyeshan <yeshan.li@spacemit.com>
>
> Add device tree binding header for SpacemiT k3 DMA request numbers. This
Why?
> defines the DMA request mapping for non-secure peripherals including UART,
> I2C, SSP/SPI, CAN, and QSPI.
>
> Signed-off-by: liyeshan <yeshan.li@spacemit.com>
Name looks close to login name?
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> ---
> include/dt-bindings/dma/k3-pdma.h | 83 +++++++++++++++++++++++++++++++++++++++
I am already confused what is happening in this patchset - so which
device are you adding? K1 or K3?
> 1 file changed, 83 insertions(+)
>
> diff --git a/include/dt-bindings/dma/k3-pdma.h b/include/dt-bindings/dma/k3-pdma.h
> new file mode 100644
> index 000000000000..05541a9a9973
> --- /dev/null
> +++ b/include/dt-bindings/dma/k3-pdma.h
> @@ -0,0 +1,83 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * This header provides DMA request number for non-secure peripherals of
> + * SpacemiT K3 PDMA.
> + *
> + * Copyright (c) 2025 SpacemiT
> + * Copyright (c) 2025 Guodong Xu <guodong@riscstar.com>
> + */
> +
> +#ifndef __DT_BINDINGS_DMA_K3_PDMA_H__
> +#define __DT_BINDINGS_DMA_K3_PDMA_H__
> +
> +/* UART DMA request numbers */
> +#define K3_PDMA_UART0_TX 3
This starts from 0 or 1.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: sound: Convert pcm3060 to DT schema
From: Kirill Marinushkin @ 2026-03-27 7:30 UTC (permalink / raw)
To: Padmashree S S, lgirdwood, broonie
Cc: robh, conor+dt, krzk+dt, devicetree, linux-sound, linux-kernel
In-Reply-To: <20260326183747.528754-1-padmashreess2006@gmail.com>
Good day Padmashree,
i received your patch, and support your interest to keep the driver
documentation
up-to-date! I would kindly ask you to give me some time to get
up to speed with the context of the documentation change.
You may expect to hear back from me next week.
At the same time, i don't want to block any progress.
If you receive enough approvals from the other members of the community,
please feel free to proceed without my feedback.
Best regards,
Kirill Marinushkin
On 3/26/26 7:37 PM, Padmashree S S wrote:
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> .../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt b/Documentation/devicetree/bindings/sound/pcm3060.txt
> deleted file mode 100644
> index 97de66932d44..000000000000
> --- a/Documentation/devicetree/bindings/sound/pcm3060.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -PCM3060 audio CODEC
> -
> -This driver supports both I2C and SPI.
> -
> -Required properties:
> -
> -- compatible: "ti,pcm3060"
> -
> -- reg : the I2C address of the device for I2C, the chip select
> - number for SPI.
> -
> -Optional properties:
> -
> -- ti,out-single-ended: "true" if output is single-ended;
> - "false" or not specified if output is differential.
> -
> -Examples:
> -
> - pcm3060: pcm3060@46 {
> - compatible = "ti,pcm3060";
> - reg = <0x46>;
> - ti,out-single-ended = "true";
> - };
> diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> new file mode 100644
> index 000000000000..ceb6f044b196
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCM3060 audio CODEC
> +
> +maintainers:
> + - Kirill Marinushkin <k.marinushkin@gmail.com>
> +
> +properties:
> + compatible:
> + const: ti,pcm3060
> +
> + reg:
> + maxItems: 1
> + description: |
> + The I2C address of the device
> + or SPI chip select number.
> +
> + ti,out-single-ended:
> + type: boolean
> + description: |
> + If present, the output is single-ended.
> + If absent, the output is differential.
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcm3060: audio-codec@46 {
> + compatible = "ti,pcm3060";
> + reg = <0x46>;
> + ti,out-single-ended;
> + };
> + };
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: sound: Convert pcm3060 to DT schema
From: Krzysztof Kozlowski @ 2026-03-27 7:32 UTC (permalink / raw)
To: Padmashree S S
Cc: k.marinushkin, lgirdwood, broonie, robh, conor+dt, krzk+dt,
devicetree, linux-sound, linux-kernel
In-Reply-To: <20260326183747.528754-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 12:07:47AM +0530, Padmashree S S wrote:
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
And this should go to commit log forever? Why?
No, this wasn't ever reviewed as requested by the GSoC process.
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> .../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt b/Documentation/devicetree/bindings/sound/pcm3060.txt
> deleted file mode 100644
> index 97de66932d44..000000000000
> --- a/Documentation/devicetree/bindings/sound/pcm3060.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -PCM3060 audio CODEC
> -
> -This driver supports both I2C and SPI.
> -
> -Required properties:
> -
> -- compatible: "ti,pcm3060"
> -
> -- reg : the I2C address of the device for I2C, the chip select
> - number for SPI.
> -
> -Optional properties:
> -
> -- ti,out-single-ended: "true" if output is single-ended;
> - "false" or not specified if output is differential.
> -
> -Examples:
> -
> - pcm3060: pcm3060@46 {
> - compatible = "ti,pcm3060";
> - reg = <0x46>;
> - ti,out-single-ended = "true";
> - };
> diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> new file mode 100644
> index 000000000000..ceb6f044b196
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/pcm3060.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCM3060 audio CODEC
> +
> +maintainers:
> + - Kirill Marinushkin <k.marinushkin@gmail.com>
> +
> +properties:
> + compatible:
> + const: ti,pcm3060
> +
> + reg:
> + maxItems: 1
> + description: |
> + The I2C address of the device
> + or SPI chip select number.
Nah, wasn't reviewed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: twl: Reference converted YAML schemas for subnodes
From: Krzysztof Kozlowski @ 2026-03-27 7:37 UTC (permalink / raw)
To: Jihed Chaibi
Cc: lee, andreas, robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260325095016.48752-1-jihed.chaibi.dev@gmail.com>
On Wed, Mar 25, 2026 at 10:50:16AM +0100, Jihed Chaibi wrote:
> Now that all TWL subnode bindings (audio, keypad, twl4030-usb, gpio,
> usb-comparator) have been converted to YAML and merged into mainline,
subject and here: drop YAML. There are no YAML schemas.
> update the parent ti,twl.yaml to properly reference them via $ref.
> Previously these subnodes used inline compatible definitions with
> additionalProperties: true, which meant properties defined in the
> subnode schemas were not being validated. Replace them with $ref to the
No, they were validated by their child device schemas. Everything was
correct and expected.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
From: Krzysztof Kozlowski @ 2026-03-27 7:51 UTC (permalink / raw)
To: Biswapriyo Nath
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka, linux-arm-msm,
devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260325-ginkgo-add-usb-ir-vib-v1-4-446c6e865ad6@gmail.com>
On Wed, Mar 25, 2026 at 06:07:27PM +0000, Biswapriyo Nath wrote:
> 30 duty cycle for IR transmitter is used in Xiaomi Redmi Note 8 (ginkgo).
>
> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> ---
> Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> index 72cadebf6e3..0297bfbb275 100644
> --- a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> +++ b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> @@ -25,7 +25,7 @@ properties:
>
> duty-cycle:
> $ref: /schemas/types.yaml#/definitions/uint8
> - enum: [50, 60, 70, 75, 80, 90]
> + enum: [30, 50, 60, 70, 75, 80, 90]
Hm, why is this enum, instead of 1-99, in the first place?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-03-27 7:54 UTC (permalink / raw)
To: Bryan O'Donoghue, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <fedd369d-a0fc-4dbd-9862-3b6e3a403764@linaro.org>
On 3/27/26 03:03, Bryan O'Donoghue wrote:
> On 26/03/2026 14:49, Vladimir Zapolskiy wrote:
>> Here the description of hardware is done, and my point is that the new
>> PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
>> possible to give a proper description of hardware without this invention.
>
> Perhaps I'm not understanding you.
You are welcome to ask questions, it may save time.
> If we use PHY_TYPE_DPHY
>
> include/dt-bindings/phy/phy.h:#define PHY_TYPE_DPHY 10
>
> We _must_ then add SPLIT_MODE to phy.h if/when we implement that
> support.
I don't think it is the must.
> Which means successfully arguing the toss of weather SPLIT_MODE
> is a Qualcommism - a vendor specific mode or not.
>
> <&phy PHY_TYPE_DPHY> committed to an upstream dts will then need to be
> supported perpetually.
>
First of all, nobody says/defines that the phy type is mandatory to be
present in the cell at all, for instance it could be provided over bus-type
property of media endpoints, and a connected sensor unavoidably postulates
the value of this property.
> So for example qrb5615 - kona/rb5 support split mode.
>
> Pretend go with <&phy PHY_TYPE_DPHY>; and retrofit individual PHY
> support to this platform.
>
> Grand so far.
>
> The pretend we want to switch from one sensor to a split-mode sensor on
> the existing mezzanine.
You may think how it should be done, it's been asked for a while to provide
a complete valid example, it may help you to get a better understanding of
the whole picture.
>
> Then we need a representation of split mode in phy.h to represent that
> in DT.
Some kind of split mode representation should be in DT, it does not
mean that it sticks to phy.h or whatever else. Lanes (and bus-type) are
described under endpoint device tree nodes, this is totally sufficient
to separate what you call "a split mode". So, it excludes phy.h.
>
> <&phy PHY_TYPE_DPHY_SPLIT_MODE>;
>
> Except split-mode is not an appropriate mode to define in phy.h since it
> is vendor specific - even if a few vendors support it, its not a generic
> PHY mode.
>
> Hence we would have an enormously difficult time justifying adding that
> mode to phy.h and rightly so.
We still discuss a hardware description, it should not be problematic to
provide descriptions of regular DPHY and what you call 'split mode' DPHY
without any new extentions of the existing dt bindings.
>>> https://review.lineageos.org/c/LineageOS/
>>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>>> cam_csiphy/cam_csiphy_core.c#b285
>>>
>>> There is disjunction all over this file depending on the mode.
>>>
>>> https://review.lineageos.org/c/LineageOS/
>>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>>> cam_csiphy/cam_csiphy_core.c#b767
>
>
> OTOH
>
> - SPLIT_MODE will certainly require _both_ separate init sequences
> and specific logical disjunction for additional configuration steps
> lane-assignment and masking, etc.
>
> - That phy.h isn't the right location for SPLIT_MODE as its vendor
> specific. Just look at the modes we have for the USB PHYs
> same logic => include/dt-bindings/phy/phy-qcom-qmp.h same
> raison d'être
>
> - And that specifying PHY_TYPE_DPHY now binds us into an ABI that we
> cannot subsequently change - it will not be possible to introduce
> include/dt-bindings/phy/phy-qcom-mipi-csi2.h later on with our mode
>
> So therefore include/dt-bindings/phy/phy-qcom-mipi-csi2.h + PHY modes is
> the logical outcome.
>
Unnecessary extention of the dt bindings ABI is not needed to complete
the task.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 04/22] dt-bindings: dma: renesas,rz-dmac: Document optional DMA ACK cell
From: Geert Uytterhoeven @ 2026-03-27 8:00 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Vinod Koul, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, magnus.damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu.Beznea, Biju Das, Fabrizio Castro, Prabhakar Mahadev Lad,
John Madieu, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
linux-sound@vger.kernel.org
In-Reply-To: <TY6PR01MB1737720136E84FAF590F637C4FF56A@TY6PR01MB17377.jpnprd01.prod.outlook.com>
Hi John,
On Thu, 26 Mar 2026 at 23:42, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > On Thu, 19 Mar 2026 at 16:55, John Madieu <john.madieu.xa@bp.renesas.com>
> > wrote:
> > > Some peripherals on RZ/V2H, RZ/V2N, and RZ/G3E SoCs require explicit
> > > ACK signal routing through the ICU. Document the optional second cell
> > > in the DMA specifier for specifying the ACK signal number.
> > >
> > > The first cell remains unchanged and specifies the encoded MID/RID and
> > > channel configuration. The optional second cell specifies the DMA ACK
> > > signal number for peripherals requiring level-based handshaking.
> > >
> > > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > Just a quick head-up, as I haven't read the actual secion in the
> > documentation yet.
> >
> > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > @@ -63,17 +63,27 @@ properties:
> > > - const: register
> > >
> > > '#dma-cells':
> > > - const: 1
> > > - description:
> > > + description: |
> > > The cell specifies the encoded MID/RID or the REQ No values of
> > > the DMAC port connected to the DMA client and the slave channel
> > > configuration parameters.
> > > + Use 1 cell for basic DMA configuration.
> > > + Use 2 cells when DMA ACK signal routing through ICU is required
> > > + (RZ/V2H, RZ/V2N, RZ/G3E audio peripherals such as SSIU, SPDIF,
> > SRC, DVC).
> > > +
> > > + First cell:
> > > bits[0:9] - Specifies the MID/RID or the REQ No value
> > > bit[10] - Specifies DMA request high enable (HIEN)
> > > bit[11] - Specifies DMA request detection type (LVL)
> > > bits[12:14] - Specifies DMAACK output mode (AM)
> > > bit[15] - Specifies Transfer Mode (TM)
> > >
> > > + Second cell (optional, when #dma-cells = <2>):
> > > + bits[6:0] - DMA acknowledge signal number (from ICU ACK table),
> > > + where 0 is a valid signal number.
> > > + Required for peripherals using level-based DMA
> > > + handshaking (SSIU, SPDIF, RSPI, SCU, ADC, PDM).
> >
> > How do you expect this to work? #dma-cells applies to all DMA consumers of
> > this provider, and these SoCs already have DMA users relying on #dma-cells
> > being one.
>
> Indeed.
>
> > In addition, you cannot have optional cells: if #dma-cells is two, then
> > all consumers must supply two cells (of course we could switch all of them
> > to two cells at once). However, as zero is a valid signal number, we
> > cannot use that as a dummy when no DMA acknowledge signal number is needed
> > (we could use e.g. 0xffffffff instead).
> >
> > Is there any other way to provide this information?
> > E.g. could we have a table in the driver that contains this info for the
> > (presumably few) MID/RID values that need it?
>
> There are actually 89 entries, and I could identify 3 peripheral
> group with linear ACK assignments. Thus instead of static array
> we would get a simple function handling 3 req_no ranges.
>
> Something like:
>
> /*
> * Map MID/RID request number (bits[0:9] of DMA specifier) to the ICU
> * DMA ACK signal number, per RZ/G3E hardware manual Table 4.6-28.
> *
> * Three peripheral groups with linear ACK assignment:
> *
> * PFC external DMA pins (DREQ0..DREQ4):
> * req_no 0x000-0x004 -> ACK No. 84-88 (ack = req_no + 84)
> *
> * SSIU BUSIFs (ssip00..ssip93):
> * req_no 0x161-0x198 -> ACK No. 28-83 (ack = req_no - 0x145)
> *
> * SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
> * req_no 0x199-0x1b4 -> ACK No. 0-27 (ack = req_no - 0x199)
> */
> static int rz_dmac_get_ack_no(const struct rz_dmac_info *info, u16 req_no)
> {
> if (!info->icu_register_dma_ack)
> return -EINVAL;
>
> /* PFC external DMA pins: ACK No. 84-88 */
> if (req_no <= 0x004)
> return req_no + 84;
>
> /* SSIU BUSIFs: ACK No. 28-83 */
> if (req_no >= 0x161 && req_no <= 0x198)
> return req_no - 0x145;
>
> /* SPDIF + SCU SRC + DVC: ACK No. 0-27 */
> if (req_no >= 0x199 && req_no <= 0x1b4)
> return req_no - 0x199;
>
> return -EINVAL;
> }
Nice!
Note that you can use ranges in case statements:
git grep "case.*\.\.\."
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v9 0/2] Add ITE IT61620 MIPI DSI to HDMI bridge driver
From: Pet Weng @ 2026-03-27 8:02 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-kernel, Hermes Wu, Kenneth Hung,
Pet Weng, Jau-chih Tseng, Pin-yen Lin, Krzysztof Kozlowski,
Dmitry Baryshkov
This patch series adds support for the ITE IT61620 MIPI DSI to HDMI
bridge chip.
The IT61620 is an I2C-controlled bridge that receives MIPI DSI input
and outputs HDMI signals. A single-port MIPI DSI input is converted to
an HDMI 1.4 output. This series introduces:
- A device tree binding YAML file describing the hardware
- A new DRM bridge driver implementing the basic functionality
Signed-off-by: Pet Weng <pet.weng@ite.com.tw>
---
Changes in v9:
- Fix commit message wrapping to follow kernel style
- Run checkpatch.pl and address reported issues
- Restore Reviewed-by from Krzysztof as the change is non-functional
- Link to v8: https://lore.kernel.org/r/20260320-it61620-0714-v8-0-0e70271cf5a9@ite.com.tw
Changes in v8:
- dt-binding:
1. Clarify the hardware differences between IT6162 and IT61620 in the
description (IT61620 is single-port and lacks an internal MCU). [Krzysztof]
2. Dropped Reviewed-by from Krzysztof due to description changes.
- Call drm_atomic_helper_connector_hdmi_clear_audio_infoframe() in audio
shutdown path [Dmitry]
- Link to v7: https://lore.kernel.org/r/20260313-it61620-0714-v7-0-36a16dc036d6@ite.com.tw
Changes in v7:
- The dt-bindings were previously reviewed by Krzysztof Kozlowski.
- drm/bridge: [Dmitry]
1. drop redundant register access wrappers and use regmap APIs directly
2. use drm_dbg_kms() instead of drm_dbg() when printing display timing information
3. use drm_display_mode directly for video timing
4. add helper for writing 16-bit timing registers
5. simplify HDMI interrupt handling
6. add mono audio support
7. program audio parameters directly
8. inline audio infoframe disable logic
- MAINTAINERS: squash to driver patch [Dmitry]
- Link to v6: https://lore.kernel.org/r/20260130-it61620-0714-v6-0-70afa65923b5@ite.com.tw
Changes in v6:
- In patch 1 [Luca]
1. Fix a typo in the commit message.
2. Remove redundant assignment of bridge.funcs, which is already set by
devm_drm_bridge_alloc().
- Link to v5: https://lore.kernel.org/r/20251222-it61620-0714-v5-0-afb6479ad3ca@ite.com.tw
Changes in v5:
- Fix dt_binding_check errors by adding missing unevaluatedProperties constraints
for port and endpoint nodes in the device tree binding. [Rob]
- Link to v4: https://lore.kernel.org/r/20251216-it61620-0714-v4-0-9d2fea7847ae@ite.com.tw
Changes in v4:
- In patch 1 [Krzysztof]
1. Remove redundant "description" fields from interrupts and regulators
2. Drop pinctrl-names and pinctrl-0; driver does not require them
3. Remove port/endpoint properties already covered by video interfaces schema
4. Fix example indentation to 4 spaces for readability
- In patch 2 [Jani]
1. Use connector->display_info from DRM helper instead of parsing EDID manually
- In patch 2 [Dmitry]
1. Remove redundant powered check in reg access
2. Use TMDS character rate instead of pixel clock for N/CTS
3. Use consistent lowercase naming for tmds.
4. Use test_bit() instead of custom bit-test helper
5. Use tmds_char_rate_valid instead of custom mode_valid
6. Use custom EDID read instead of DDC bus for segment handling
7. Drop redundant atomic feature check
8. Pass flags directly to drm_bridge_attach()
9. Check DRM_BRIDGE_ATTACH_NO_CONNECTOR flag before drm_bridge_attach()
10. Short-circuit HPD update if connector status unchanged
11. Remove unnecessary NULL check for connector state
12. Rename cached_edid to edid since it's no longer cached
13. Remove redundant sample rate checks; rely on hdmi-codec validation
14. Remove unsupported 18-bit audio sample size; rely on hdmi-codec
15. Remove unnecessary fmt switch; rely on hdmi-codec defaults
16. Check and propagate errors from it61620_audio_update_hw_params instead of
ignoring them
- In patch 3 [Krzysztof]
1. Remove unnecessary T: field pointing to git; subsystem already defines it
- Link to v3: https://lore.kernel.org/r/20251009-it61620-0714-v3-0-5d682d028441@ite.com.tw
Changes in v3:
- Wrapped description lines to comply with 80-character line length limit
in patch 1. [Rob]
- Renamed node from "it61620@58" to "bridge@58" in patch 1. [Rob]
- Add port@2 for I2S audio input in patch 1. [Dmitry]
- Updated the Kconfig dependency from CRYPTO and CRYPTO_HASH to
CRYPTO_LIB_SHA1 in patch 2. [Eric]
- In patch 2 [Dmitry]
1. Audio and InfoFrame
- Rename audfmt to i2s_input_format for clarity.
- Remove unused infoframe[HDMI_INFOFRAME_SIZE(AUDIO)].
2. Platform data and structure
- Drop platform data usage; migrate members into struct it61620
3. Code organization
- Reorder functions to avoid the need for forward declarations.
- Add static inline to small helper functions
(e.g. bridge_to_it61620()).
4. HDCP handling
- Make HDCP enable/disable conditional on conn_state->content_protection.
- Report authentication result using drm_hdcp_update_content_protection().
5. Error handling
- Replace manual error path with dev_err_probe().
6. Power management
- Inline suspend/resume callbacks.
- Use DEFINE_RUNTIME_DEV_PM_OPS() instead of explicit struct definition.
7. Bridge callbacks
- Drop empty bridge_detach().
- Inline it61620_bridge_mode_valid().
8. EDID handling
- Remove unnecessary cached EDID duplication.
9. Mode set and pixel clock
- Move mode handling to atomic_enable().
- Keep only pixelclock for future N/CTS audio calculations.
10. Logging
- Replace noisy drm_err() calls with drm_dbg().
11. InfoFrame support
- Add support for SPD and Vendor InfoFrames.
- Link to v2: https://lore.kernel.org/r/20250828-it61620-0714-v2-0-586f5934d5f8@ite.com.tw
Changes in v2:
- Call the sha1() library function instead of using the crypto_shash
"sha1" in patch 2.
- Rewrite it61620_hdmi_ddc_wait() with readx_poll_timeout() in patch 2. [Pin-yen]
- Rewrite it61620_hdmi_hdcp_wait_ksv_list() with readx_poll_timeout() in
patch 2.
- Replace interrupts-extended with interrupts in patch 1. [Rob]
- Replace dsi-lanes with the standard property data-lanes from the graph
binding. [Rob]
- Replace "#/$defs/port-base" with "#/properties/port" in patch 1. [Rob]
- Drop unused labels and "hdmi" for the node name. [Rob]
- Drop status in patch 1. [Rob]
- Link to v1: https://lore.kernel.org/r/20250714-it61620-0714-v1-0-3761164d0b98@ite.com.tw
---
Pet Weng (2):
dt-bindings: display: Add ITE IT61620 MIPI DSI to HDMI bridge
drm/bridge: Add ITE IT61620 MIPI DSI to HDMI bridge driver
.../bindings/display/bridge/ite,it61620.yaml | 152 ++
MAINTAINERS | 7 +
drivers/gpu/drm/bridge/Kconfig | 18 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ite-it61620.c | 2592 ++++++++++++++++++++
5 files changed, 2770 insertions(+)
---
base-commit: a42c0d615ad29e3e11b1c91f677bcabcb5dc8e13
change-id: 20250714-it61620-0714-ab4ab4ceff29
Best regards,
--
Pet Weng <pet.weng@ite.com.tw>
^ 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