* Re: [PATCH v1 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
From: Troy Mitchell @ 2026-03-31 6:24 UTC (permalink / raw)
To: 曹珊珊, Yixun Lan
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Troy Mitchell, Michael Opdenacker,
Guodong Xu, Hendrik Hamerlinck, Yangyu Chen, spacemit,
linux-riscv, devicetree, linux-kernel
In-Reply-To: <407ce3d77416bb2522b7906b0df3d5adf02c27ee.d811f619.24b1.431f.ad4d.c0bae1097eb9@feishu.cn>
On Tue Mar 31, 2026 at 2:15 PM CST, 曹珊珊 wrote:
>
>> From: "Yixun Lan"<dlan@kernel.org>
>> Date: Tue, Mar 31, 2026, 14:03
>> Subject: Re: [PATCH v1 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
>> To: "Sandie Cao"<sandie.cao@deepcomputing.io>
>> Cc: "Conor Dooley"<conor+dt@kernel.org>, "Emil Renner Berthing"<kernel@esmil.dk>, "Rob Herring"<robh@kernel.org>, "Krzysztof Kozlowski"<krzk+dt@kernel.org>, "Paul Walmsley"<paul.walmsley@sifive.com>, "Palmer Dabbelt"<palmer@dabbelt.com>, "Albert Ou"<aou@eecs.berkeley.edu>, "Heinrich Schuchardt"<heinrich.schuchardt@canonical.com>, "Troy Mitchell"<troy.mitchell@linux.spacemit.com>, "Michael Opdenacker"<michael.opdenacker@rootcommit.com>, "Guodong Xu"<guodong@riscstar.com>, "Hendrik Hamerlinck"<hendrik.hamerlinck@hammernet.be>, "Yangyu Chen"<cyy@cyyself.name>, <spacemit@lists.linux.dev>, <linux-riscv@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
I'm just confused as to why this appeared in the body.
- Troy
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: media: camss: Add qcom,sm6350-camss
From: Luca Weiss @ 2026-03-31 6:38 UTC (permalink / raw)
To: Vladimir Zapolskiy, Luca Weiss, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-media, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <fe00906e-fb06-44e3-985b-3d0e95839e43@linaro.org>
On Tue Mar 31, 2026 at 12:57 AM CEST, Vladimir Zapolskiy wrote:
> On 2/16/26 10:54, Luca Weiss wrote:
>> Add bindings for the Camera Subsystem on the SM6350 SoC.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> .../bindings/media/qcom,sm6350-camss.yaml | 471 +++++++++++++++++++++
>> 1 file changed, 471 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml
>> new file mode 100644
>> index 000000000000..96974d90d8c4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm6350-camss.yaml
>> @@ -0,0 +1,471 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/qcom,sm6350-camss.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SM6350 Camera Subsystem (CAMSS)
>> +
>> +maintainers:
>> + - Luca Weiss <luca.weiss@fairphone.com>
>> +
>> +description:
>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,sm6350-camss
>> +
>> + reg:
>> + maxItems: 24
>> +
>> + reg-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite
>> + - const: a5_csr
>> + - const: a5_qgic
>> + - const: a5_sierra
>> + - const: bps
>> + - const: camnoc
>> + - const: core_top_csr_tcsr
>> + - const: cpas_cdm
>> + - const: cpas_top
>> + - const: ipe
>> + - const: jpeg_dma
>> + - const: jpeg_enc
>> + - const: lrme
>> +
>> + clocks:
>> + maxItems: 39
>> +
>> + clock-names:
>> + items:
>> + - const: cam_axi
>> + - const: soc_ahb
>> + - const: camnoc_axi
>> + - const: core_ahb
>> + - const: cpas_ahb
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: vfe0_axi
>> + - const: vfe0
>> + - const: vfe0_cphy_rx
>> + - const: vfe0_csid
>> + - const: vfe1_axi
>> + - const: vfe1
>> + - const: vfe1_cphy_rx
>> + - const: vfe1_csid
>> + - const: vfe2_axi
>> + - const: vfe2
>> + - const: vfe2_cphy_rx
>> + - const: vfe2_csid
>> + - const: vfe_lite
>> + - const: vfe_lite_cphy_rx
>> + - const: vfe_lite_csid
>> + - const: bps
>> + - const: bps_ahb
>> + - const: bps_areg
>> + - const: bps_axi
>> + - const: icp
>> + - const: ipe0
>> + - const: ipe0_ahb
>> + - const: ipe0_areg
>> + - const: ipe0_axi
>> + - const: jpeg
>> + - const: lrme
>> +
>> + interrupts:
>> + maxItems: 18
>> +
>> + interrupt-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite
>> + - const: a5
>> + - const: cpas
>> + - const: cpas_cdm
>> + - const: jpeg_dma
>> + - const: jpeg_enc
>> + - const: lrme
>> +
>> + interconnects:
>> + maxItems: 4
>> +
>> + interconnect-names:
>> + items:
>> + - const: ahb
>> + - const: hf_mnoc
>> + - const: sf_mnoc
>> + - const: sf_icp_mnoc
>> +
>> + iommus:
>> + maxItems: 14
>> +
>> + power-domains:
>> + maxItems: 6
>> +
>> + power-domain-names:
>> + items:
>> + - const: ife0
>> + - const: ife1
>> + - const: ife2
>> + - const: top
>> + - const: bps
>> + - const: ipe
>
> I've lost the content, why 'top' is somewhere in the middle?
https://lore.kernel.org/linux-arm-msm/20260214-slick-ringtail-of-innovation-d8eecd@quoll/
>
>> +
>> + vdd-csiphy0-0p9-supply:
>> + description:
>> + Phandle to a 0.9V regulator supply to CSIPHY0.
>> +
>> + vdd-csiphy0-1p25-supply:
>> + description:
>> + Phandle to a 1.25V regulator supply to CSIPHY0.
>> +
>> + vdd-csiphy1-0p9-supply:
>> + description:
>> + Phandle to a 0.9V regulator supply to CSIPHY1.
>> +
>> + vdd-csiphy1-1p25-supply:
>> + description:
>> + Phandle to a 1.25V regulator supply to CSIPHY1.
>> +
>> + vdd-csiphy2-0p9-supply:
>> + description:
>> + Phandle to a 0.9V regulator supply to CSIPHY2.
>> +
>> + vdd-csiphy2-1p25-supply:
>> + description:
>> + Phandle to a 1.25V regulator supply to CSIPHY2.
>> +
>> + vdd-csiphy3-0p9-supply:
>> + description:
>> + Phandle to a 0.9V regulator supply to CSIPHY3.
>> +
>> + vdd-csiphy3-1p25-supply:
>> + description:
>> + Phandle to a 1.25V regulator supply to CSIPHY3.
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + description:
>> + CSI input ports.
>> +
>> + patternProperties:
>> + "^port@[0-3]$":
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> +
>> + description:
>> + Input port for receiving CSI data from a CSIPHY.
>> +
>> + properties:
>> + endpoint:
>> + $ref: video-interfaces.yaml#
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> +
>> + bus-type:
>> + enum:
>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>> +
>> + required:
>> + - data-lanes
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - clocks
>> + - clock-names
>> + - interrupts
>> + - interrupt-names
>> + - interconnects
>> + - interconnect-names
>> + - iommus
>> + - power-domains
>> + - power-domain-names
>> + - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/qcom,gcc-sm6350.h>
>> + #include <dt-bindings/clock/qcom,sm6350-camcc.h>
>> + #include <dt-bindings/interconnect/qcom,icc.h>
>> + #include <dt-bindings/interconnect/qcom,sm6350.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/media/video-interfaces.h>
>> + #include <dt-bindings/power/qcom-rpmpd.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + isp@acb3000 {
>> + compatible = "qcom,sm6350-camss";
>> +
>> + reg = <0x0 0x0acb3000 0x0 0x1000>,
>> + <0x0 0x0acba000 0x0 0x1000>,
>> + <0x0 0x0acc1000 0x0 0x1000>,
>> + <0x0 0x0acc8000 0x0 0x1000>,
>> + <0x0 0x0ac65000 0x0 0x1000>,
>> + <0x0 0x0ac66000 0x0 0x1000>,
>> + <0x0 0x0ac67000 0x0 0x1000>,
>> + <0x0 0x0ac68000 0x0 0x1000>,
>> + <0x0 0x0acaf000 0x0 0x4000>,
>> + <0x0 0x0acb6000 0x0 0x4000>,
>> + <0x0 0x0acbd000 0x0 0x4000>,
>> + <0x0 0x0acc4000 0x0 0x4000>,
>> + <0x0 0x0ac18000 0x0 0x3000>,
>> + <0x0 0x0ac00000 0x0 0x6000>,
>> + <0x0 0x0ac10000 0x0 0x8000>,
>> + <0x0 0x0ac6f000 0x0 0x8000>,
>> + <0x0 0x0ac42000 0x0 0x4600>,
>> + <0x0 0x01fc0000 0x0 0x40000>,
>> + <0x0 0x0ac48000 0x0 0x1000>,
>> + <0x0 0x0ac40000 0x0 0x1000>,
>> + <0x0 0x0ac87000 0x0 0xa000>,
>> + <0x0 0x0ac52000 0x0 0x4000>,
>> + <0x0 0x0ac4e000 0x0 0x4000>,
>> + <0x0 0x0ac6b000 0x0 0xa00>;
>> + reg-names = "csid0",
>> + "csid1",
>> + "csid2",
>> + "csid_lite",
>> + "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>> + "vfe0",
>> + "vfe1",
>> + "vfe2",
>> + "vfe_lite",
>> + "a5_csr",
>> + "a5_qgic",
>> + "a5_sierra",
>> + "bps",
>> + "camnoc",
>> + "core_top_csr_tcsr",
>> + "cpas_cdm",
>> + "cpas_top",
>> + "ipe",
>> + "jpeg_dma",
>> + "jpeg_enc",
>> + "lrme";
>> +
>> + clocks = <&gcc GCC_CAMERA_AXI_CLK>,
>> + <&camcc CAMCC_SOC_AHB_CLK>,
>> + <&camcc CAMCC_CAMNOC_AXI_CLK>,
>> + <&camcc CAMCC_CORE_AHB_CLK>,
>> + <&camcc CAMCC_CPAS_AHB_CLK>,
>> + <&camcc CAMCC_CSIPHY0_CLK>,
>> + <&camcc CAMCC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAMCC_CSIPHY1_CLK>,
>> + <&camcc CAMCC_CSI1PHYTIMER_CLK>,
>> + <&camcc CAMCC_CSIPHY2_CLK>,
>> + <&camcc CAMCC_CSI2PHYTIMER_CLK>,
>> + <&camcc CAMCC_CSIPHY3_CLK>,
>> + <&camcc CAMCC_CSI3PHYTIMER_CLK>,
>> + <&camcc CAMCC_IFE_0_AXI_CLK>,
>> + <&camcc CAMCC_IFE_0_CLK>,
>> + <&camcc CAMCC_IFE_0_CPHY_RX_CLK>,
>> + <&camcc CAMCC_IFE_0_CSID_CLK>,
>> + <&camcc CAMCC_IFE_1_AXI_CLK>,
>> + <&camcc CAMCC_IFE_1_CLK>,
>> + <&camcc CAMCC_IFE_1_CPHY_RX_CLK>,
>> + <&camcc CAMCC_IFE_1_CSID_CLK>,
>> + <&camcc CAMCC_IFE_2_AXI_CLK>,
>> + <&camcc CAMCC_IFE_2_CLK>,
>> + <&camcc CAMCC_IFE_2_CPHY_RX_CLK>,
>> + <&camcc CAMCC_IFE_2_CSID_CLK>,
>> + <&camcc CAMCC_IFE_LITE_CLK>,
>> + <&camcc CAMCC_IFE_LITE_CPHY_RX_CLK>,
>> + <&camcc CAMCC_IFE_LITE_CSID_CLK>,
>> + <&camcc CAMCC_BPS_CLK>,
>> + <&camcc CAMCC_BPS_AHB_CLK>,
>> + <&camcc CAMCC_BPS_AREG_CLK>,
>> + <&camcc CAMCC_BPS_AXI_CLK>,
>> + <&camcc CAMCC_ICP_CLK>,
>> + <&camcc CAMCC_IPE_0_CLK>,
>> + <&camcc CAMCC_IPE_0_AHB_CLK>,
>> + <&camcc CAMCC_IPE_0_AREG_CLK>,
>> + <&camcc CAMCC_IPE_0_AXI_CLK>,
>> + <&camcc CAMCC_JPEG_CLK>,
>> + <&camcc CAMCC_LRME_CLK>;
>> + clock-names = "cam_axi",
>> + "soc_ahb",
>> + "camnoc_axi",
>> + "core_ahb",
>> + "cpas_ahb",
>> + "csiphy0",
>> + "csiphy0_timer",
>> + "csiphy1",
>> + "csiphy1_timer",
>> + "csiphy2",
>> + "csiphy2_timer",
>> + "csiphy3",
>> + "csiphy3_timer",
>> + "vfe0_axi",
>> + "vfe0",
>> + "vfe0_cphy_rx",
>> + "vfe0_csid",
>> + "vfe1_axi",
>> + "vfe1",
>> + "vfe1_cphy_rx",
>> + "vfe1_csid",
>> + "vfe2_axi",
>> + "vfe2",
>> + "vfe2_cphy_rx",
>> + "vfe2_csid",
>> + "vfe_lite",
>> + "vfe_lite_cphy_rx",
>> + "vfe_lite_csid",
>> + "bps",
>> + "bps_ahb",
>> + "bps_areg",
>> + "bps_axi",
>> + "icp",
>> + "ipe0",
>> + "ipe0_ahb",
>> + "ipe0_areg",
>> + "ipe0_axi",
>> + "jpeg",
>> + "lrme";
>> +
>> + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 717 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 473 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 461 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 718 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 472 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 463 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 459 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 475 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 476 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "csid0",
>> + "csid1",
>> + "csid2",
>> + "csid_lite",
>> + "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>> + "vfe0",
>> + "vfe1",
>> + "vfe2",
>> + "vfe_lite",
>> + "a5",
>> + "cpas",
>> + "cpas_cdm",
>> + "jpeg_dma",
>> + "jpeg_enc",
>> + "lrme";
>> +
>> + interconnects = <&gem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
>> + &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>> + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
>> + &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
>> + <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
>> + &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
>> + <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
>> + &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
>> + interconnect-names = "ahb",
>> + "hf_mnoc",
>> + "sf_mnoc",
>> + "sf_icp_mnoc";
>> +
>> + iommus = <&apps_smmu 0x820 0xc0>,
>> + <&apps_smmu 0x840 0x0>,
>> + <&apps_smmu 0x860 0xc0>,
>> + <&apps_smmu 0x880 0x0>,
>> + <&apps_smmu 0xc40 0x20>,
>> + <&apps_smmu 0xc60 0x20>,
>> + <&apps_smmu 0xc80 0x0>,
>> + <&apps_smmu 0xca2 0x0>,
>> + <&apps_smmu 0xcc0 0x20>,
>> + <&apps_smmu 0xce0 0x20>,
>> + <&apps_smmu 0xd00 0x20>,
>> + <&apps_smmu 0xd20 0x20>,
>> + <&apps_smmu 0xd40 0x20>,
>> + <&apps_smmu 0xd60 0x20>;
>> +
>> + power-domains = <&camcc IFE_0_GDSC>,
>> + <&camcc IFE_1_GDSC>,
>> + <&camcc IFE_2_GDSC>,
>> + <&camcc TITAN_TOP_GDSC>,
>> + <&camcc BPS_GDSC>,
>> + <&camcc IPE_0_GDSC>;
>> + power-domain-names = "ife0",
>> + "ife1",
>> + "ife2",
>> + "top",
>> + "bps",
>> + "ipe";
>> +
>> + vdd-csiphy0-0p9-supply = <&vreg_l18a>;
>> + vdd-csiphy0-1p25-supply = <&vreg_l22a>;
>> + vdd-csiphy1-0p9-supply = <&vreg_l18a>;
>> + vdd-csiphy1-1p25-supply = <&vreg_l22a>;
>> + vdd-csiphy2-0p9-supply = <&vreg_l18a>;
>> + vdd-csiphy2-1p25-supply = <&vreg_l22a>;
>> + vdd-csiphy3-0p9-supply = <&vreg_l18a>;
>> + vdd-csiphy3-1p25-supply = <&vreg_l22a>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + csiphy0_ep: endpoint {
>> + data-lanes = <0 1 2 3>;
>> + bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
>> + remote-endpoint = <&sensor_ep>;
>> + };
>> + };
>> + };
>> + };
>> + };
>>
>
> Because CAMSS device tree nodes are far from being settled down, one
> more time I can just express my opinion that there is no good enough
> reason to describe all clocks and interconnects prematurely, anyway
Would be nice if the camss maintainers were aligned so that contributors
don't have to deal with mailing list conflicts over these fundamental
things.
It doesn't really make it fun to contribute if you get conflicting
opinions from two people that you should both value the opinion of
because they're maintainer.
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Thanks!
Regards
Luca
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
From: 曹珊珊 @ 2026-03-31 6:38 UTC (permalink / raw)
To: Troy Mitchell
Cc: Yixun Lan, Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Troy Mitchell, Michael Opdenacker,
Guodong Xu, Hendrik Hamerlinck, Yangyu Chen, spacemit,
linux-riscv, devicetree, linux-kernel
In-Reply-To: <DHGR42QJK86L.10IAY9CB3RZH5@linux.spacemit.com>
> On Tue Mar 31, 2026 at 2:15 PM CST, 曹珊珊 wrote:
> >
> >> From: "Yixun Lan"<dlan@kernel.org>
> >> Date: Tue, Mar 31, 2026, 14:03
> >> Subject: Re: [PATCH v1 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
> >> To: "Sandie Cao"<sandie.cao@deepcomputing.io>
> >> Cc: "Conor Dooley"<conor+dt@kernel.org>, "Emil Renner Berthing"<kernel@esmil.dk>, "Rob Herring"<robh@kernel.org>, "Krzysztof Kozlowski"<krzk+dt@kernel.org>, "Paul Walmsley"<paul.walmsley@sifive.com>, "Palmer Dabbelt"<palmer@dabbelt.com>, "Albert Ou"<aou@eecs.berkeley.edu>, "Heinrich Schuchardt"<heinrich.schuchardt@canonical.com>, "Troy Mitchell"<troy.mitchell@linux.spacemit.com>, "Michael Opdenacker"<michael.opdenacker@rootcommit.com>, "Guodong Xu"<guodong@riscstar.com>, "Hendrik Hamerlinck"<hendrik.hamerlinck@hammernet.be>, "Yangyu Chen"<cyy@cyyself.name>, <spacemit@lists.linux.dev>, <linux-riscv@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
> I'm just confused as to why this appeared in the body.
>
> - Troy
>
This was the format of my email sender.
I correct it now.
Thanks.
Sandie
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: can: mcp251xfd: add microchip,xstbyen property
From: Viken Dadhaniya @ 2026-03-31 6:45 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: mani, thomas.kopp, mailhol, robh, krzk+dt, conor+dt, andersson,
konradybcio, linusw, brgl, linux-can, devicetree, linux-kernel,
linux-arm-msm, linux-gpio, mukesh.savaliya, anup.kulkarni,
Conor Dooley
In-Reply-To: <20260323-surname-osmosis-3cceca19c824@spud>
Hi Marc,
Could you please let me know if the driver change looks acceptable to be merged?
Once merged, I will proceed with posting the device-tree change.
Thanks
Viken
On 3/24/2026 3:00 AM, Conor Dooley wrote:
> On Mon, Mar 23, 2026 at 09:37:24PM +0100, Marc Kleine-Budde wrote:
>> On 23.03.2026 19:30:00, Conor Dooley wrote:
>>>> diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
>>>> index 2d13638ebc6a..28e494262cd9 100644
>>>> --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
>>>> +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
>>>> @@ -44,6 +44,14 @@ properties:
>>>> signals a pending RX interrupt.
>>>> maxItems: 1
>>>>
>>>> + microchip,xstbyen:
>>>> + type: boolean
>>>> + description:
>>>> + If present, configure the INT0/GPIO0/XSTBY pin as transceiver standby
>>>> + control. The pin is driven low when the controller is active and high
>>>> + when it enters Sleep mode, allowing automatic standby control of an
>>>> + external CAN transceiver connected to this pin.
>>>
>>> What I don't understand from this patch is why a property for this is
>>> required.
>>> Why can't this mode be implied from the lack of rx-int-gpios or
>>> interrupts?
>>
>> The mcp251xfd has 2 GPIO pins. "rx-int-gpios" is for the other pin:
>> INT1/GPIO1. Also by default I don't want the controller to drive a pin
>> in a certain direction.
>
> Oke.
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Krzysztof Kozlowski @ 2026-03-31 6:47 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260330-upstream_i2c-v28-2-17bdae39c5cb@aspeedtech.com>
On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> Add aspeed,enable-dma boolean property to indicate that DMA is
> available for transfers on this I2C bus.
>
> Also add the aspeed,global-regs phandle to reference the AST2600
> global registers syscon node, containing the SoC-common I2C register
> set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> index de2c359037da..67b23d1a4cec 100644
> --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> @@ -37,6 +37,16 @@ properties:
> resets:
> maxItems: 1
>
> + aspeed,enable-dma:
> + type: boolean
> + description: Indicates this I2C controller instance has DMA capability.
Compatible implies that "I2C controller instance has DMA capability", no?
How two same devices, with exactly the same or compatible programming
model can have difference in the programming model for DMA (one lacks
it)?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Krzysztof Kozlowski @ 2026-03-31 6:48 UTC (permalink / raw)
To: Iker Pedrosa
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <20260330-orangepi-sd-card-uhs-v5-1-bd853604322d@gmail.com>
On Mon, Mar 30, 2026 at 10:38:02AM +0200, Iker Pedrosa wrote:
> Document pinctrl properties to support voltage-dependent pin
> configuration switching for UHS-I SD card modes.
>
> Add optional pinctrl-names property with two states:
> - "default": For 3.3V operation with standard drive strength
> - "state_uhs": For 1.8V operation with optimized drive strength
>
> These pinctrl states allow the SDHCI driver to coordinate voltage
> switching with pin configuration changes, ensuring proper signal
> integrity during UHS-I mode transitions.
>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> ---
> .../devicetree/bindings/mmc/spacemit,sdhci.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> index 9a055d963a7f0cdba4741c1e3e7269688dcd5f45..201ab97f0e88376a4680dcca7917e8b3172bd84a 100644
> --- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> @@ -44,6 +44,20 @@ properties:
> - const: axi
> - const: sdh
>
> + pinctrl-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum:
No, that's not enum but list. Look here:
> + - default
> + - state_uhs
Instead: uhs
> +
> + pinctrl-0:
> + description: Default pinctrl state for 3.3V operation
So first item must be default, not uhs
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Krzysztof Kozlowski @ 2026-03-31 6:58 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: <20260331005458.24010-2-jianhua.lin@mediatek.com>
On Tue, Mar 31, 2026 at 08:54:56AM +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.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
> 1 file changed, 36 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..601fe05b73e7 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,22 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + minItems: 1
> + maxItems: 2
Why jpgdec-smi alone is now valid? Drop these two.
> + 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.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 6:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: jk@codeconstruct.com.au, andriy.shevchenko@linux.intel.com,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Benjamin Herrenschmidt,
Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260331-fanatic-certain-bustard-fb13bc@quoll>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> > Add aspeed,enable-dma boolean property to indicate that DMA is
> > available for transfers on this I2C bus.
> >
> > Also add the aspeed,global-regs phandle to reference the AST2600
> > global registers syscon node, containing the SoC-common I2C register
> > set.
> >
> > These properties apply only to the AST2600 binding. Legacy DTs remain
> > unchanged.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> > ---
> > Changes in v28:
> > - update commit message correspond with aspeed,enable-dma.
> > - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> > description.
> > - Fix aspeed,enable-dma description to reflect hardware capability rather
> > than software behavior
> > Changes in v27:
> > - change aspeed,transfer-mode to aspeed,enable-dma.
> > ---
> > .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12
> ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > index de2c359037da..67b23d1a4cec 100644
> > --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > @@ -37,6 +37,16 @@ properties:
> > resets:
> > maxItems: 1
> >
> > + aspeed,enable-dma:
> > + type: boolean
> > + description: Indicates this I2C controller instance has DMA capability.
>
> Compatible implies that "I2C controller instance has DMA capability", no?
>
> How two same devices, with exactly the same or compatible programming
> model can have difference in the programming model for DMA (one lacks it)?
>
> Best regards,
> Krzysztof
Thanks your review.
All AST2600 I2C controller instances have DMA hardware.
I will remove the aspeed,enable-dma property and instead expose sysfs
attribute in driver to allow users to enable dma/buffer/byte.
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Jeremy Kerr @ 2026-03-31 7:00 UTC (permalink / raw)
To: Ryan Chen, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE6F267C60EEC34B6A75400F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Hi Ryan,
> All AST2600 I2C controller instances have DMA hardware.
> I will remove the aspeed,enable-dma property and instead expose sysfs
> attribute in driver to allow users to enable dma/buffer/byte.
Sounds reasonable, but before you do so, how are you planning to manage
the allocation of DMA channels across multiple i2c peripherals?
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 7/7] arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
From: Sakari Ailus @ 2026-03-31 7:02 UTC (permalink / raw)
To: Richard Acayan
Cc: David Heidelberg, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Tianshu Qiu, Robert Mader, phone-devel,
linux-arm-msm, devicetree, linux-media
In-Reply-To: <acsjH0tZ-jj7N7c5@rdacayan>
On Mon, Mar 30, 2026 at 09:27:59PM -0400, Richard Acayan wrote:
> On Tue, Mar 24, 2026 at 12:57:59PM +0200, Sakari Ailus wrote:
> > Hi David, Richard,
> >
> > On Tue, Mar 24, 2026 at 10:35:24AM +0100, David Heidelberg wrote:
> > >
> > >
> > > On 24/03/2026 03:05, Richard Acayan wrote:
> > > > On Fri, Mar 13, 2026 at 07:26:47PM +0100, David Heidelberg wrote:
> > > > > On 17/02/2026 01:27, Richard Acayan wrote:
> > > > > [...]
> > > > >
> > > > > > +&cci_i2c1 {
> > > > > > + camera@1a {
> > > > > > + compatible = "sony,imx355";
> > > > > > + reg = <0x1a>;
> > > > > > +
> > > > > > + clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > +
> > > > > > + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > + assigned-clock-rates = <19200000>;
> > > > >
> > > > > Extract from #sdm670-mainline:erebion.eu discussion:
> > > > > The imx355 can operate on 24 MHz (on both Pixel 3 and 3a), but Linux kernel
> > > > > driver can operate only with 19.2 MHz.
> > > > >
> > > > > I assume it would be worth it mention at least by comment here.
> > > >
> > > > This might set the series back because the devicetree isn't meant to be
> > > > written for specific software, but it's included in v11 because you
> > > > already asked twice.
> > > >
> > >
> > > I would say node with lower clock frequency is still much better than
> > > nothing or placeholder saying "i2c camera here". Instead we'll have small
> > > placeholder that value can be bumped to 24 MHz. Important is this can be
> > > easily improved when at least one consumer of the device-tree gains support.
> > >
> > > We have very scarce support of cameras on mobile phones in mainline, thus
> > > leaving a comment that HW can do 24 MHz is reasonable compromise IMHO.
> >
> > The bindings could document the supported frequency range.
> >
> > In DTS it may make sense to set the frequency the vendor uses as it may
> > affect the link frequencies (albeit I guess they're the same in this
> > case?).
>
> Is this review relevant to v11?
I'd think so: it doesn't mention the frequency should be 24 MHz.
--
Sakari Ailus
^ permalink raw reply
* Re: New default binding for PWM devices? [Was: Re: [PATCH] dt-bindings: timer: xlnx,xps-timer: Make PWM in example usable]
From: Uwe Kleine-König @ 2026-03-31 7:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Krzysztof Kozlowski, Sean Anderson, linux-kernel,
linux-pwm, devicetree, Chris Packham, Marek Vasut
In-Reply-To: <CAMuHMdXDZD6QAbKgny1utfYhagUEZ5pcgiDCTTfJKNVVZLOUYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
Hello Geert,
On Mon, Mar 30, 2026 at 02:12:47PM +0200, Geert Uytterhoeven wrote:
> On Sat, 7 Jun 2025 at 09:23, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> > On Fri, Jun 06, 2025 at 09:13:24AM -0500, Rob Herring wrote:
> > > reg:
> > > > maxItems: 1
> > > >
> > > > - '#pwm-cells': true
> > > > + '#pwm-cells':
> > > > + const: 3
> > > >
> > > > xlnx,count-width:
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > @@ -82,7 +83,7 @@ examples:
> > > > };
> > > >
> > > > timer@800f0000 {
> > > > - #pwm-cells = <0>;
> > > > + #pwm-cells = <3>;
> > > > clock-names = "s_axi_aclk";
> > > > clocks = <&zynqmp_clk 71>;
> > > > compatible = "xlnx,xps-timer-1.00.a";
> > > >
> > > > There is however one concern that I want to get resolved first to
> > > > prevent churn:
> > > >
> > > > In principle I think it's bad that a phandle to a PWM must contain a
> > > > period and flags specifying the polarity. For some use cases the period
> > > > might not matter or is implicitly given or more than one period length
> > > > is relevant.
> > >
> > > Why can't the period be 0 and no flags set if they aren't needed?
> >
> > I don't say they cannot, and probably that's the most sane option if
> > there is no fixed default period and flags and we're sticking to 3
> > cells.
>
> So zero should have been used for drivers/pwm/pwm-argon-fan-hat.c?
Do you mean #pwm-cells = <0>? Or period = flags = 0?
If the phandle wouldn't contain period and flags and so it would only be
used to identify the PWM to use and say nothing about how it is used,
then using #pwm-cells = <0> for PWM chips that only have a single PWM
would work fine.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Krzysztof Kozlowski @ 2026-03-31 7:05 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331012450.1298115-1-chancel.liu@nxp.com>
On Tue, Mar 31, 2026 at 10:24:50AM +0900, Chancel Liu wrote:
> Currently this binding only lists i2s and dsp_b formats that are used
> by existing sound cards. However, DT bindings should describe the full
> hardware capabilities rather than only the formats of current usage.
>
> The SAI audio controller of i.MX audio sound card supports multiple DAI
> formats, including:
> - i2s
> - left_j
> - right_j
> - dsp_a
> - dsp_b
> - pdm
> - msb
> - lsb
>
> Complete the full list of formats supported by i.MX audio sound card to
> ensure the binding correctly describes hardware.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: i2c: intel,ixp4xx-i2c: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-31 7:07 UTC (permalink / raw)
To: Shi Hao
Cc: andi.shyti, conor+dt, devicetree, krzk+dt, linux-i2c,
linux-kernel, robh
In-Reply-To: <20260330054439.9545-1-i.shihao.999@gmail.com>
On Mon, Mar 30, 2026 at 11:14:39AM +0530, Shi Hao wrote:
> Convert the IOP3xx and IXP4xx XScale bindings to DT schema. This
> conversion also adds the interrupts property, as it is used by the driver
> and existing DTS files but was not documented in the original binding.
>
> Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Krzysztof Kozlowski @ 2026-03-31 7:09 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260330094459.128648-2-m-shah@ti.com>
On Mon, Mar 30, 2026 at 03:14:58PM +0530, Moteen Shah wrote:
> The ti,j721e-system-controller binding currently only allows
> clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
> schema. However, the system controller on J721S2 also contains audio
J721S2 or AM62?
> reference clock controllers (ti,am62-audio-refclk) that use the same
> clock-controller@XXXX naming pattern.
>
> Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
> or audio-refclk schemas using a oneOf constraint.
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> .../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> index f3bd0be3b279..d5d84a8f1257 100644
> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> @@ -53,9 +53,11 @@ patternProperties:
>
> "^clock-controller@[0-9a-f]+$":
> type: object
> - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + oneOf:
> + - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
Alphanumerical order.
There is no ti,am62 in the top level compatibles, so why am62 is here?
Top level has j721s2 but this ti,am62-audio-refclk.yaml only am62.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 7:09 UTC (permalink / raw)
To: Jeremy Kerr, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <09cbc12bea5707f794e139ea1bfafac82c2d2c12.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> Hi Ryan,
>
> > All AST2600 I2C controller instances have DMA hardware.
> > I will remove the aspeed,enable-dma property and instead expose sysfs
> > attribute in driver to allow users to enable dma/buffer/byte.
>
> Sounds reasonable, but before you do so, how are you planning to manage the
> allocation of DMA channels across multiple i2c peripherals?
>
The AST2600 I2C hardware has only one can use DMA at a time.
To avoid the complexity of managing DMA channel contention,
I plan to use buffer mode by default for all controllers, which still provides
better performance than byte mode without requiring DMA channel allocation.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: soc: renesas: add MFIS binding documentation
From: Wolfram Sang @ 2026-03-31 7:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Geert Uytterhoeven, linux-renesas-soc, linux-kernel, Jassi Brar,
Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree
In-Reply-To: <c46357c9-8cf4-45ec-8b48-8cf979de2e98@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
> I did not get the driver so I cannot verify that. What sort of Linux ABI
> does this bind?
In case you mean this as unanswered questions to v1: This describes the
device specific second mbox cell. Like Tegra does it here (even with
shifts instead of plain numbers):
include/dt-bindings/mailbox/tegra186-hsp.h
But all this has been said before and you got the driver as well in v2.
I really have no idea what is still missing?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: Xianwei Zhao @ 2026-03-31 7:10 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <CAFBinCD1GPP82MEBDHg3BwCJg6JY5k2HksEt+kCB=YjnYTO7Tw@mail.gmail.com>
Hi Martin,
I confirmed with Junyi Zhao that the current implementation counts
from zero, so this submission is correct.
We agree this should be fixed and will address it in a follow-up patch.
Thanks for pointing it out.
On 2026/3/31 05:54, Martin Blumenstingl wrote:
> Hi Xianwei Zhao,
>
> thanks for your contribution!
>
> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
> There is an old report that got lost, stating that the current
> pwm-meson driver has an off-by-one error with the hi and lo fields:
> [0]
> Since you are working on bringing up a new platform: is this something
> you can verify in your lab?
> To be clear: I'm not expecting you to work on this ad-hoc or bring a
> patch into this series. However, it would be great if you could verify
> if the findings from [0] are correct and send an updated patch in
> future.
>
> Thank you and best regards
> Martin
^ permalink raw reply
* [PATCH v2 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-03-31 7:10 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
In-Reply-To: <20260331034423.67142-1-sandie.cao@deepcomputing.io>
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is based on riscv-dt-for-next.
v2:
- Patch 1:
Use formal format user name.
- Patch 2:
Use formal format user name.
Add Reviewed-by from Troy Mitchell.
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
3 files changed, 30 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: 4a1739c30fc66a59450c1f78923f94607e786882
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: can: mcp251xfd: add microchip,xstbyen property
From: Marc Kleine-Budde @ 2026-03-31 7:10 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: mani, thomas.kopp, mailhol, robh, krzk+dt, conor+dt, andersson,
konradybcio, linusw, brgl, linux-can, devicetree, linux-kernel,
linux-arm-msm, linux-gpio, mukesh.savaliya, anup.kulkarni,
Conor Dooley
In-Reply-To: <d4e092d6-5d9e-49a4-88d0-c02e2f17f36b@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
On 31.03.2026 12:15:26, Viken Dadhaniya wrote:
> Could you please let me know if the driver change looks acceptable to be merged?
> Once merged, I will proceed with posting the device-tree change.
Applied to linux-can-next. It will be included in my next PR.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Krzysztof Kozlowski @ 2026-03-31 7:11 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260330094459.128648-3-m-shah@ti.com>
On Mon, Mar 30, 2026 at 03:14:59PM +0530, Moteen Shah wrote:
> + p10-hog {
> + /* P10 - MCASP/TRACE_MUX_S1 */
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "MCASP/TRACE_MUX_S1";
> + };
> +};
> +
> +&mux0 {
> + idle-state = <0>;
> +};
> +
> +&mux1 {
> + idle-state = <0>;
> +};
> +
> +&scm_conf {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + audio_refclk1: clock-controller@42e4 {
> + compatible = "ti,am62-audio-refclk";
there is no am62 compatible or DTSI include in the parent SoC file, so
am62n seems to be completely different device than j721s2.
Why does am62b appear here in this context?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-03-31 7:11 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is based on riscv-dt-for-next.
v2:
- Patch 1:
Use formal format user name.
- Patch 2:
Use formal format user name.
Add Reviewed-by from Troy Mitchell.
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
3 files changed, 30 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: 4a1739c30fc66a59450c1f78923f94607e786882
--
2.43.0
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-31 7:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <2388acbc-a927-4727-a23c-5ecd7c33a926@kernel.org>
On 2026/3/30 下午3:23, Krzysztof Kozlowski wrote:
> On 30/03/2026 09:18, Hongliang Wang wrote:
>> On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
>>> 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.
>> I can describe the hardware in loongson,ls2x-i2c.yaml, and I would like to
>> confirm with you what final implementation plan you agree to? clock
>> framework
>> or custom clock-input an clock-div attributes? if clock framework, how
>> can it
>> also be used for ACPI?
> And you ask DT maintainer for that? It's not relevant. You sent DT
> bindings patch, so this patch must be correct and we discuss this patch
> here.
I don't. My idea is that if the clock input attribute can't be used for both
dts and acpi, then clock framework will be used for dts and new define
attribute
will be used for acpi. I will first implement the hardware description
and clock
framework in Bindings.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: clock: qcom,sm6125-dispcc: reference qcom,gcc.yaml
From: Krzysztof Kozlowski @ 2026-03-31 7:12 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, kernel test robot
In-Reply-To: <20260330-ginkgo-add-usb-ir-vib-v3-2-c4b778b0d7f8@gmail.com>
On Mon, Mar 30, 2026 at 10:13:49AM +0000, Biswapriyo Nath wrote:
> Just like most of Qualcomm clock controllers, we can reference common
> qcom,gcc.yaml schema to unify the common parts of the binding. This
> also adds the '#reset-cells' property which is permitted for the
> SM6125 SoC clock controllers, but not listed as a valid property.
>
> Fixes: bb4d28e377cf ("arm64: dts: qcom: sm6125: Add missing MDSS core reset")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603150629.GYoouFwZ-lkp@intel.com/
> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> ---
> .../devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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