* Re: [PATCH 04/10] clk: qcom: clk-rpm: add msm8960 compatible
From: Konrad Dybcio @ 2026-04-14 8:08 UTC (permalink / raw)
To: linux, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-4-007fda9d6134@smankusors.com>
On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>
> Add support for the "qcom,rpmcc-msm8960" compatible string to the
> RPM clock driver.
>
> msm8960 uses the same RPM clock descriptions as apq8064, so reuse
> rpm_clk_apq8064 for this compatible.
>
> Tested-by: Rudraksha Gupta <guptarud@gmail.com>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
This suggests a fallback compatible could be fitting
Konrad
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Konrad Dybcio @ 2026-04-14 8:07 UTC (permalink / raw)
To: linux, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <c63abc0e-e060-4825-b595-a46ddf262673@oss.qualcomm.com>
On 4/14/26 10:06 AM, Konrad Dybcio wrote:
> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>
>> msm8960 uses the same clock descriptor as apq8064 but lacked the
>
> This doesn't quite seem to be the case, some fields differ and
> apq8064 additionally has:
>
> QCOM_RPM_PM8821_SMPS1
> QCOM_RPM_PM8821_SMPS2
> QCOM_RPM_PM8821_LDO1
> QCOM_RPM_VDDMIN_GPIO
Ah hmm, the MFD driver seems to provide *all* RPM resources..
Konrad
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Konrad Dybcio @ 2026-04-14 8:06 UTC (permalink / raw)
To: linux, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-3-007fda9d6134@smankusors.com>
On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>
> msm8960 uses the same clock descriptor as apq8064 but lacked the
This doesn't quite seem to be the case, some fields differ and
apq8064 additionally has:
QCOM_RPM_PM8821_SMPS1
QCOM_RPM_PM8821_SMPS2
QCOM_RPM_PM8821_LDO1
QCOM_RPM_VDDMIN_GPIO
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-14 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <e80cbf58-3701-48fd-81ea-2fe6007221d0@kernel.org>
On Tue, Apr 14, 2026 at 09:11:38AM +0200, Krzysztof Kozlowski wrote:
> On 14/04/2026 08:59, Shawn Guo wrote:
> > On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
> >> On 14/04/2026 03:21, Shawn Guo wrote:
> >>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 13/04/2026 16:34, Shawn Guo wrote:
> >>>>> In short, there will be Nord DTS using the binding coming, and I do not
> >>>>
> >>>> Maybe there will, maybe there will not.
> >>>>
> >>>>> think posting them at the same time should be a requirement.
> >>>>
> >>>> Well, it is a requirement as I explained previously, said that
> >>>> *multiple* times on the mailing list, documented expectations in
> >>>> mentioned/linked email threads.
> >>>
> >>> To be honest, I can only read the following from mentioned email
> >>> threads.
> >>>
> >>> - Binding and DTS should be organized in separate series per subsystem
> >>> - DTS should reference binding series by a lore link
> >>>
> >>
> >> The links told explicitly to organize series per subsystem/maintainer.
> >> Who is the subsystem here?
> >
> > Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> > output, so I guess it's DT/Rob?
>
> If you guess, then why did you post it separately from the other patches
> targeting Rob?
I should have done that.
> But you mentioned oryon-2-3 compatible. Who applied it? Rob? Who applied
> Kryo? Or Samsung Mongoose?
I was misled by commit 96e71f817b02 ("dt-bindings: arm: cpus: Extend
Qualcomm Oryon compatibles"), which should also been applied by DT/Rob,
IMO. The merge conflict where oryon-1-4 got lost could have been avoided
if the commit above went through DT tree, since your commit 0220405d7e09
("dt-bindings: arm: cpus: Deprecate Qualcomm generic compatibles") already
went to DT.
> I explained you the rule - bindings go with the subsystem and you post
> everything targeting subsystem in one patchset. This was explicitly
> asked for in my referenced postings.
Being a platform maintainer for 1.5 decades, I knew this pretty well.
> The SoC is the primary subsystem here.
The same binding switching its belonging subsystem is a new thing to me.
Shawn
^ permalink raw reply
* Re: [PATCH v4 05/13] dt-bindings: mfd: s2mps11: add documentation for S2MU005 PMIC
From: Rob Herring (Arm) @ 2026-04-14 7:58 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Conor Dooley, Krzysztof Kozlowski, linux-rtc, linux-leds,
Jonathan Corbet, linux-pm, devicetree, Pavel Machek, Nam Tran,
linux-kernel, Shuah Khan, linux-doc, MyungJoo Ham,
Alexandre Belloni, Łukasz Lebiedziński, Chanwoo Choi,
Lee Jones, Krzysztof Kozlowski, Sebastian Reichel,
André Draszik, linux-samsung-soc
In-Reply-To: <20260414-s2mu005-pmic-v4-5-7fe7480577e6@disroot.org>
On Tue, 14 Apr 2026 12:02:57 +0530, Kaustabh Chakraborty wrote:
> Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
> USB Interface Controller), and flash and RGB LED controllers.
>
> Since regulators are not supported by this device, unmark this property
> as required and instead set this in a per-device basis for ones which
> need it.
>
> Add the compatible and documentation for the S2MU005 PMIC. Also, add an
> example for nodes for supported sub-devices, i.e. charger, extcon,
> flash, and rgb.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../devicetree/bindings/mfd/samsung,s2mps11.yaml | 121 ++++++++++++++++++++-
> 1 file changed, 120 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:241.29-39: Warning (reg_format): /example-2/i2c/pmic@3d/extcon/port/endpoint@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:246.29-39: Warning (reg_format): /example-2/i2c/pmic@3d/extcon/port/endpoint@1:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:240.53-243.27: Warning (avoid_default_addr_size): /example-2/i2c/pmic@3d/extcon/port/endpoint@0: Relying on default #address-cells value
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:240.53-243.27: Warning (avoid_default_addr_size): /example-2/i2c/pmic@3d/extcon/port/endpoint@0: Relying on default #size-cells value
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:245.49-248.27: Warning (avoid_default_addr_size): /example-2/i2c/pmic@3d/extcon/port/endpoint@1: Relying on default #address-cells value
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:245.49-248.27: Warning (avoid_default_addr_size): /example-2/i2c/pmic@3d/extcon/port/endpoint@1: Relying on default #size-cells value
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:240.53-243.27: Warning (graph_endpoint): /example-2/i2c/pmic@3d/extcon/port/endpoint@0: graph node '#address-cells' is -1, must be 1
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:240.53-243.27: Warning (graph_endpoint): /example-2/i2c/pmic@3d/extcon/port/endpoint@0: graph node '#size-cells' is -1, must be 0
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:245.49-248.27: Warning (graph_endpoint): /example-2/i2c/pmic@3d/extcon/port/endpoint@1: graph node '#address-cells' is -1, must be 1
Documentation/devicetree/bindings/mfd/samsung,s2mps11.example.dts:245.49-248.27: Warning (graph_endpoint): /example-2/i2c/pmic@3d/extcon/port/endpoint@1: graph node '#size-cells' is -1, must be 0
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260414-s2mu005-pmic-v4-5-7fe7480577e6@disroot.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [EXTERNAL] Re: [PATCH v2 1/2] ASoC: dt-bindings: ti,tas2781: Add TAS5832 support
From: Xu, Baojun @ 2026-04-14 7:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: broonie@kernel.org, tiwai@suse.de,
andriy.shevchenko@linux.intel.com, 13916275206@139.com,
Ding, Shenghao, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, lgirdwood@gmail.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, Yi, Ken, Lo, Henry, Chen, Robin,
Wang, Will, jim.shil@goertek.com, toastcheng@google.com,
chinkaiting@google.com
In-Reply-To: <20260414-zippy-caterpillar-from-lemuria-7d70ac@quoll>
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 14 April 2026 14:56
> To: Xu, Baojun
>
> On Tue, Apr 14, 2026 at 09:54:40AM +0800, Baojun Xu wrote:
> > TAS5832 is in same family with TAS5827/28/30.
> >
> > Signed-off-by: Baojun Xu <baojun.xu@ti.com>
> > ---
> > v2:
> > - No update.
> > ---
>
> So you are going to just ignore review?
This patch was reviewed by Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>.
I has resend the patch with reviewed tag, please ignore this email.
>
> Best regards,
> Krzysztof
>
>
Best Regards
Jim
^ permalink raw reply
* Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan @ 2026-04-14 7:47 UTC (permalink / raw)
To: Robin Murphy
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mark Rutland, linux-arm-kernel, iommu, devicetree,
linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <65629411-0e1c-4c9c-bc9f-6488097bd77f@arm.com>
Hi Robin,
On Fri, Apr 10, 2026 at 01:07:29PM +0100, Robin Murphy wrote:
>On 08/04/2026 2:47 pm, Peng Fan wrote:
>> On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>> > On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> > > This patch series adds proper support for describing and probing the
>> > > Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> > > the SMMU in Devicetree, and updates the relevant drivers accordingly.
>> > >
>> > > The SMMU v3 architecture allows an optional PMCG block, typically
>> > > associated with TCUs, to be implemented within the SMMU register
>> > > address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> > > TCU page 0.
>> >
>> > But what's wrong with the existing binding? Especially given that it even has
>> > an upstream user already:
>> >
>> > https://git.kernel.org/torvalds/c/aef9703dcbf8
>> >
>> > > Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> > > referencing the existing arm,smmu-v3-pmcg binding.
>> > >
>> > > Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> > > child nodes described in DT once the SMMU probe succeeds.
>> > >
>> > > Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> > > PMCG is described as a child node. The PMCG registers occupy a sub-region
>> > > of the parent SMMU MMIO window, which is already requested by the SMMU
>> >
>> > That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>> > reserve implementation defined register space") nearly 6 years ago, where the
>> > whole purpose was to support Arm's PMCG implementation properly. What kernel
>> > is this based on?
>>
>> Seems I am wrong. I thought PMCG is in page 0, so there were resource
>> conflicts. I just retest without this patchset, all goes well.
>>
>> But from dt perspective, should the TCU PMCG node be child node of
>> SMMU node?
>
>No. PMCGs can be used entirely independently of the SMMU itself, and while
>most of the events do relate to SMMU translation and thus aren't necessarily
>meaningful if it's not in use, there are still some which can be useful for
>basic traffic counting, monitoring GPT/translation activity from _other_
>security states (if observation is delegated to Non-Secure) and possibly
>other things, even if the "main" Non-Secure SMMU interface isn't advertised
>at all. It would be unreasonable to require the SMMU node to be present and
>enabled *and* have a driver to populate PMCGs, to monitor events which are
>outside the scope of that driver.
Thanks for explaining this in detail.
Just have one more question, we are using mmu-700, but MMU-700 implementation
defined TCU and TBU events are not supported.
Should we introduce a compatible string saying "arm,mmu700-tcu-pmcg" or
"arm,mmu700-tbu-pmcg"? TBH, I have not checked MMU600(AE) or else.
Thanks,
Peng
>
>Thanks,
>Robin.
>
^ permalink raw reply
* Re: [PATCH 01/35] dt-bindings: qcom,pdc: Tighten reg to single APSS DRV region
From: Mukesh Ojha @ 2026-04-14 7:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260413-delectable-fair-nautilus-ccabcc@quoll>
On Mon, Apr 13, 2026 at 10:10:15AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Apr 11, 2026 at 12:10:38AM +0530, Mukesh Ojha wrote:
> > The PDC has multiple DRV regions, each sized 0x10000, where each region
>
> Here and in subject - add "example". You are not tightening anything
> relevant. This is just an example, it can contain whatever "reg" value.
> It's nice that value is real and correct, but now your subject creates
> impression you are actually fixing something relevant, but in fact it
> has zero impact.
Ack, will fix the subject or if this patch is not useful, can drop it ?
>
> Best regards,
> Krzysztof
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: media: qcom,glymur-iris: Add glymur video codec
From: Krzysztof Kozlowski @ 2026-04-14 7:25 UTC (permalink / raw)
To: Vishnu Reddy
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <20260414-glymur-v1-1-7d3d1cf57b16@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:29:57AM +0530, Vishnu Reddy wrote:
> Add device tree binding for the Qualcomm Glymur Iris video codec. Glymur
> is a new generation of video IP that introduces a dual-core architecture.
> The second core brings its own power domain, clocks, and reset lines,
> requiring additional power domains and clocks in the power sequence.
>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,glymur-iris.yaml | 220 +++++++++++++++++++++
> include/dt-bindings/media/qcom,glymur-iris.h | 11 ++
> 2 files changed, 231 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,glymur-iris.yaml b/Documentation/devicetree/bindings/media/qcom,glymur-iris.yaml
> new file mode 100644
> index 000000000000..10ee02cd1a7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,glymur-iris.yaml
> @@ -0,0 +1,220 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,glymur-iris.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Glymur SoC Iris video encoder and decoder
> +
> +maintainers:
> + - Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> +
> +description:
> + The Iris video processing unit on Qualcomm Glymur SoC is a video encode and
> + decode accelerator.
> +
> +properties:
> + compatible:
> + const: qcom,glymur-iris
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 9
> +
> + clock-names:
> + items:
> + - const: iface
> + - const: core
> + - const: vcodec0_core
iface1 goes here
core_freerun
vcodec0_core_freerun
and the rest, based on sm8750. Or which previous variant did you use as
the base?
> + - const: iface_ctrl
> + - const: core_freerun
> + - const: vcodec0_core_freerun
> + - const: iface1
> + - const: vcodec1_core
> + - const: vcodec1_core_freerun
> +
> + dma-coherent: true
> +
> + firmware-name:
> + maxItems: 1
> +
> + interconnects:
> + maxItems: 2
> +
> + interconnect-names:
> + items:
> + - const: cpu-cfg
> + - const: video-mem
> +
> + interrupts:
> + maxItems: 1
> +
> + iommus:
> + maxItems: 4
> +
> + iommu-map:
> + maxItems: 1
> +
> + memory-region:
> + maxItems: 1
> +
> + operating-points-v2: true
> + opp-table:
> + type: object
> +
> + power-domains:
> + maxItems: 5
> +
> + power-domain-names:
> + items:
> + - const: venus
> + - const: vcodec0
> + - const: mxc
> + - const: mmcx
> + - const: vcodec1
> +
> + resets:
> + maxItems: 6
> +
> + reset-names:
> + items:
> + - const: bus0
bus1
core
vcodec0_core
> + - const: bus_ctrl
> + - const: core
> + - const: vcodec0_core
> + - const: bus1
> + - const: vcodec1_core
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - dma-coherent
> + - interconnects
> + - interconnect-names
> + - interrupts
> + - iommus
> + - memory-region
> + - power-domains
> + - power-domain-names
> + - resets
> + - reset-names
> +
> +unevaluatedProperties: false
Use existing, most recent code as starting point.
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/media/qcom,glymur-iris.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + video-codec@aa00000 {
> + compatible = "qcom,glymur-iris";
> + reg = <0x0aa00000 0xf0000>;
> +
> + clocks = <&gcc_video_axi0_clk>,
> + <&videocc_mvs0c_clk>,
> + <&videocc_mvs0_clk>,
> + <&gcc_video_axi0c_clk>,
> + <&videocc_mvs0c_freerun_clk>,
> + <&videocc_mvs0_freerun_clk>,
> + <&gcc_video_axi1_clk>,
> + <&videocc_mvs1_clk>,
> + <&videocc_mvs1_freerun_clk>;
> + clock-names = "iface",
> + "core",
> + "vcodec0_core",
> + "iface_ctrl",
> + "core_freerun",
> + "vcodec0_core_freerun",
> + "iface1",
> + "vcodec1_core",
> + "vcodec1_core_freerun";
> +
> + dma-coherent;
> +
> + interconnects = <&hsc_noc_master_appss_proc &config_noc_slave_venus_cfg>,
> + <&mmss_noc_master_video &mc_virt_slave_ebi1>;
> + interconnect-names = "cpu-cfg",
> + "video-mem";
> +
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> +
> + iommus = <&apps_smmu 0x1940 0x0>,
> + <&apps_smmu 0x1943 0x0>,
> + <&apps_smmu 0x1944 0x0>,
> + <&apps_smmu 0x19e0 0x0>;
> +
> + iommu-map = <IRIS_FIRMWARE &apps_smmu 0x19e2 0x1>;
> +
> + memory-region = <&video_mem>;
> +
> + operating-points-v2 = <&iris_opp_table>;
> +
> + power-domains = <&videocc_mvs0c_gdsc>,
> + <&videocc_mvs0_gdsc>,
> + <&rpmhpd RPMHPD_MXC>,
> + <&rpmhpd RPMHPD_MMCX>,
> + <&videocc_mvs1_gdsc>;
> + power-domain-names = "venus",
> + "vcodec0",
> + "mxc",
> + "mmcx",
> + "vcodec1";
> +
> + resets = <&gcc_video_axi0_clk_ares>,
> + <&gcc_video_axi0c_clk_ares>,
> + <&videocc_mvs0c_freerun_clk_ares>,
> + <&videocc_mvs0_freerun_clk_ares>,
> + <&gcc_video_axi1_clk_ares>,
> + <&videocc_mvs1_freerun_clk_ares>;
> + reset-names = "bus0",
> + "bus_ctrl",
> + "core",
> + "vcodec0_core",
> + "bus1",
> + "vcodec1_core";
> +
> + iris_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-240000000 {
> + opp-hz = /bits/ 64 <240000000 240000000 360000000>;
> + required-opps = <&rpmhpd_opp_svs>,
> + <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-338000000 {
> + opp-hz = /bits/ 64 <338000000 338000000 507000000>;
> + required-opps = <&rpmhpd_opp_svs>,
> + <&rpmhpd_opp_svs>;
> + };
> +
> + opp-366000000 {
> + opp-hz = /bits/ 64 <366000000 366000000 549000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>,
> + <&rpmhpd_opp_svs_l1>;
> + };
> +
> + opp-444000000 {
> + opp-hz = /bits/ 64 <444000000 444000000 666000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>,
> + <&rpmhpd_opp_nom>;
> + };
> +
> + opp-533333334 {
> + opp-hz = /bits/ 64 <533333334 533333334 800000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>,
> + <&rpmhpd_opp_turbo>;
> + };
> +
> + opp-655000000 {
> + opp-hz = /bits/ 64 <655000000 655000000 982000000>;
> + required-opps = <&rpmhpd_opp_nom>,
> + <&rpmhpd_opp_turbo_l1>;
> + };
> + };
> + };
> diff --git a/include/dt-bindings/media/qcom,glymur-iris.h b/include/dt-bindings/media/qcom,glymur-iris.h
> new file mode 100644
> index 000000000000..5766db0b9247
> --- /dev/null
> +++ b/include/dt-bindings/media/qcom,glymur-iris.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _DT_BINDINGS_MEDIA_QCOM_GLYMUR_IRIS_H_
> +#define _DT_BINDINGS_MEDIA_QCOM_GLYMUR_IRIS_H_
> +
> +#define IRIS_FIRMWARE 0
For what is this define? IOMMU map? Binding is quiet about it, so
probably this should have some prefix to make it obvious.
IOMMU_? DEV_? What does this define express?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 08/13] mfd: sec: resolve PMIC revision in S2MU005
From: Kaustabh Chakraborty @ 2026-04-14 7:25 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, André Draszik,
Alexandre Belloni, Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <20260414-s2mu005-pmic-v4-8-7fe7480577e6@disroot.org>
On 2026-04-14 12:03 +05:30, Kaustabh Chakraborty wrote:
> In devices other than S2MPG1X, the revision can be retrieved from the
> first register of the PMIC regmap. In S2MU005 however, the location is
> in offset 0x73. Introduce a switch-case block to allow selecting the
> REG_ID register.
>
> S2MU005 also has a field mask for the revision. Apply it using
> FIELD_GET() and get the extracted value.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> drivers/mfd/sec-common.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
> index 883e6d0aa3f06..43215605191e4 100644
> --- a/drivers/mfd/sec-common.c
> +++ b/drivers/mfd/sec-common.c
> @@ -16,6 +16,7 @@
> #include <linux/mfd/samsung/irq.h>
> #include <linux/mfd/samsung/s2mps11.h>
> #include <linux/mfd/samsung/s2mps13.h>
> +#include <linux/mfd/samsung/s2mu005.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/pm.h>
> @@ -119,20 +120,27 @@ static const struct mfd_cell s2mu005_devs[] = {
>
> static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
> {
> - unsigned int val;
> + unsigned int reg, mask, val;
>
> - /* For s2mpg1x, the revision is in a different regmap */
> switch (sec_pmic->device_type) {
> case S2MPG10:
> case S2MPG11:
> + /* For s2mpg1x, the revision is in a different regmap */
> return;
> - default:
> + case S2MU005:
> + reg = S2MU005_REG_ID;
> + mask = S2MU005_ID_MASK;
> break;
> + default:
> + /* For other device types, REG_ID is always the first register. */
> + reg = S2MPS11_REG_ID;
> + mask = ~0;
> }
>
> - /* For each device type, the REG_ID is always the first register */
> - if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, &val))
> + if (!regmap_read(sec_pmic->regmap_pmic, reg, &val)) {
> + val = FIELD_GET(S2MU005_ID_MASK, val);
Bug here! FIELD_GET(mask, val) should've been used.
> dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
> + }
> }
>
> static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
^ permalink raw reply
* Re: [PATCH 07/11] media: iris: Rename clock and power domain macros to use vcodec prefix
From: Vishnu Reddy @ 2026-04-14 7:20 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <20260414063846.fixumrttkfqwydch@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:08 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:03AM +0530, Vishnu Reddy wrote:
>> The current clock and power domain enum names are too generic. Rename
>> them with a vcodec prefix to make the names more meaningful and to easily
>> accommodate vcodec1 enums for the secondary core in the following patches.
> patches ?
>
>> This patch only renames the macros and does not introduce any functional
>> changes.
> "this patch" or "patches" are not preferred.. write the commit text in
> imperative mood..
Ack, will correct in the next revision.
Thanks,
Vishnu Reddy
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 12 ++++----
>> .../media/platform/qcom/iris/iris_platform_gen1.c | 6 ++--
>> .../media/platform/qcom/iris/iris_platform_gen2.c | 6 ++--
>> .../platform/qcom/iris/iris_platform_sc7280.h | 10 +++----
>> .../platform/qcom/iris/iris_platform_sm8750.h | 12 ++++----
>> drivers/media/platform/qcom/iris/iris_vpu3x.c | 25 ++++++++--------
>> drivers/media/platform/qcom/iris/iris_vpu4x.c | 30 ++++++++++---------
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 35 +++++++++++-----------
>> 8 files changed, 70 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 55ff6137d9a9..30e9d4d288c6 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -49,14 +49,14 @@ extern const struct iris_platform_data sm8650_data;
>> extern const struct iris_platform_data sm8750_data;
>>
>> enum platform_clk_type {
>> - IRIS_AXI_CLK, /* AXI0 in case of platforms with multiple AXI clocks */
>> + IRIS_AXI_VCODEC_CLK,
>> IRIS_CTRL_CLK,
>> IRIS_AHB_CLK,
>> - IRIS_HW_CLK,
>> - IRIS_HW_AHB_CLK,
>> - IRIS_AXI1_CLK,
>> + IRIS_VCODEC_CLK,
>> + IRIS_VCODEC_AHB_CLK,
>> + IRIS_AXI_CTRL_CLK,
>> IRIS_CTRL_FREERUN_CLK,
>> - IRIS_HW_FREERUN_CLK,
>> + IRIS_VCODEC_FREERUN_CLK,
>> IRIS_BSE_HW_CLK,
>> IRIS_VPP0_HW_CLK,
>> IRIS_VPP1_HW_CLK,
>> @@ -206,7 +206,7 @@ struct icc_vote_data {
>>
>> enum platform_pm_domain_type {
>> IRIS_CTRL_POWER_DOMAIN,
>> - IRIS_HW_POWER_DOMAIN,
>> + IRIS_VCODEC_POWER_DOMAIN,
>> IRIS_VPP0_HW_POWER_DOMAIN,
>> IRIS_VPP1_HW_POWER_DOMAIN,
>> IRIS_APV_HW_POWER_DOMAIN,
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>> index df8e6bf9430e..be6a631f8ede 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>> @@ -284,9 +284,9 @@ static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>> static const char * const sm8250_opp_pd_table[] = { "mx" };
>>
>> static const struct platform_clk_data sm8250_clk_table[] = {
>> - {IRIS_AXI_CLK, "iface" },
>> - {IRIS_CTRL_CLK, "core" },
>> - {IRIS_HW_CLK, "vcodec0_core" },
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_VCODEC_CLK, "vcodec0_core" },
>> };
>>
>> static const char * const sm8250_opp_clk_table[] = {
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> index 5da90d47f9c6..47c6b650f0b4 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> @@ -780,9 +780,9 @@ static const char * const sm8550_pmdomain_table[] = { "venus", "vcodec0" };
>> static const char * const sm8550_opp_pd_table[] = { "mxc", "mmcx" };
>>
>> static const struct platform_clk_data sm8550_clk_table[] = {
>> - {IRIS_AXI_CLK, "iface" },
>> - {IRIS_CTRL_CLK, "core" },
>> - {IRIS_HW_CLK, "vcodec0_core" },
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_VCODEC_CLK, "vcodec0_core" },
>> };
>>
>> static const char * const sm8550_opp_clk_table[] = {
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sc7280.h b/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
>> index 0ec8f334df67..6b783e524b81 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_sc7280.h
>> @@ -16,11 +16,11 @@ static const struct bw_info sc7280_bw_table_dec[] = {
>> static const char * const sc7280_opp_pd_table[] = { "cx" };
>>
>> static const struct platform_clk_data sc7280_clk_table[] = {
>> - {IRIS_CTRL_CLK, "core" },
>> - {IRIS_AXI_CLK, "iface" },
>> - {IRIS_AHB_CLK, "bus" },
>> - {IRIS_HW_CLK, "vcodec_core" },
>> - {IRIS_HW_AHB_CLK, "vcodec_bus" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_AHB_CLK, "bus" },
>> + {IRIS_VCODEC_CLK, "vcodec_core" },
>> + {IRIS_VCODEC_AHB_CLK, "vcodec_bus" },
>> };
>>
>> static const char * const sc7280_opp_clk_table[] = {
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8750.h b/drivers/media/platform/qcom/iris/iris_platform_sm8750.h
>> index 719056656a5b..f843f13251c5 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_sm8750.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8750.h
>> @@ -11,12 +11,12 @@ static const char * const sm8750_clk_reset_table[] = {
>> };
>>
>> static const struct platform_clk_data sm8750_clk_table[] = {
>> - {IRIS_AXI_CLK, "iface" },
>> - {IRIS_CTRL_CLK, "core" },
>> - {IRIS_HW_CLK, "vcodec0_core" },
>> - {IRIS_AXI1_CLK, "iface1" },
>> - {IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>> - {IRIS_HW_FREERUN_CLK, "vcodec0_core_freerun" },
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_VCODEC_CLK, "vcodec0_core" },
>> + {IRIS_AXI_CTRL_CLK, "iface1" },
>> + {IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>> + {IRIS_VCODEC_FREERUN_CLK, "vcodec0_core_freerun" },
>> };
>>
>> #endif
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
>> index fe4423b951b1..1f0a3a47d87f 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
>> @@ -209,7 +209,7 @@ static int iris_vpu33_power_off_controller(struct iris_core *core)
>>
>> disable_power:
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>>
>> return 0;
>> }
>> @@ -218,36 +218,37 @@ static int iris_vpu35_power_on_hw(struct iris_core *core)
>> {
>> int ret;
>>
>> - ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + ret = iris_enable_power_domains(core,
>> + core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>> if (ret)
>> return ret;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_AXI_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_AXI_VCODEC_CLK);
>> if (ret)
>> goto err_disable_power;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_FREERUN_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> if (ret)
>> goto err_disable_axi_clk;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_CLK);
>> if (ret)
>> goto err_disable_hw_free_clk;
>>
>> - ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
>> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN], true);
>> if (ret)
>> goto err_disable_hw_clk;
>>
>> return 0;
>>
>> err_disable_hw_clk:
>> - iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_CLK);
>> err_disable_hw_free_clk:
>> - iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> err_disable_axi_clk:
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>> err_disable_power:
>> - iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>>
>> return ret;
>> }
>> @@ -256,8 +257,8 @@ static void iris_vpu35_power_off_hw(struct iris_core *core)
>> {
>> iris_vpu33_power_off_hardware(core);
>>
>> - iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>> }
>>
>> const struct vpu_ops iris_vpu3_ops = {
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/media/platform/qcom/iris/iris_vpu4x.c
>> index a8db02ce5c5e..4082d331d2f3 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu4x.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
>> @@ -27,7 +27,8 @@ static int iris_vpu4x_genpd_set_hwmode(struct iris_core *core, bool hw_mode, u32
>> {
>> int ret;
>>
>> - ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], hw_mode);
>> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN],
>> + hw_mode);
>> if (ret)
>> return ret;
>>
>> @@ -63,7 +64,7 @@ static int iris_vpu4x_genpd_set_hwmode(struct iris_core *core, bool hw_mode, u32
>> dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VPP0_HW_POWER_DOMAIN],
>> !hw_mode);
>> restore_hw_domain_mode:
>> - dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], !hw_mode);
>> + dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN], !hw_mode);
>>
>> return ret;
>> }
>> @@ -162,15 +163,15 @@ static int iris_vpu4x_enable_hardware_clocks(struct iris_core *core, u32 efuse_v
>> {
>> int ret;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_AXI_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_AXI_VCODEC_CLK);
>> if (ret)
>> return ret;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_FREERUN_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> if (ret)
>> goto disable_axi_clock;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_CLK);
>> if (ret)
>> goto disable_hw_free_run_clock;
>>
>> @@ -198,11 +199,11 @@ static int iris_vpu4x_enable_hardware_clocks(struct iris_core *core, u32 efuse_v
>> disable_bse_hw_clock:
>> iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
>> disable_hw_clock:
>> - iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_CLK);
>> disable_hw_free_run_clock:
>> - iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> disable_axi_clock:
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>>
>> return ret;
>> }
>> @@ -216,9 +217,9 @@ static void iris_vpu4x_disable_hardware_clocks(struct iris_core *core, u32 efuse
>> iris_disable_unprepare_clock(core, IRIS_VPP0_HW_CLK);
>>
>> iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_FREERUN_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>> }
>>
>> static int iris_vpu4x_power_on_hardware(struct iris_core *core)
>> @@ -226,7 +227,8 @@ static int iris_vpu4x_power_on_hardware(struct iris_core *core)
>> u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
>> int ret;
>>
>> - ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + ret = iris_enable_power_domains(core,
>> + core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>> if (ret)
>> return ret;
>>
>> @@ -278,7 +280,7 @@ static int iris_vpu4x_power_on_hardware(struct iris_core *core)
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
>> [IRIS_VPP0_HW_POWER_DOMAIN]);
>> disable_hw_power_domain:
>> - iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>>
>> return ret;
>> }
>> @@ -356,7 +358,7 @@ static void iris_vpu4x_power_off_hardware(struct iris_core *core)
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
>> [IRIS_VPP0_HW_POWER_DOMAIN]);
>>
>> - iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>> }
>>
>> const struct vpu_ops iris_vpu4x_ops = {
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index bfd1e762c38e..006fd3ffc752 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -213,7 +213,7 @@ int iris_vpu_power_off_controller(struct iris_core *core)
>> disable_power:
>> iris_disable_unprepare_clock(core, IRIS_AHB_CLK);
>> iris_disable_unprepare_clock(core, IRIS_CTRL_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
>>
>> return 0;
>> @@ -221,10 +221,10 @@ int iris_vpu_power_off_controller(struct iris_core *core)
>>
>> void iris_vpu_power_off_hw(struct iris_core *core)
>> {
>> - dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], false);
>> - iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> - iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>> + dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN], false);
>> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_AHB_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_CLK);
>> }
>>
>> void iris_vpu_power_off(struct iris_core *core)
>> @@ -251,7 +251,7 @@ int iris_vpu_power_on_controller(struct iris_core *core)
>> if (ret)
>> goto err_disable_power;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_AXI_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_AXI_VCODEC_CLK);
>> if (ret)
>> goto err_disable_power;
>>
>> @@ -268,7 +268,7 @@ int iris_vpu_power_on_controller(struct iris_core *core)
>> err_disable_ctrl_clock:
>> iris_disable_unprepare_clock(core, IRIS_CTRL_CLK);
>> err_disable_axi_clock:
>> - iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_VCODEC_CLK);
>> err_disable_power:
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
>>
>> @@ -279,30 +279,31 @@ int iris_vpu_power_on_hw(struct iris_core *core)
>> {
>> int ret;
>>
>> - ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + ret = iris_enable_power_domains(core,
>> + core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>> if (ret)
>> return ret;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_CLK);
>> if (ret)
>> goto err_disable_power;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_HW_AHB_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_VCODEC_AHB_CLK);
>> if (ret && ret != -ENOENT)
>> goto err_disable_hw_clock;
>>
>> - ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
>> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN], true);
>> if (ret)
>> goto err_disable_hw_ahb_clock;
>>
>> return 0;
>>
>> err_disable_hw_ahb_clock:
>> - iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_AHB_CLK);
>> err_disable_hw_clock:
>> - iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_VCODEC_CLK);
>> err_disable_power:
>> - iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_VCODEC_POWER_DOMAIN]);
>>
>> return ret;
>> }
>> @@ -362,7 +363,7 @@ int iris_vpu35_vpu4x_power_off_controller(struct iris_core *core)
>> disable_power:
>> iris_disable_unprepare_clock(core, IRIS_CTRL_CLK);
>> iris_disable_unprepare_clock(core, IRIS_CTRL_FREERUN_CLK);
>> - iris_disable_unprepare_clock(core, IRIS_AXI1_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_CTRL_CLK);
>>
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
>>
>> @@ -379,7 +380,7 @@ int iris_vpu35_vpu4x_power_on_controller(struct iris_core *core)
>> if (ret)
>> return ret;
>>
>> - ret = iris_prepare_enable_clock(core, IRIS_AXI1_CLK);
>> + ret = iris_prepare_enable_clock(core, IRIS_AXI_CTRL_CLK);
>> if (ret)
>> goto err_disable_power;
>>
>> @@ -396,7 +397,7 @@ int iris_vpu35_vpu4x_power_on_controller(struct iris_core *core)
>> err_disable_ctrl_free_clk:
>> iris_disable_unprepare_clock(core, IRIS_CTRL_FREERUN_CLK);
>> err_disable_axi1_clk:
>> - iris_disable_unprepare_clock(core, IRIS_AXI1_CLK);
>> + iris_disable_unprepare_clock(core, IRIS_AXI_CTRL_CLK);
>> err_disable_power:
>> iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
>>
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
From: Krzysztof Kozlowski @ 2026-04-14 7:19 UTC (permalink / raw)
To: Antony Kurniawan Soemardi
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel, phone-devel,
Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-2-007fda9d6134@smankusors.com>
On Tue, Apr 14, 2026 at 01:55:29AM +0700, Antony Kurniawan Soemardi wrote:
> Add compat for Smart Peripheral System (SPS) Interrupt Controller (SIC)
> present on Qualcomm MSM8960 SoC.
>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
> 1 file changed, 2 insertions(+)
This was also sent. Where is the changelog and versioning? What changed
here?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/10] dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
From: Krzysztof Kozlowski @ 2026-04-14 7:18 UTC (permalink / raw)
To: Antony Kurniawan Soemardi
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel, phone-devel,
Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-1-007fda9d6134@smankusors.com>
On Tue, Apr 14, 2026 at 01:55:28AM +0700, Antony Kurniawan Soemardi wrote:
> Document the qcom,rpmcc-msm8960 compatible.
>
> The MSM8960 platform shares the same RPM clock definitions as
> APQ8064, so extend the existing conditional schema to treat
> qcom,rpmcc-msm8960 the same as qcom,rpmcc-apq8064.
>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
You already sent it some time ago. Implement previous feedback.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Krzysztof Kozlowski @ 2026-04-14 7:17 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <20260413144553.132737-1-dinguyen@kernel.org>
On Mon, Apr 13, 2026 at 09:45:52AM -0500, Dinh Nguyen wrote:
> The Agilex7 is a series of devices from Altera that are derived from
> the Agilex family.
>
> The Agilex7F device supports PCIE 4.0 and DDR4. The Agilex7I device supports
> PCIE 5.0 and DDR4, while the Agilex7M device supports DDR4, DDR5, LPDDR5
> and PCIE 5.0.
>
> All other peripherals from these devices are the same as the Agilex
> device.
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/altera.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
> index 206686f3eebc..5ee09f8d4698 100644
> --- a/Documentation/devicetree/bindings/arm/altera.yaml
> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
> @@ -115,6 +115,16 @@ properties:
> - intel,socfpga-agilex5-socdk-nand
> - const: intel,socfpga-agilex5
>
> + - description: Agilex7 series F, I and M boards
> + items:
> + - enum:
> + - intel,socfpga-agilex7m-socdk
> + - enum:
> + - intel,socfpga-agilex7f
> + - intel,socfpga-agilex7i
> + - intel,socfpga-agilex7m
> + - const: intel,socfpga-agilex
And separate question - why previous soc "agilex" is used as fallback?
Even more confusing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Krzysztof Kozlowski @ 2026-04-14 7:16 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <20260413144553.132737-1-dinguyen@kernel.org>
On Mon, Apr 13, 2026 at 09:45:52AM -0500, Dinh Nguyen wrote:
> The Agilex7 is a series of devices from Altera that are derived from
> the Agilex family.
SoCs?
>
> The Agilex7F device supports PCIE 4.0 and DDR4. The Agilex7I device supports
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.
> PCIE 5.0 and DDR4, while the Agilex7M device supports DDR4, DDR5, LPDDR5
> and PCIE 5.0.
>
> All other peripherals from these devices are the same as the Agilex
> device.
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/altera.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
> index 206686f3eebc..5ee09f8d4698 100644
> --- a/Documentation/devicetree/bindings/arm/altera.yaml
> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
> @@ -115,6 +115,16 @@ properties:
> - intel,socfpga-agilex5-socdk-nand
> - const: intel,socfpga-agilex5
>
> + - description: Agilex7 series F, I and M boards
> + items:
> + - enum:
> + - intel,socfpga-agilex7m-socdk
Why does "7m-socdk" go with "7i" and "7m"? If these are SoCs, then board
using soc 7m cannot use 7i or 7f fallback.
Or board is not using 7m SoC, but then the name is misleading.
> + - enum:
> + - intel,socfpga-agilex7f
> + - intel,socfpga-agilex7i
> + - intel,socfpga-agilex7m
> + - const: intel,socfpga-agilex
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Andy Shevchenko @ 2026-04-14 7:14 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <20260413200547.75bfd672@jic23-huawei>
On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> On Mon, 30 Mar 2026 14:58:46 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
...
> > + if (!conf->temp_en)
> > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
>
> Could make this
> val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> !conf->temp_en);
> Not particularly important though if you prefer the if.
Isn't this becomes FIELD_MODIFY()?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 0/9] riscv: spacemit: enable SD card support with UHS modes for OrangePi RV2
From: Iker Pedrosa @ 2026-04-14 7:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Troy Mitchell, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel, Anand Moon, Trevor Gamblin,
Vincent Legoll
In-Reply-To: <f58ec12c-3957-4d44-b823-6a1ae1a1dd94@kernel.org>
El lun, 13 abr 2026 a las 10:07, Krzysztof Kozlowski
(<krzk@kernel.org>) escribió:
>
> On 13/04/2026 10:02, Iker Pedrosa wrote:
> > This series enables complete SD card support for the Spacemit K1-based
> > OrangePi RV2 board, including UHS (Ultra High Speed) modes for
> > high-performance SD card operation.
> >
> > Background
> >
> > The Spacemit K1 SoC includes an SDHCI controller capable of supporting
> > SD cards up to UHS-I speeds (SDR104 at 208MHz). However, mainline
> > currently lacks basic SD controller configuration, SDHCI driver
> > enhancements for voltage switching and tuning, and power management
> > infrastructure.
> >
> > Implementation
> >
> > The series enables SD card support through coordinated layers:
> >
> > - Hardware infrastructure (patches 1-2): Device tree bindings for voltage
> > switching hardware and essential clock infrastructure.
> > - SDHCI driver enhancements (patches 3-7): Regulator framework
> > integration, pinctrl state switching for voltage domains, AIB register
> > programming, and comprehensive SDR tuning support for reliable UHS
> > operation.
> > - SoC and board integration (patches 8-10): Complete K1 SoC controller
> > definitions, PMIC power infrastructure, and OrangePi RV2 board enablement
> > with full UHS support.
> >
> > This transforms the OrangePi RV2 from having no SD card support to full
> > UHS-I capability, enabling high-performance storage up to 208MHz.
> >
> > Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
> > Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> > ---
> > Changes in v8:
> > - Resending the series as v8. The v7 submission failed due to an SMTP
> > error during transit, which resulted in a broken thread on the mailing
> > list.
>
> Hm? Everything is here:
> https://lore.kernel.org/all/20260413-orangepi-sd-card-uhs-v7-1-16650f49c022@gmail.com/
>
> You can send individual patches to fix up threading, use --in-reply-to.
My apologies for the noise and the rapid resend.
The reason for v8 was that the v7 cover letter (0/9) failed to reach
the mailing list due to an SMTP error on my end. This left the v7
thread "headless" in the archives without the changelog or the full
context of the series. I was attempting to fix the threading
immediately so that reviewers would have a complete set of patches to
look at, but I realize now that resending the entire series on the
same day was premature.
>
> > - No functional changes from v7.
> > - Link to v7: https://lore.kernel.org/r/20260413-orangepi-sd-card-uhs-v7-1-16650f49c022@gmail.com
> >
>
> You already sent it on 13th of April. And now v8 the same day. Wait a
> few days to allow people to actually review your code.
>
> It's BTW merge window, so big series should slow down.
I take your point regarding the merge window. I will step back and
wait for feedback on v8 once the window closes and you have more room
for reviews.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Krzysztof Kozlowski @ 2026-04-14 7:11 UTC (permalink / raw)
To: Shawn Guo
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <ad3l37AXKvzRrafU@QCOM-aGQu4IUr3Y>
On 14/04/2026 08:59, Shawn Guo wrote:
> On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
>> On 14/04/2026 03:21, Shawn Guo wrote:
>>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
>>>> On 13/04/2026 16:34, Shawn Guo wrote:
>>>>> In short, there will be Nord DTS using the binding coming, and I do not
>>>>
>>>> Maybe there will, maybe there will not.
>>>>
>>>>> think posting them at the same time should be a requirement.
>>>>
>>>> Well, it is a requirement as I explained previously, said that
>>>> *multiple* times on the mailing list, documented expectations in
>>>> mentioned/linked email threads.
>>>
>>> To be honest, I can only read the following from mentioned email
>>> threads.
>>>
>>> - Binding and DTS should be organized in separate series per subsystem
>>> - DTS should reference binding series by a lore link
>>>
>>
>> The links told explicitly to organize series per subsystem/maintainer.
>> Who is the subsystem here?
>
> Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> output, so I guess it's DT/Rob?
If you guess, then why did you post it separately from the other patches
targeting Rob?
But you mentioned oryon-2-3 compatible. Who applied it? Rob? Who applied
Kryo? Or Samsung Mongoose?
I explained you the rule - bindings go with the subsystem and you post
everything targeting subsystem in one patchset. This was explicitly
asked for in my referenced postings. The SoC is the primary subsystem here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Krzysztof Kozlowski @ 2026-04-14 7:05 UTC (permalink / raw)
To: Shawn Guo
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <ad3l37AXKvzRrafU@QCOM-aGQu4IUr3Y>
On 14/04/2026 08:59, Shawn Guo wrote:
> On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
>> On 14/04/2026 03:21, Shawn Guo wrote:
>>> On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
>>>> On 13/04/2026 16:34, Shawn Guo wrote:
>>>>> In short, there will be Nord DTS using the binding coming, and I do not
>>>>
>>>> Maybe there will, maybe there will not.
>>>>
>>>>> think posting them at the same time should be a requirement.
>>>>
>>>> Well, it is a requirement as I explained previously, said that
>>>> *multiple* times on the mailing list, documented expectations in
>>>> mentioned/linked email threads.
>>>
>>> To be honest, I can only read the following from mentioned email
>>> threads.
>>>
>>> - Binding and DTS should be organized in separate series per subsystem
>>> - DTS should reference binding series by a lore link
>>>
>>
>> The links told explicitly to organize series per subsystem/maintainer.
>> Who is the subsystem here?
>
> Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
> output, so I guess it's DT/Rob?
>
>>> These are what I'm trying to do, and I'm not just posting DTS
>>> simultaneously. I do not really read the requirement of posting
>>> binding and DTS using it simultaneously from the email threads.
>>>
>>> Taking a step back, even if the requirement is mentioned in an email
>>> thread like this one, I'm not sure it's the correct or well received
>>> way to define a requirement. And that might be why you had to keep
>>> repeating yourself.
>>>
>>>> It's also documented in submitting
>>>> patches in DT (although not with that strong wording).
>>>
>>> Either I'm blind or reading the wrong document. I failed to find
>>> the requirement of posting binding and DTS using it simultaneously
>>> in Documentation/devicetree/bindings/submitting-patches.rst. Could you
>>> point it out explicitly?
>>
>> Rule 8.
>
> This one?
>
> 8) If a documented compatible string is not yet matched by the
> driver, the documentation should also include a compatible
> string that is matched by the driver
>
> Are we looking at the same version of the document? How does that map
> to the requirement of posting binding and DTS using it simultaneously we
> are debating here? I'm confused.
Why is the rule there and what is expressed by it? We do not discuss
posting binding and DTS using simultaneously. We discuss lack of user of
a binding.
I even asked earlier explicitly:
"Why do want even such binding?"
Do you have a user of this compatible? Not a single one. So apply the
spirit of that rule. Or if you cannot get the spirit, you could apply it
literally.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-14 6:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <27f57fd6-71cc-4f88-9d8f-6c6fc778008a@kernel.org>
On Tue, Apr 14, 2026 at 08:23:12AM +0200, Krzysztof Kozlowski wrote:
> On 14/04/2026 03:21, Shawn Guo wrote:
> > On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> >> On 13/04/2026 16:34, Shawn Guo wrote:
> >>> In short, there will be Nord DTS using the binding coming, and I do not
> >>
> >> Maybe there will, maybe there will not.
> >>
> >>> think posting them at the same time should be a requirement.
> >>
> >> Well, it is a requirement as I explained previously, said that
> >> *multiple* times on the mailing list, documented expectations in
> >> mentioned/linked email threads.
> >
> > To be honest, I can only read the following from mentioned email
> > threads.
> >
> > - Binding and DTS should be organized in separate series per subsystem
> > - DTS should reference binding series by a lore link
> >
>
> The links told explicitly to organize series per subsystem/maintainer.
> Who is the subsystem here?
Rob Herring <robh@kernel.org> appears at the top of get_maintainer.pl
output, so I guess it's DT/Rob?
> > These are what I'm trying to do, and I'm not just posting DTS
> > simultaneously. I do not really read the requirement of posting
> > binding and DTS using it simultaneously from the email threads.
> >
> > Taking a step back, even if the requirement is mentioned in an email
> > thread like this one, I'm not sure it's the correct or well received
> > way to define a requirement. And that might be why you had to keep
> > repeating yourself.
> >
> >> It's also documented in submitting
> >> patches in DT (although not with that strong wording).
> >
> > Either I'm blind or reading the wrong document. I failed to find
> > the requirement of posting binding and DTS using it simultaneously
> > in Documentation/devicetree/bindings/submitting-patches.rst. Could you
> > point it out explicitly?
>
> Rule 8.
This one?
8) If a documented compatible string is not yet matched by the
driver, the documentation should also include a compatible
string that is matched by the driver
Are we looking at the same version of the document? How does that map
to the requirement of posting binding and DTS using it simultaneously we
are debating here? I'm confused.
Shawn
^ permalink raw reply
* [PATCH v4 2/2] hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
From: Brian Chiang @ 2026-04-14 6:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng, Brian Chiang,
Jack Cheng
In-Reply-To: <20260414-add-support-for-q50sn12072-and-q54sn120a1-v4-0-b81eaea49df1@inventec.com>
From: Jack Cheng <cheng.jackhy@inventec.com>
The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
module from Delta Power Modules.
The Q50SN12072, quarter brick, single output 12V. This product provides up
to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
efficiency up to 98.3%@54Vin.
The Q54SN120A1, quarter brick, single output 12V. This product provides up
to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
efficiency up to 98.1%@54Vin.
Add support for them to q54sj108a2 driver.
Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
---
drivers/hwmon/pmbus/q54sj108a2.c | 105 +++++++++++++++++++++++++++------------
1 file changed, 72 insertions(+), 33 deletions(-)
diff --git a/drivers/hwmon/pmbus/q54sj108a2.c b/drivers/hwmon/pmbus/q54sj108a2.c
index d5d60a9af8c5..0fd7dc37e328 100644
--- a/drivers/hwmon/pmbus/q54sj108a2.c
+++ b/drivers/hwmon/pmbus/q54sj108a2.c
@@ -22,7 +22,9 @@
#define PMBUS_FLASH_KEY_WRITE 0xEC
enum chips {
- q54sj108a2
+ q50sn12072,
+ q54sj108a2,
+ q54sn120a1
};
enum {
@@ -55,10 +57,24 @@ struct q54sj108a2_data {
#define to_psu(x, y) container_of((x), struct q54sj108a2_data, debugfs_entries[(y)])
static struct pmbus_driver_info q54sj108a2_info[] = {
- [q54sj108a2] = {
+ [q50sn12072] = {
.pages = 1,
+ /* Source : Delta Q50SN12072 */
+ .format[PSC_VOLTAGE_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
+ PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
+ PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
+ },
+ [q54sj108a2] = {
+ .pages = 1,
/* Source : Delta Q54SJ108A2 */
+ .format[PSC_VOLTAGE_OUT] = linear,
.format[PSC_TEMPERATURE] = linear,
.format[PSC_VOLTAGE_IN] = linear,
.format[PSC_CURRENT_OUT] = linear,
@@ -69,6 +85,20 @@ static struct pmbus_driver_info q54sj108a2_info[] = {
PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
PMBUS_HAVE_STATUS_INPUT,
},
+ [q54sn120a1] = {
+ .pages = 1,
+ /* Source : Delta Q54SN120A1 */
+ .format[PSC_VOLTAGE_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
+ PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
+ PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
+ },
};
static ssize_t q54sj108a2_debugfs_read(struct file *file, char __user *buf,
@@ -270,7 +300,9 @@ static const struct file_operations q54sj108a2_fops = {
};
static const struct i2c_device_id q54sj108a2_id[] = {
+ { "q50sn12072", q50sn12072 },
{ "q54sj108a2", q54sj108a2 },
+ { "q54sn120a1", q54sn120a1 },
{ },
};
@@ -280,6 +312,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
u8 buf[I2C_SMBUS_BLOCK_MAX + 1];
+ const struct i2c_device_id *mid;
enum chips chip_id;
int ret, i;
struct dentry *debugfs;
@@ -292,14 +325,9 @@ static int q54sj108a2_probe(struct i2c_client *client)
I2C_FUNC_SMBUS_BLOCK_DATA))
return -ENODEV;
- if (client->dev.of_node)
- chip_id = (enum chips)(unsigned long)of_device_get_match_data(dev);
- else
- chip_id = i2c_match_id(q54sj108a2_id, client)->driver_data;
-
ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
if (ret < 0) {
- dev_err(&client->dev, "Failed to read Manufacturer ID\n");
+ dev_err(dev, "Failed to read Manufacturer ID\n");
return ret;
}
if (ret != 6 || strncmp(buf, "DELTA", 5)) {
@@ -308,19 +336,25 @@ static int q54sj108a2_probe(struct i2c_client *client)
return -ENODEV;
}
- /*
- * The chips support reading PMBUS_MFR_MODEL.
- */
ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
if (ret < 0) {
dev_err(dev, "Failed to read Manufacturer Model\n");
return ret;
}
- if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10)) {
- buf[ret] = '\0';
+ buf[ret] = '\0';
+ for (mid = q54sj108a2_id; mid->name[0]; mid++) {
+ if (!strncasecmp(mid->name, buf, strlen(mid->name)))
+ break;
+ }
+ if (!mid->name[0]) {
dev_err(dev, "Unsupported Manufacturer Model '%s'\n", buf);
return -ENODEV;
}
+ chip_id = mid->driver_data;
+
+ if (strcmp(client->name, mid->name) != 0)
+ dev_notice(dev, "Device mismatch: Configured %s, detected %s\n",
+ client->name, mid->name);
ret = i2c_smbus_read_block_data(client, PMBUS_MFR_REVISION, buf);
if (ret < 0) {
@@ -341,6 +375,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
if (!psu)
return 0;
+ psu->chip = chip_id;
psu->client = client;
debugfs = pmbus_get_debugfs_dir(client);
@@ -359,9 +394,6 @@ static int q54sj108a2_probe(struct i2c_client *client)
debugfs_create_file("write_protect", 0444, q54sj108a2_dir,
&psu->debugfs_entries[Q54SJ108A2_DEBUGFS_WRITEPROTECT],
&q54sj108a2_fops);
- debugfs_create_file("store_default", 0200, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
- &q54sj108a2_fops);
debugfs_create_file("vo_ov_response", 0644, q54sj108a2_dir,
&psu->debugfs_entries[Q54SJ108A2_DEBUGFS_VOOV_RESPONSE],
&q54sj108a2_fops);
@@ -383,27 +415,34 @@ static int q54sj108a2_probe(struct i2c_client *client)
debugfs_create_file("mfr_location", 0444, q54sj108a2_dir,
&psu->debugfs_entries[Q54SJ108A2_DEBUGFS_MFR_LOCATION],
&q54sj108a2_fops);
- debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
- &q54sj108a2_fops);
- debugfs_create_file("blackbox_read_offset", 0444, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ_OFFSET],
- &q54sj108a2_fops);
- debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
- &q54sj108a2_fops);
- debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
- &q54sj108a2_fops);
- debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
- &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
- &q54sj108a2_fops);
+ if (psu->chip == q54sj108a2) {
+ debugfs_create_file("store_default", 0200, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
+ &q54sj108a2_fops);
+ debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
+ &q54sj108a2_fops);
+ debugfs_create_file("blackbox_read_offset", 0444, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ_OFFSET],
+ &q54sj108a2_fops);
+ debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
+ &q54sj108a2_fops);
+ debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
+ &q54sj108a2_fops);
+ debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
+ &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
+ &q54sj108a2_fops);
+ }
return 0;
}
static const struct of_device_id q54sj108a2_of_match[] = {
- { .compatible = "delta,q54sj108a2", .data = (void *)q54sj108a2 },
+ { .compatible = "delta,q50sn12072" },
+ { .compatible = "delta,q54sj108a2" },
+ { .compatible = "delta,q54sn120a1" },
{ },
};
@@ -421,6 +460,6 @@ static struct i2c_driver q54sj108a2_driver = {
module_i2c_driver(q54sj108a2_driver);
MODULE_AUTHOR("Xiao.Ma <xiao.mx.ma@deltaww.com>");
-MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 series modules");
+MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 and compatibles");
MODULE_LICENSE("GPL");
MODULE_IMPORT_NS("PMBUS");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: trivial: Add q50sn12072 and q54sn120a1 support
From: Brian Chiang @ 2026-04-14 6:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng, Brian Chiang,
Jack Cheng
In-Reply-To: <20260414-add-support-for-q50sn12072-and-q54sn120a1-v4-0-b81eaea49df1@inventec.com>
From: Jack Cheng <cheng.jackhy@inventec.com>
Add support for the Delta Electronics q50sn12072 and q54sn120a1
1/4 Brick DC/DC Regulated Power Modules.
Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index a482aeadcd44..d4b78154df82 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -96,7 +96,11 @@ properties:
# Delta Electronics DPS920AB 920W 54V Power Supply
- delta,dps920ab
# 1/4 Brick DC/DC Regulated Power Module
+ - delta,q50sn12072
+ # 1/4 Brick DC/DC Regulated Power Module
- delta,q54sj108a2
+ # 1/4 Brick DC/DC Regulated Power Module
+ - delta,q54sn120a1
# Devantech SRF02 ultrasonic ranger in I2C mode
- devantech,srf02
# Devantech SRF08 ultrasonic ranger
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] Add support for q50sn12072 and q54sn120a1
From: Brian Chiang @ 2026-04-14 6:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng, Brian Chiang,
Jack Cheng
The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
module from Delta Power Modules.
The Q50SN12072, quarter brick, single output 12V. This product provides up
to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
efficiency up to 98.3%@54Vin.
The Q54SN120A1, quarter brick, single output 12V. This product provides up
to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
efficiency up to 98.1%@54Vin.
Add support for them to q54sj108a2 driver.
Signed-off-by: Jack Cheng <Cheng.JackHY@inventec.com>
Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
Changes in v4:
- Add null terminator to prevent comparison of uninitialized data which
takes place when ret is shorter than strlen(mid->name)
- Link to v3: https://lore.kernel.org/r/20260402-add-support-for-q50sn12072-and-q54sn120a1-v3-0-67a5184e93b8@inventec.com
Changes in v3:
- Fix MFR_MODEL detection by using strncasecmp prefix match, without the strict length equality
- Move blackbox_read_offset debugfs entry inside the q54sj108a2-only guard block
- Sort the debugfs entries by the order of PMBus register addresses
- Link to v2: https://lore.kernel.org/r/20260326-add-support-for-q50sn12072-and-q54sn120a1-v2-0-77bc77eedc76@inventec.com
Changes in v2:
- Drop Q50SN12072_DEBUGFS_VOUT_COMMAND debugfs entry
- Add .format[PSC_VOLTAGE_OUT] = linear explicitly to all three chip
entries for consistency
- Replace hardcoded MFR_MODEL check (ret != 14 || strncmp("Q54SJ108A2"))
with a loop over q54sj108a2_id[] using strncasecmp to support all
three chip variants dynamically
- Remove of_device_get_match_data()/i2c_match_id() early chip_id path;
derive chip_id exclusively from MFR_MODEL hardware read
- Remove unused .data fields from of_device_id entries
- Guard store_default, blackbox_erase, blackbox_set_offset, blackbox_read,
and flash_key debugfs entries under psu->chip == q54sj108a2 check
- Add dev_notice() when configured device name differs from detected model
- Update MODULE_DESCRIPTION to "PMBus driver for Delta Q54SJ108A2 and
compatibles"
- Fix commit message typo: "Q54SN12072" -> "Q50SN12072"
- Link to v1: https://lore.kernel.org/r/20250701-add-support-for-q50sn12072-and-q54sn120a1-v1-0-c387baf928cb@inventec.com
---
Jack Cheng (2):
dt-bindings: trivial: Add q50sn12072 and q54sn120a1 support
hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
.../devicetree/bindings/trivial-devices.yaml | 4 +
drivers/hwmon/pmbus/q54sj108a2.c | 105 ++++++++++++++-------
2 files changed, 76 insertions(+), 33 deletions(-)
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20250701-add-support-for-q50sn12072-and-q54sn120a1-a9c299e6d81d
Best regards,
--
Brian Chiang <chiang.brian@inventec.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: dt-bindings: ti,tas2781: Add TAS5832 support
From: Krzysztof Kozlowski @ 2026-04-14 6:56 UTC (permalink / raw)
To: Baojun Xu
Cc: broonie, tiwai, andriy.shevchenko, 13916275206, shenghao-ding,
linux-sound, linux-kernel, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, k-yi, henry.lo, robinchen, will-wang, jim.shil,
toastcheng, chinkaiting
In-Reply-To: <20260414015441.2439-1-baojun.xu@ti.com>
On Tue, Apr 14, 2026 at 09:54:40AM +0800, Baojun Xu wrote:
> TAS5832 is in same family with TAS5827/28/30.
>
> Signed-off-by: Baojun Xu <baojun.xu@ti.com>
> ---
> v2:
> - No update.
> ---
So you are going to just ignore review?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Krzysztof Kozlowski @ 2026-04-14 6:55 UTC (permalink / raw)
To: phucduc.bui
Cc: kuninori.morimoto.gx, broonie, lgirdwood, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, perex, tiwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-7-phucduc.bui@gmail.com>
On Mon, Apr 13, 2026 at 05:07:00PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The FSI on r8a7740 requires the SPU bus/bridge clock to be enabled before
> accessing its registers. Without this clock, any register access leads to
> a system hang as the FSI block sits behind the SPU bus.
> Update the binding to support a flexible positional clock list to properly
Flexible is not allowed. Provide reasons for exception.
> describe the hardware clock tree, including:
> - SPU bus/bridge clock (spu) for register access.
> - CPG DIV6 clocks (icka/b) as functional clock parents.
> - FSI internal dividers (diva/b) for audio clock generation.
> - External clock inputs (xcka/b) provided by the board.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>
> Changes in v2:
> - Rename FSI module clock to "own" to match driver.
> - Add "spu", "icka/b", "diva/b", "xcka/b" clock names.
> - Use YAML anchors to constrain clock-names properly.
> - Add "if" rule to require "spu" clock for r8a7740.
> - Update example with full clock configuration.
> - Clean up schema by moving allOf location.
>
> .../bindings/sound/renesas,fsi.yaml | 61 +++++++++++++++++--
> 1 file changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> index df91991699a7..d0ae54f3d321 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> @@ -9,9 +9,6 @@ title: Renesas FIFO-buffered Serial Interface (FSI)
> maintainers:
> - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> -allOf:
> - - $ref: dai-common.yaml#
> -
> properties:
> $nodename:
> pattern: "^sound@.*"
> @@ -38,7 +35,36 @@ properties:
> maxItems: 1
>
> clocks:
> - maxItems: 1
> + description: |
> + Clock driving the FSI Controller. The first clock must be
> + the module clock ("own").
> + minItems: 1
> + maxItems: 8
> +
> + clock-names:
> + description: |
> + Names of clocks corresponding to entries in "clocks":
> + - "own": Main FSI module clock (must be first and always present)
> + - "spu": SPU bus/bridge clock. On R8A7740, this clock must be
> + enabled to allow register access as the FSI block is connected
> + behind the SPU bus.
> + - "icka" / "ickb": CPG DIV6 functional clocks for FSI port A/B
> + - "diva"/"divb": Internal FSI dividers for port A/B used for
> + audio clock generation
> + - "xcka"/"xckb": External clock inputs for FSI port A/B
> + provided by the board
This goes to the "clocks:"
> + minItems: 1
> + items:
> + - const: own
> + - &fsi_all_clks
I don't understand this syntax.
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