* Re: [PATCH v4 1/8] mmc: sdhci-of-k1: enable essential clock, infrastructure for SD operation
From: Vincent Legoll @ 2026-03-29 9:20 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, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel, Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260323-orangepi-sd-card-uhs-v4-0-567c9775fd0e@gmail.com>
Hello,
I applied this series on top of cbfffcca2bf0622b601b7eaf477aa29035169184
(linux mainline from yesterday) and successfully booted the resulting
kernel from an SD card on an OrangePi-RV2 (with the vendor u-boot from
the SPI flash).
So if you want, you can add my: Tested-by: Vincent Legoll
<legoll@online.fr> # OrangePi-RV2 to the relevant patches from this
series Thanks Regards
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: clock: qcom, dispcc-sm6125: Add #reset-cells property
From: Krzysztof Kozlowski @ 2026-03-29 9:21 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, stable, kernel test robot
In-Reply-To: <20260329-ginkgo-add-usb-ir-vib-v2-2-870e0745e55e@gmail.com>
On Sun, Mar 29, 2026 at 04:47:57AM +0000, Biswapriyo Nath wrote:
> The '#reset-cells' property is permitted for the SM6125 SoC clock
> controllers, but not listed as a valid property.
Any reason why this binding file is the only dispcc not referencing
qcom,gcc.yaml? It should and it would solve the error. Look at other
files.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: clock: qcom, dispcc-sm6125: Add #reset-cells property
From: Krzysztof Kozlowski @ 2026-03-29 9:28 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, stable, kernel test robot
In-Reply-To: <20260329-amorphous-happy-deer-cea083@quoll>
On 29/03/2026 11:21, Krzysztof Kozlowski wrote:
> On Sun, Mar 29, 2026 at 04:47:57AM +0000, Biswapriyo Nath wrote:
>> The '#reset-cells' property is permitted for the SM6125 SoC clock
>> controllers, but not listed as a valid property.
>
> Any reason why this binding file is the only dispcc not referencing
> qcom,gcc.yaml? It should and it would solve the error. Look at other
> files.
... and you also need to update the example.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Krzysztof Kozlowski @ 2026-03-29 9:29 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-2-krishnagopi487@gmail.com>
On Sun, Mar 29, 2026 at 11:45:19AM +0530, Gopi Krishna Menon wrote:
> Convert the SPEAr Thermal Sensor bindings to DT schema.
>
> Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
> ---
> Changes since v1:
> - Changed unevaluatedProperties to additionalProperties
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Krzysztof Kozlowski @ 2026-03-29 9:31 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-3-krishnagopi487@gmail.com>
On Sun, Mar 29, 2026 at 11:45:20AM +0530, Gopi Krishna Menon wrote:
> st,thermal-flags is a required property in SPEAr Thermal Sensor node,
> which is incorrectly written as thermal_flags in spear13xx.dtsi.
>
> Rename thermal_flags to st,thermal-flags to fix the property name
Does this have an impact? If yes, then why no fixes? If no, then why
not? How this could ever worked? Maybe this is completely unnecessary.
We already talked about this and I don't get why this change is neeeded
and why we discuss the same problem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Krzysztof Kozlowski @ 2026-03-29 9:34 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329-starfish-of-eternal-storm-f16de5@quoll>
On 29/03/2026 11:31, Krzysztof Kozlowski wrote:
> On Sun, Mar 29, 2026 at 11:45:20AM +0530, Gopi Krishna Menon wrote:
>> st,thermal-flags is a required property in SPEAr Thermal Sensor node,
>> which is incorrectly written as thermal_flags in spear13xx.dtsi.
>>
>> Rename thermal_flags to st,thermal-flags to fix the property name
>
> Does this have an impact? If yes, then why no fixes? If no, then why
> not? How this could ever worked? Maybe this is completely unnecessary.
>
> We already talked about this and I don't get why this change is neeeded
> and why we discuss the same problem.
and by "this change" I meant, "rename" part, instead of "removal".
Your task is analyze entire code, understand what was wrong and provide
proper solution.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Krzysztof Kozlowski @ 2026-03-29 9:37 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-1-6098dc997d66@mainlining.org>
On Fri, Mar 27, 2026 at 09:11:43PM +0100, Barnabás Czémán wrote:
> Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
> is using mss-supply as a regulator usually it is pm8953_s1.
> Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
> as a pm domain.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> include/dt-bindings/power/qcom-rpmpd.h | 20 +++++++++++++-------
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> index 8174ceeab572..659936d6a46e 100644
> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> @@ -48,6 +48,7 @@ properties:
> - qcom,sc7280-rpmhpd
> - qcom,sc8180x-rpmhpd
> - qcom,sc8280xp-rpmhpd
> + - qcom,sdm632-rpmpd
> - qcom,sdm660-rpmpd
> - qcom,sdm670-rpmhpd
> - qcom,sdm845-rpmhpd
> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> index 4371ac941f29..2d82434b993c 100644
> --- a/include/dt-bindings/power/qcom-rpmpd.h
> +++ b/include/dt-bindings/power/qcom-rpmpd.h
> @@ -84,13 +84,11 @@
> #define QM215_VDDMX_AO MSM8917_VDDMX_AO
>
> /* MSM8953 Power Domain Indexes */
> -#define MSM8953_VDDMD 0
ABI break / impact and due to two changes combined I don't really
understand why. Why MSS using mss-supply makes this ABI invalid/wrong?
> -#define MSM8953_VDDMD_AO 1
> -#define MSM8953_VDDCX 2
> -#define MSM8953_VDDCX_AO 3
> -#define MSM8953_VDDCX_VFL 4
> -#define MSM8953_VDDMX 5
> -#define MSM8953_VDDMX_AO 6
> +#define MSM8953_VDDCX RPMPD_VDDCX
> +#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
> +#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
> +#define MSM8953_VDDMX RPMPD_VDDMX
> +#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
I don't see how this is related to new compatible and SDM632.
>
> /* MSM8974 Power Domain Indexes */
> #define MSM8974_VDDCX 0
> @@ -156,6 +154,14 @@
> #define QCS404_LPIMX 5
> #define QCS404_LPIMX_VFL 6
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: media: convert hix5hd2-ir to DT schema
From: Krzysztof Kozlowski @ 2026-03-29 9:45 UTC (permalink / raw)
To: Pranav Kharche
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mauro Carvalho Chehab, linux-media, devicetree
In-Reply-To: <20260328084238.201452-2-pranavkharche7@gmail.com>
On Sat, Mar 28, 2026 at 02:12:38PM +0530, Pranav Kharche wrote:
> Convert the legacy plaintext binding for HiSilicon hix5hd2 IR remote
> controller to JSON Schema (DT schema) format in YAML.
>
> This binding documents the infrared remote receiver found in HiSilicon
> SoCs such as hix5hd2 and hi3796cv300. The conversion includes:
>
> - Standardized property definitions with types and constraints
Drop
> - Reference to rc.yaml base schema for remote controller properties
Drop
> - Addition of include directives for interrupt-controller bindings
Drop
> - Proper example with GIC interrupt specifiers
Drop
> - Schema validation support for device tree sources
Drop
>
> The new schema enables:
> - Validation improvement
Drop
>
> tested with: make dt_binding_check DT_SCHEMA_FILES=...
> All schema validation checks pass.
Drop
Please write useful commit msgs, meaning you do not need to state
obvious things. Plenty of examples in git log.
What you MUST say here is documenting the changes you done to the
binding. You removed existing property which is not explained at all,
introduces undocumented ABI and adds new warnings. No, seriously, no.
And if you TESTED this you would see errors, so back to basic
requirements of schema conversion - see my posts on social.kernel.org.
>
> Signed-off-by: Pranav Kharche <pranavkharche7@gmail.com>
> ---
> .../devicetree/bindings/media/hix5hd2-ir.txt | 26 ---------
> .../devicetree/bindings/media/hix5hd2-ir.yaml | 53 +++++++++++++++++++
> 2 files changed, 53 insertions(+), 26 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
> create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
> deleted file mode 100644
> index ca4cf774662e..000000000000
> --- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -Device-Tree bindings for hix5hd2 ir IP
> -
> -Required properties:
> - - compatible: Should contain "hisilicon,hix5hd2-ir", or:
> - - "hisilicon,hi3796cv300-ir" for Hi3796CV300 IR device.
> - - reg: Base physical address of the controller and length of memory
> - mapped region.
> - - interrupts: interrupt-specifier for the sole interrupt generated by
> - the device. The interrupt specifier format depends on the interrupt
> - controller parent.
> - - clocks: clock phandle and specifier pair.
> -
> -Optional properties:
> - - linux,rc-map-name: see rc.txt file in the same directory.
> - - hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
> - Provide correct clocks instead.
> -
> -Example node:
> -
> - ir: ir@f8001000 {
> - compatible = "hisilicon,hix5hd2-ir";
> - reg = <0xf8001000 0x1000>;
> - interrupts = <0 47 4>;
> - clocks = <&clock HIX5HD2_IR_CLOCK>;
> - linux,rc-map-name = "rc-tivo";
> - };
> diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.yaml b/Documentation/devicetree/bindings/media/hix5hd2-ir.yaml
> new file mode 100644
> index 000000000000..91cba6ec88c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.yaml
Filename must match the compatible, choose one.
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/hix5hd2-ir.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HiSilicon Hix5hd2 infrared remote controller
> +
> +maintainers:
> + - Pranav Kharche <pranavkharche7@gmail.com>
> +
> +allOf:
> + - $ref: rc.yaml#
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + This binding describes the infrared remote controller found in
So description describes that your binding describes... No, drop.
Explain the hardware and if you do not have any explanation, no need to
state obvious and paste here compatibles.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Dmitry Baryshkov @ 2026-03-29 9:51 UTC (permalink / raw)
To: Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <39a320e472ddc6d44c950a995b577e77@mainlining.org>
On Sat, Mar 28, 2026 at 09:22:19AM +0100, Barnabás Czémán wrote:
> On 2026-03-27 21:26, Dmitry Baryshkov wrote:
> > On Fri, Mar 27, 2026 at 09:11:43PM +0100, Barnabás Czémán wrote:
> > > Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
> > > is using mss-supply as a regulator usually it is pm8953_s1.
> > > Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
> > > as a pm domain.
> > >
> > > Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> > > ---
> > > .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> > > include/dt-bindings/power/qcom-rpmpd.h | 20
> > > +++++++++++++-------
> > > 2 files changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> > > b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> > > index 8174ceeab572..659936d6a46e 100644
> > > --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> > > +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> > > @@ -48,6 +48,7 @@ properties:
> > > - qcom,sc7280-rpmhpd
> > > - qcom,sc8180x-rpmhpd
> > > - qcom,sc8280xp-rpmhpd
> > > + - qcom,sdm632-rpmpd
> > > - qcom,sdm660-rpmpd
> > > - qcom,sdm670-rpmhpd
> > > - qcom,sdm845-rpmhpd
> > > diff --git a/include/dt-bindings/power/qcom-rpmpd.h
> > > b/include/dt-bindings/power/qcom-rpmpd.h
> > > index 4371ac941f29..2d82434b993c 100644
> > > --- a/include/dt-bindings/power/qcom-rpmpd.h
> > > +++ b/include/dt-bindings/power/qcom-rpmpd.h
> > > @@ -84,13 +84,11 @@
> > > #define QM215_VDDMX_AO MSM8917_VDDMX_AO
> > >
> > > /* MSM8953 Power Domain Indexes */
> > > -#define MSM8953_VDDMD 0
> > > -#define MSM8953_VDDMD_AO 1
> > > -#define MSM8953_VDDCX 2
> > > -#define MSM8953_VDDCX_AO 3
> > > -#define MSM8953_VDDCX_VFL 4
> > > -#define MSM8953_VDDMX 5
> > > -#define MSM8953_VDDMX_AO 6
> > > +#define MSM8953_VDDCX RPMPD_VDDCX
> > > +#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
> > > +#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
> > > +#define MSM8953_VDDMX RPMPD_VDDMX
> > > +#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
> >
> > Well, no. This is an ABI break. It will make previous DT to stop from
> > working. You can drop unused indices, but you can not change the values
> > used by the existing domains.
> Do these indices never can be changed?
You can add new indices and you can (with some care) drop existing
incorrecr or unused ones. You can't reassign indices though. The rule of
thumb is that old DTs should continue to work without rebuilding.
> >
> > >
> > > /* MSM8974 Power Domain Indexes */
> > > #define MSM8974_VDDCX 0
> > > @@ -156,6 +154,14 @@
> > > #define QCS404_LPIMX 5
> > > #define QCS404_LPIMX_VFL 6
> > >
> > > +/* SDM632 Power Domain Indexes */
> > > +#define SDM632_VDDMD 0
> > > +#define SDM632_VDDCX 1
> > > +#define SDM632_VDDCX_AO 2
> > > +#define SDM632_VDDCX_VFL 3
> > > +#define SDM632_VDDMX 4
> > > +#define SDM632_VDDMX_AO 5
> >
> > Please use RPMHPD_* instead of introducing new entries.
> I do not understand completely, should I use RPHPD bindings in rpmpd driver
> or
> I should use rpmhpd driver for SDM632?
Sorry, I meant RPMPD_*
> >
> > > +
> > > /* SDM660 Power Domains */
> > > #define SDM660_VDDCX RPMPD_VDDCX
> > > #define SDM660_VDDCX_AO RPMPD_VDDCX_AO
> > >
> > > --
> > > 2.53.0
> > >
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac-sku support
From: Krzysztof Kozlowski @ 2026-03-29 9:52 UTC (permalink / raw)
To: Umang Chheda
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260328-monaco-evk-ac-sku-v1-1-79d166fa5571@oss.qualcomm.com>
On Sat, Mar 28, 2026 at 05:11:17PM +0530, Umang Chheda wrote:
> Introduce new bindings for the monaco-evk-ac-sku,
> an IoT board based on the QCS8300-AC variant SoC.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index ca880c105f3b..07053cc2ac1c 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -918,6 +918,7 @@ properties:
> - enum:
> - arduino,monza
> - qcom,monaco-evk
> + - qcom,monaco-evk-ac-sku
Why adding name 'sku' to the compatible? What's the meaning here?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/7] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add PMI632 Type-C property
From: Dmitry Baryshkov @ 2026-03-29 9:52 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, stable, Konrad Dybcio
In-Reply-To: <20260329-ginkgo-add-usb-ir-vib-v2-5-870e0745e55e@gmail.com>
On Sun, Mar 29, 2026 at 04:48:00AM +0000, Biswapriyo Nath wrote:
> The USB-C port is used for powering external devices and transfer
> data from/to them.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> ---
> .../boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: sdm670-google-common: enable debug uart
From: Dmitry Baryshkov @ 2026-03-29 9:55 UTC (permalink / raw)
To: pabloyoyoista
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Richard Acayan, ~postmarketos/upstreaming
In-Reply-To: <20260328-pabloyoyoista-debug-uart-on-rdacayan-next-v2-3-53abd9db8f0a@postmarketos.org>
On Sat, Mar 28, 2026 at 11:58:42PM +0100, Pablo Correa Gómez via B4 Relay wrote:
> From: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
>
> This has been tested on the Pixel 3a with USB Cereal board
>
> Depends on
> https://lore.kernel.org/all/20260310002606.16413-5-mailingradian@gmail.com/
>
> Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
> ---
> arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: sdm670: add debug uart soc node
From: Dmitry Baryshkov @ 2026-03-29 9:55 UTC (permalink / raw)
To: pabloyoyoista
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Richard Acayan, ~postmarketos/upstreaming
In-Reply-To: <20260328-pabloyoyoista-debug-uart-on-rdacayan-next-v2-2-53abd9db8f0a@postmarketos.org>
On Sat, Mar 28, 2026 at 11:58:41PM +0100, Pablo Correa Gómez via B4 Relay wrote:
> From: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
>
> Values are taken from the other geni nodes
>
> Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
> ---
> arch/arm64/boot/dts/qcom/sdm670.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/6] drm/panel: Add driver for Novatek NT35532
From: Dmitry Baryshkov @ 2026-03-29 10:05 UTC (permalink / raw)
To: cristian_ci
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260327-rimob-new-features-v4-2-06edff9c4509@protonmail.com>
On Fri, Mar 27, 2026 at 03:30:48PM +0100, Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino <cristian_ci@protonmail.com>
>
> Add support for Novatek NT35532-based 1080p video mode DSI panel.
>
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/gpu/drm/panel/Kconfig | 10 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-novatek-nt35532.c | 796 ++++++++++++++++++++++++++
> 4 files changed, 808 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable display and GPU
From: Dmitry Baryshkov @ 2026-03-29 10:12 UTC (permalink / raw)
To: cristian_ci
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <O7THc5h8ZhgzNpklYKTGOnEZKlN4BtHZHjKZt2KErekNb3E-hizt2dw7xuJ8G6giEyivmvC0f6-eIfCT6fJkUA7_CVQwhAktCXfBqAVV_Zo=@protonmail.com>
On Sat, Mar 28, 2026 at 05:30:53PM +0000, cristian_ci wrote:
> On Friday, March 27th, 2026 at 23:57, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> > On Fri, Mar 27, 2026 at 03:30:49PM +0100, Cristian Cozzolino via B4 Relay wrote:
> > > From: Cristian Cozzolino <cristian_ci@protonmail.com>
> > >
> > > Add the description for the display panel found on this phone.
> > > And with this done we can also enable the GPU and set the zap shader
> > > firmware path.
> > >
> > > Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> > > ---
> > > .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 73 ++++++++++++++++++++++
> > > 1 file changed, 73 insertions(+)
> > >
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> I wonder if I should, instead, edit the compatible property by adding a
> second string (for the fallback), like this:
>
> compatible = "flipkart,rimob-panel-nt35532-cs", "novatek,nt35532";
>
> and, therefore, add "novatek,nt35532" string also to (patch 1/6)'s
> bindings example. Let me know what you think.
What would it mean? I think we usually don't include the IC into the
compat list for the panel, but feel free to prove me wrong.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Arend van Spriel @ 2026-03-29 10:21 UTC (permalink / raw)
To: Ronald Claveau, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, van Spriel
Cc: linux-wireless, devicetree, linux-kernel, netdev, Conor Dooley
In-Reply-To: <20260327-add-bcm43752-compatible-v2-1-5b28e6637101@aliel.fr>
On 27/03/2026 10:36, Ronald Claveau wrote:
> Add bcm43752 compatible with its bcm4329 compatible fallback.
Hi Johannes,
I moved this patch to you in patchwork. In response by Neil Armstrong to
earlier proposed patch it seems he prefers this to go through the
wireless or networking tree.
Regards,
Arend
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> The Khadas VIM4 board based on Amlogic A311D2 aka T7 features an AP6275s Wi-Fi/Bluetooth module with a BCM43752 chipset.
> This patch aims to add this chipset with its fallback to bcm4329 compatible.
>
> The original patch series is here:
> https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr
> ---
> Changes in v2:
> - Add netdev in CC.
> - Link to v1: https://lore.kernel.org/r/20260326-add-bcm43752-compatible-v1-1-b3b9a58ab38b@aliel.fr
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: fix remaining gpu_zap_shader labels
From: Dmitry Baryshkov @ 2026-03-29 10:22 UTC (permalink / raw)
To: Tobias Heider
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260328-zap-v1-1-f6810b9b4930@canonical.com>
On Sat, Mar 28, 2026 at 04:49:21PM +0100, Tobias Heider wrote:
> Most qcom DTs were converted to use the gpu_zap_shader label instead
> of patching the gpu node in commit 2377626fd216 ("arm64: dts: qcom:
> add gpu_zap_shader label"). This fixes the remaining ones.
>
> Signed-off-by: Tobias Heider <tobias.heider@canonical.com>
> ---
> arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi | 8 ++++----
> arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: drop redundant zap-shader memory-region
From: Dmitry Baryshkov @ 2026-03-29 10:23 UTC (permalink / raw)
To: Tobias Heider
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260328-zap-v1-2-f6810b9b4930@canonical.com>
On Sat, Mar 28, 2026 at 04:49:22PM +0100, Tobias Heider wrote:
> This is already defined in the gpu_zap_shader node in hamoa.dtsi,
> there is no need to redefine it.
>
> Signed-off-by: Tobias Heider <tobias.heider@canonical.com>
> ---
> arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi | 1 -
> arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 1/6] dt-bindings: pinctrl: add NXP MC33978/MC34978 MSDI
From: Rob Herring (Arm) @ 2026-03-29 10:30 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Linus Walleij, linux-kernel, kernel, Lee Jones, devicetree,
David Jander, Krzysztof Kozlowski, linux-hwmon, linux-gpio,
Guenter Roeck, Peter Rosin, Conor Dooley
In-Reply-To: <20260329090601.532477-2-o.rempel@pengutronix.de>
On Sun, 29 Mar 2026 11:05:56 +0200, Oleksij Rempel wrote:
> Add device tree binding documentation for the NXP MC33978 and MC34978
> Multiple Switch Detection Interface (MSDI) devices.
>
> The MC33978 and MC34978 differ primarily in their operating temperature
> ranges. While not software-detectable, providing specific compatible
> strings allows the hwmon subsystem to correctly interpret thermal
> thresholds and hardware faults.
>
> These ICs monitor up to 22 mechanical switch contacts in automotive and
> industrial environments. They provide configurable wetting currents to
> break through contact oxidation and feature extensive hardware
> protection against thermal overload and voltage transients (load
> dumps/brown-outs).
>
> The device interfaces via SPI. While it provides multiple functions, its
> primary hardware purpose is pin/switch control. To accurately represent
> the hardware as a single physical integrated circuit without unnecessary
> DT overhead, all functions are flattened into a single pinctrl node:
> - pinctrl: Exposing the 22 switch inputs (SG/SP pins) as a GPIO controller
> and managing their pin configurations.
> - hwmon: Exposing critical hardware faults (OT, OV, UV) and static
> voltage/temperature thresholds.
> - mux: Controlling the 24-to-1 analog multiplexer to route pin voltages,
> internal temperature, or battery voltage to an external SoC ADC.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> ---
> changes v8:
> - Update IRQ_TYPE_* macros include path reference in documentation from
> interrupt-controller.h to dt-bindings/interrupt-controller/irq.h.
> - Add bias-disable, drive-open-drain, drive-open-source, and drive-strength
> to the list of supported pin configuration properties.
> changes v7:
> - no changes
> changes v6:
> - add Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> - add Reviewed-by: Linus Walleij <linusw@kernel.org>
> changes v5:
> - Commit Message: Added justification for distinct compatible strings
> based on temperature ranges.
> - Restricted pins property to an explicit enum of valid hardware pins
> changes v4:
> - Drop the standalone mfd/nxp,mc33978.yaml schema entirely.
> - Move the unified device binding to bindings/pinctrl/nxp,mc33978.yaml,
> - Remove the dedicated child node compatible strings (nxp,mc33978-pinctrl).
> - Flatten the pinctrl/gpio properties directly into the main SPI device
> node.
> changes v3:
> - Drop regular expression pattern from pinctrl child node and define
> it as a standard property
> - Reorder required properties list in MFD binding
> - Remove stray blank line from the MFD binding devicetree example
> - Replace unevaluatedProperties with additionalProperties in the pinctrl
> binding
> changes v2:
> - Squashed MFD, pinctrl, hwmon, and mux bindings into a single patch
> - Removed the empty hwmon child node
> - Folded the mux-controller node into the parent MFD node
> - Added vbatp-supply and vddq-supply to the required properties block
> - Changed the example node name from mc33978@0 to gpio@0
> - Removed unnecessary literal block scalars (|) from descriptions
> - Documented SG, SP, and SB pin acronyms in the pinctrl description
> - Added consumer polarity guidance (GPIO_ACTIVE_LOW/HIGH) for SG/SB
> inputs, with a note on output circuit dependency
> - Updated commit message
> ---
> .../bindings/pinctrl/nxp,mc33978.yaml | 158 ++++++++++++++++++
> 1 file changed, 158 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/nxp,mc33978.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pinctrl/nxp,mc33978.example.dtb: gpio@0 (nxp,mc33978): $nodename:0: 'gpio@0' does not match '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
from schema $id: http://devicetree.org/schemas/mux/mux-controller.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260329090601.532477-2-o.rempel@pengutronix.de
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
* [PATCH 1/2] dt-bindings: arm: qcom: Add SM7325 Motorola edge 30 (dubai)
From: Val Packett @ 2026-03-29 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Val Packett, linux-arm-msm, devicetree, linux-kernel
Motorola edge 30 (motorola,dubai) is a smartphone based on the
SM7325 SoC.
Signed-off-by: Val Packett <val@packett.cool>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index ca880c105f3b..58f1621bb855 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1038,6 +1038,7 @@ properties:
- items:
- enum:
+ - motorola,dubai
- nothing,spacewar
- const: qcom,sm7325
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: Add Motorola edge 30 (dubai) DTS
From: Val Packett @ 2026-03-29 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kees Cook, Tony Luck, Guilherme G. Piccoli
Cc: Val Packett, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329103055.96649-1-val@packett.cool>
The Motorola edge 30 is a smartphone released in 2022.
This commit has the following features working:
- Display (simplefb)
- Touchscreen
- Power and volume buttons
- Storage (UFS 3.1)
- Battery (ADSP battmgr)
- USB (Type-C, 2.0, dual-role)
- Wi-Fi and Bluetooth (WCN6750 hw1.0)
Signed-off-by: Val Packett <val@packett.cool>
---
My new main phone, it's very cool :)
Left out for now, will send after this lands:
- actual panel (Novatek NT37701 based)
- apparently the first to need different prepare commands depending on
refresh rate, have a WIP patch to pass the info already, expecting that
to go through some discussion though..
- seems impossible to find model numbers, there are 2 vendors (Tianma
and CSOT) but there's no info online for a 6.55" NT37701 based panel
made by either company
- audio (Awinic AW88261 + WCD9375)
- waiting for the Senary MI2S series to land for the speakers
- only have the top (aux) mic working but not the bottom (main) one o.0
- camera (Samsung S5KJN1 as ultrawide)
- still polishing the tiny driver from downstream for the WL2864C PMIC
Did not bring up yet:
- other cameras (OV50A main, OV32B40 front): need drivers >_<
- haptics (AW86224): needs to be added to AW86927 driver (similar regs)
ath11k bdf sent:
https://lists.infradead.org/pipermail/ath11k/2026-March/008314.html
Thanks,
~val
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm7325-motorola-dubai.dts | 1474 +++++++++++++++++
2 files changed, 1475 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c46d94bb6dd5..c4d5dba342e3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -334,6 +334,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm6375-sony-xperia-murray-pdx225.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-curtana.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-joyeuse.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7225-fairphone-fp4.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm7325-motorola-dubai.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7325-nothing-spacewar.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-microsoft-surface-duo.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts b/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
new file mode 100644
index 000000000000..2be4f235a80b
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm7325-motorola-dubai.dts
@@ -0,0 +1,1474 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) 2026, Val Packett <val@packett.cool>
+ */
+
+/dts-v1/;
+
+/* PM7250B is configured to use SID8/9 */
+#define PM7250B_SID 8
+#define PM7250B_SID1 9
+
+#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "sm7325.dtsi"
+#include "pm7325.dtsi"
+#include "pm7250b.dtsi"
+#include "pm8350c.dtsi" /* PM7350C */
+#include "pmk8350.dtsi" /* PMK7325 */
+
+/ {
+ model = "Motorola edge 30";
+ compatible = "motorola,dubai", "qcom,sm7325";
+ chassis-type = "handset";
+
+ aliases {
+ bluetooth0 = &bluetooth;
+ serial0 = &uart5;
+ serial1 = &uart7;
+ wifi0 = &wifi;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ stdout-path = "serial0:115200n8";
+
+ framebuffer0: framebuffer@e1000000 {
+ compatible = "simple-framebuffer";
+ reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
+ width = <1080>;
+ height = <2400>;
+ stride = <(1080 * 4)>;
+ format = "a8r8g8b8";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&kypd_vol_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&pm7325_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm7325-pmic-glink",
+ "qcom,qcm6490-pmic-glink",
+ "qcom,pmic-glink";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ orientation-gpios = <&tlmm 140 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_sbu: endpoint {
+ remote-endpoint = <&fsa4480_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ramoops@ae000000 {
+ compatible = "ramoops";
+ reg = <0x0 0xae000000 0x0 0xc0000>;
+ console-size = <0x40000>;
+ mem-type = <2>;
+ pmsg-size = <0x40000>;
+ record-size = <0x3f800>;
+ };
+
+ removed@c0000000 {
+ reg = <0x0 0xc0000000 0x0 0x5100000>;
+ no-map;
+ };
+
+ cont-splash@e1000000 {
+ reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
+ no-map;
+ };
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ size = <0x0 0x8000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
+ thermal-zones {
+ cam-flash-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 2>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ chg-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ chg-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 4>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ conn-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-1-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 5>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-2-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 6>;
+
+ /* Reports negative temperature. */
+ status = "disabled";
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ quiet-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ sdm-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 3>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ xo-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
+ // S2B is really ebi.lvl but it's there for supply map completeness sake.
+ vreg_s2b_0p7: smpb2-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s2b_0p7";
+
+ regulator-min-microvolt = <65535>;
+ regulator-max-microvolt = <65535>;
+ regulator-always-on;
+ vin-supply = <&vph_pwr>;
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ };
+
+ wcn6750-pmu {
+ compatible = "qcom,wcn6750-pmu";
+ pinctrl-0 = <&bt_en>;
+ pinctrl-names = "default";
+ vddaon-supply = <&mos_0p95_aon_s10c>;
+ vddasd-supply = <&vreg_l11c_2p8>;
+ vddpmu-supply = <&mos_0p95_dig_s10c>;
+ vddio-supply = <&vdd18_io>;
+ vddrfa0p8-supply = <&vdd09_pmu_rfa_i>;
+ vddrfa1p2-supply = <&vdd13_pmu_rfa_i>;
+ vddrfa1p7-supply = <&vdd19_pmu_rfa_i>;
+ vddrfa2p2-supply = <&vdd22_wlpa_s1c>;
+
+ bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm7325-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+
+ vdd-l1-l4-l12-l15-supply = <&vreg_s7b_0p952>;
+ vdd-l2-l7-supply = <&vreg_bob>;
+ vdd-l3-supply = <&vreg_s2b_0p7>;
+ vdd-l5-supply = <&vreg_s2b_0p7>;
+ vdd-l6-l9-l10-supply = <&vreg_s8b_1p256>;
+ vdd-l8-supply = <&vreg_s7b_0p952>;
+ vdd-l11-l17-l18-l19-supply = <&vreg_s1b_1p856>;
+ vdd-l13-supply = <&vreg_s7b_0p952>;
+ vdd-l14-l16-supply = <&vreg_s8b_1p256>;
+
+ /*
+ * S2, L4-L5 are ARCs:
+ * S2 - ebi.lvl,
+ * L4 - lmx.lvl,
+ * l5 - lcx.lvl.
+ *
+ * L10 are unused.
+ */
+
+ vdd19_pmu_rfa_i:
+ vreg_s1b_1p856: smps1 {
+ regulator-name = "vreg_s1b_1p856";
+ regulator-min-microvolt = <1840000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ mos_0p95_aon_s10c:
+ mos_0p95_dig_s10c:
+ vdd09_pmu_rfa_i:
+ vreg_s7b_0p952: smps7 {
+ regulator-name = "vreg_s7b_0p952";
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ };
+
+ vdd13_pmu_rfa_i:
+ vreg_s8b_1p256: smps8 {
+ regulator-name = "vreg_s8b_1p256";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
+ };
+
+ vreg_l1b_0p912: ldo1 {
+ regulator-name = "vreg_l1b_0p912";
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <925000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_usbhs_3p1:
+ vreg_l2b_3p072: ldo2 {
+ regulator-name = "vreg_l2b_3p072";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3b_0p6: ldo3 {
+ regulator-name = "vreg_l3b_0p6";
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <910000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_dsi_0_1p2:
+ vdd_a_ufs_0_1p2:
+ vreg_l6b_1p2: ldo6 {
+ regulator-name = "vreg_l6b_1p2";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p96: ldo7 {
+ regulator-name = "vreg_l7b_2p96";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_0p904: ldo8 {
+ regulator-name = "vreg_l8b_0p904";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_1p2: ldo9 {
+ regulator-name = "vreg_l9b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p776: ldo11 {
+ regulator-name = "vreg_l11b_1p776";
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_0p8: ldo12 {
+ regulator-name = "vreg_l12b_0p8";
+ regulator-min-microvolt = <751000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_0p8: ldo13 {
+ regulator-name = "vreg_l13b_0p8";
+ regulator-min-microvolt = <530000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_1p2: ldo14 {
+ regulator-name = "vreg_l14b_1p2";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_0p88: ldo15 {
+ regulator-name = "vreg_l15b_0p88";
+ regulator-min-microvolt = <765000>;
+ regulator-max-microvolt = <1020000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_1p2: ldo16 {
+ regulator-name = "vreg_l16b_1p2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_1p8: ldo17 {
+ regulator-name = "vreg_l17b_1p8";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_1p8: ldo18 {
+ regulator-name = "vreg_l18b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd18_io:
+ vreg_l19b_1p8: ldo19 {
+ regulator-name = "vreg_l19b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8350c-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s9-supply = <&vph_pwr>;
+ vdd-s10-supply = <&vph_pwr>;
+
+ vdd-l1-l12-supply = <&vreg_s1b_1p856>;
+ vdd-l2-l8-supply = <&vreg_s1b_1p856>;
+ vdd-l3-l4-l5-l7-l13-supply = <&vreg_bob>;
+ vdd-l6-l9-l11-supply = <&vreg_bob>;
+ vdd-l10-supply = <&vreg_s7b_0p952>;
+
+ vdd-bob-supply = <&vph_pwr>;
+
+ /*
+ * S2, S5, S7, S10 are ARCs:
+ * S2 - cx.lvl,
+ * S5 - mss.lvl,
+ * S7 - gfx.lvl,
+ * S10 - mx.lvl.
+ */
+
+ vdd22_wlpa_s1c:
+ vreg_s1c_2p2: smps1 {
+ regulator-name = "vreg_s1c_2p2";
+ regulator-min-microvolt = <2190000>;
+ regulator-max-microvolt = <2210000>;
+ };
+
+ vreg_s9c_0p676: smps9 {
+ regulator-name = "vreg_s9c_0p676";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ };
+
+ vdd_a_usbhs_1p8:
+ vdd_qfprom:
+ vreg_l1c_1p8: ldo1 {
+ regulator-name = "vreg_l1c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ iovdd_ts:
+ vreg_l2c_1p8: ldo2 {
+ regulator-name = "vreg_l2c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_ts:
+ vreg_l3c_3p0: ldo3 {
+ regulator-name = "vreg_l3c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c_1p8_3p0: ldo4 {
+ regulator-name = "vreg_l4c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5c_1p8_3p0: ldo5 {
+ regulator-name = "vreg_l5c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c_2p96: ldo6 {
+ regulator-name = "vreg_l6c_2p96";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+ regulator-name = "vreg_l7c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c_1p8: ldo8 {
+ regulator-name = "vreg_l8c_1p8";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c_3p3: ldo9 {
+ regulator-name = "vreg_l9c_2p96";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_dsi_0_0p9:
+ vdd_a_ufs_0_core:
+ vdd_a_usbhs_core:
+ vreg_l10c_0p88: ldo10 {
+ regulator-name = "vreg_l10c_0p88";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11c_2p8: ldo11 {
+ regulator-name = "vreg_l11c_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ disp_iovcc_1p8:
+ vreg_l12c_1p8: ldo12 {
+ regulator-name = "vreg_l12c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ disp_vci_3p0:
+ vreg_l13c_3p0: ldo13 {
+ regulator-name = "vreg_l13c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ audio_sw_vcc:
+ vreg_bob: bob {
+ regulator-name = "vreg_bob";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
+
+&gcc {
+ protected-clocks = <GCC_CFG_NOC_LPASS_CLK>,
+ <GCC_MSS_CFG_AHB_CLK>,
+ <GCC_MSS_OFFLINE_AXI_CLK>,
+ <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
+ <GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <GCC_QSPI_CORE_CLK>,
+ <GCC_QSPI_CORE_CLK_SRC>,
+ <GCC_SEC_CTRL_CLK_SRC>,
+ <GCC_WPSS_AHB_BDG_MST_CLK>,
+ <GCC_WPSS_AHB_CLK>,
+ <GCC_WPSS_RSCP_CLK>;
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/sm7325/motorola/dubai/a660_zap.mbn";
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+
+ status = "okay";
+
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
+
+ interrupts-extended = <&tlmm 6 IRQ_TYPE_LEVEL_LOW>;
+
+ vcc-supply = <&audio_sw_vcc>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+ };
+};
+
+&ipa {
+ firmware-name = "qcom/sm7325/motorola/dubai/yupik_ipa_fws.mbn";
+ memory-region = <&ipa_fw_mem>;
+
+ qcom,gsi-loader = "self";
+
+ status = "okay";
+};
+
+&pm7250b_adc {
+ channel@4e {
+ reg = <ADC5_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "chg_skin_therm";
+ };
+
+ channel@4f {
+ reg = <ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "conn_therm";
+ };
+};
+
+&pm7250b_adc_tm {
+ status = "okay";
+
+ chg-skin-therm@0 {
+ reg = <0>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ conn-therm@1 {
+ reg = <1>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pm7250b_gpios {
+ gpio-line-names = "FG_ALERT_N", /* GPIO_1 */
+ "SLAVECP_INT",
+ "NC",
+ "NC",
+ "NC",
+ "DOUBLER_STAT",
+ "NC",
+ "NC",
+ "NC",
+ "NC", /* GPIO_10 */
+ "NC",
+ "NC";
+};
+
+&pm7325_gpios {
+ gpio-line-names = "PA_THERM1", /* GPIO_1 */
+ "NC",
+ "NC",
+ "PA_THERM2",
+ "CBL_PWR_N",
+ "KYPD_VOL_UP_N",
+ "NC",
+ "NC",
+ "NC",
+ "NC"; /* GPIO_10 */
+
+ kypd_vol_up_n: kypd-volp-n-state {
+ pins = "gpio6";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ bias-pull-up;
+ input-enable;
+ power-source = <1>;
+ };
+};
+
+&pm8350c_gpios {
+ gpio-line-names = "NC", /* GPIO_1 */
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "NC"; /* GPIO_9 */
+};
+
+&pm8350c_flash {
+ status = "okay";
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <4>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <400000>;
+ };
+
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <2>, <3>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <400000>;
+ };
+};
+
+&pmk8350_adc_tm {
+ status = "okay";
+
+ xo-therm@0 {
+ reg = <0>;
+ io-channels = <&pmk8350_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ quiet-therm@1 {
+ reg = <1>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ cam-flash-therm@2 {
+ reg = <2>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ sdm-skin-therm@3 {
+ reg = <3>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ chg-therm@4 {
+ reg = <4>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ pa-therm-1@5 {
+ reg = <5>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_GPIO1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ pa-therm-2@6 {
+ reg = <6>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_GPIO4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pmk8350_gpios {
+ gpio-line-names = "NC", /* GPIO_0 */
+ "NC",
+ "TP_PMK_GPIO_3",
+ "PMK_OPTION"; /* GPIO_4 */
+};
+
+&pmk8350_rtc {
+ status = "okay";
+};
+
+&pmk8350_vadc {
+ status = "okay";
+
+ channel@44 {
+ reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pmk8350_xo_therm";
+ };
+
+ channel@144 {
+ reg = <PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_quiet_therm";
+ };
+
+ channel@145 {
+ reg = <PM7325_ADC7_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_cam_flash_therm";
+ };
+
+ channel@146 {
+ reg = <PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_sdm_skin_therm";
+ };
+
+ channel@147 {
+ reg = <PM7325_ADC7_AMUX_THM4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_chg_therm";
+ };
+
+ channel@14a {
+ reg = <PM7325_ADC7_GPIO1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_pa_therm1";
+ };
+
+ channel@14d {
+ reg = <PM7325_ADC7_GPIO4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_pa_therm2";
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qfprom {
+ vcc-supply = <&vdd_qfprom>;
+};
+
+&qup_spi13_cs {
+ drive-strength = <6>;
+ bias-pull-down;
+};
+
+&qup_spi13_data_clk {
+ drive-strength = <6>;
+ bias-pull-down;
+};
+
+&qup_uart5_rx {
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart5_tx {
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart7_cts {
+ /*
+ * Configure a bias-bus-hold on CTS to lower power
+ * usage when Bluetooth is turned off. Bus hold will
+ * maintain a low power state regardless of whether
+ * the Bluetooth module drives the pin in either
+ * direction or leaves the pin fully unpowered.
+ */
+ bias-bus-hold;
+};
+
+&qup_uart7_rts {
+ /* We'll drive RTS, so no pull */
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qup_uart7_rx {
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module is
+ * in tri-state (module powered off or not driving the
+ * signal yet).
+ */
+ bias-pull-up;
+};
+
+&qup_uart7_tx {
+ /* We'll drive TX, so no pull */
+ drive-strength = <2>;
+ bias-disable;
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm7325/motorola/dubai/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm7325/motorola/dubai/cdsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/sm7325/motorola/dubai/modem.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_wpss {
+ firmware-name = "qcom/sm7325/motorola/dubai/wpss.mbn";
+
+ status = "okay";
+};
+
+&rmtfs_mem {
+ qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>,
+ <QCOM_SCM_VMID_NAV>;
+};
+
+&spi13 {
+ status = "okay";
+
+ touchscreen@0 {
+ compatible = "goodix,gt9916";
+ reg = <0>;
+
+ interrupts-extended = <&tlmm 81 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&tlmm 105 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&vdd_ts>;
+ vddio-supply = <&iovdd_ts>;
+
+ spi-max-frequency = <1000000>;
+
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2400>;
+
+ pinctrl-0 = <&ts_int_n>, <&ts_reset_n>;
+ pinctrl-names = "default";
+ };
+};
+
+&tlmm {
+ gpio-line-names = "NC", /* GPIO_0 */
+ "NC",
+ "NC",
+ "NC",
+ "SMARTPA_I2C_SDA",
+ "SMARTPA_I2C_SCK",
+ "AUD_4480_DET",
+ "AUD_4480_INT",
+ "FASTCHARGE_I2C_SDA",
+ "FASTCHARGE_I2C_SCL",
+ "SM_GPSLNA_EN_GPIO10", /* GPIO_10 */
+ "NC",
+ "PERI_I2C_SDA",
+ "PERI_I2C_SCL",
+ "NC",
+ "NC",
+ "APPS_I2C_SDA",
+ "APPS_I2C_SCL",
+ "NC",
+ "DISP_LDO_EN",
+ "CAM_FW_RST_N", /* GPIO_20 */
+ "CAM_RM_RST_N",
+ "DBG_UART_TXD",
+ "DBG_UART_RXD",
+ "TOPSB_INT_N",
+ "MCAM_LDO_EN",
+ "HOST2WLAN_SOL",
+ "WLAN2HOST_SOL",
+ "UART_BT_RTS_AP_CTS",
+ "UART_BT_CTS_AP_RTS",
+ "UART_BT_RX_AP_TX", /* GPIO_30 */
+ "UART_BT_TX_AP_RX",
+ "FRONT_60M_INT",
+ "FRONT_60M_RST",
+ "FP_INT",
+ "FP_RST",
+ "NFC_I2C_SDA",
+ "NFC_I2C_SCL",
+ "NFC_EN",
+ "NFC_CLK_REQ",
+ "NFC_SE_SPI_NREST", /* GPIO_40 */
+ "NFC_IRQ",
+ "RF_LDO_GPIO42_EN",
+ "GOOGLE_KEY_INT", /* no such key exists */
+ "DISP_RST_N",
+ "SB_INT_N",
+ "HAP_RST_N",
+ "HAP_INT",
+ "ESE_SPI_MISO",
+ "ESE_SPI_MOSI",
+ "ESE_SPI_CLK", /* GPIO_50 */
+ "ESE_SPI_CS",
+ "TP_SPI_MISO",
+ "TP_SPI_MOSI",
+ "TP_SPI_CLK",
+ "TP_SPI_CS_N",
+ "FP_SPI_MISO",
+ "FP_SPI_MOSI",
+ "FP_SPI_CLK",
+ "FP_SPI_CS_N",
+ "HW_ID_1", /* GPIO_60 */
+ "HW_ID_2",
+ "CAM_PMU_EN",
+ "WIDE_DVDD_LDO_EN",
+ "CAM_MCLK0",
+ "CAM_MCLK1",
+ "CAM_MCLK2",
+ "CAM_MCLK3",
+ "NC",
+ "CCI_I2C_SDA0",
+ "CCI_I2C_SCL0", /* GPIO_70 */
+ "CCI_I2C_SDA1",
+ "CCI_I2C_SCL1",
+ "CCI_I2C_SDA2",
+ "CCI_I2C_SCL2",
+ "CCI_I2C_SDA3",
+ "CCI_I2C_SCL3",
+ "CAM_RT_RST_N",
+ "CAM_RU_RST_N",
+ "FCAM_LDO_EN",
+ "DISP_TE", /* GPIO_80 */
+ "TP_INT_N",
+ "FORCED_USB_BOOT",
+ "SM_CDC_RST_N",
+ "WLAN_EN",
+ "BT_EN",
+ "WCN_SW_CTRL",
+ "PCIE0_RESET_N",
+ "PCIE0_CLK_REQ_N",
+ "PCIE0_WAKE_N",
+ "MOS_AS_EN", /* GPIO_90 */
+ "NC",
+ "",
+ "NC",
+ "BT_FM_SLIMBUS_CLK",
+ "BT_FM_SLIMBUS_DATA",
+ "NC",
+ "RFCONN_DET_1",
+ "RF_CON_DET_2",
+ "RF_CON_DET_3",
+ "NC", /* GPIO_100 */
+ "NC",
+ "NC",
+ "ACCEL_INT",
+ "NC",
+ "TP_RST_N",
+ "NC",
+ "NC",
+ "NC",
+ "UIM2_DATA",
+ "UIM2_CLK", /* GPIO_110 */
+ "UIM2_RESET",
+ "UIM2_PRESENT",
+ "UIM1_DATA",
+ "UIM1_CLK",
+ "UIM1_RESET",
+ "UIM1_PRESENT",
+ "SM_RFFE0_CLK",
+ "SM_RFFE0_DATA",
+ "SM_RFFE1_CLK",
+ "SM_RFFE1_DATA", /* GPIO_120 */
+ "PA_MUTING",
+ "SM_GRFC5",
+ "LAA_RX",
+ "SM_GRFC7",
+ "SM_RFFE4_CLK",
+ "SM_RFFE4_DATA",
+ "WLAN_COEX_UART_RX",
+ "WLAN_COEX_UART_TX",
+ "NC",
+ "NC", /* GPIO_130 */
+ "SM_GRFC12",
+ "NC",
+ "QLINK0_REQUEST",
+ "QLINK0_ENABLE",
+ "QLINK0_WMSS_RESET_N",
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "USB_CC_DIR", /* GPIO_140 */
+ "SAR_INT_N",
+ "PROX_INT_N",
+ "",
+ "SM_SWR_TX_CLK",
+ "SM_SWR_TX_DATA0",
+ "SM_SWR_TX_DATA1",
+ "SM_SWR_RX_CLK",
+ "SM_SWR_RX_DATA0",
+ "SM_SWR_RX_DATA1",
+ "NC", /* GPIO_150 */
+ "NC",
+ "NC",
+ "NC",
+ "SB_MI2S_SCK",
+ "SB_MI2S_WS",
+ "SB_MI2S_RXDAT_AP_TX",
+ "SB_MI2S_TXDAT_AP_RX",
+ "NC",
+ "SNS_I3C0_SDA",
+ "SNS_I3C0_SCL", /* GPIO_160 */
+ "SSC_I2C4_SDA",
+ "SSC_I2C4_SCL",
+ "MAG_I2C_SDA",
+ "MAG_I2C_SCL",
+ "NC",
+ "NC",
+ "",
+ "",
+ "",
+ "", /* GPIO_170 */
+ "SSC_BT_UART4_TX",
+ "SSC_BT_UART4_RX",
+ "NC",
+ "NC";
+ gpio-reserved-ranges = <48 4>, /* SPI (eSE - embedded Secure Element) */
+ <56 4>; /* SPI (fingerprint reader) */
+
+ qup_uart7_sleep_cts: qup-uart7-sleep-cts-state {
+ pins = "gpio28";
+ function = "gpio";
+ /*
+ * Configure a bias-bus-hold on CTS to lower power
+ * usage when Bluetooth is turned off. Bus hold will
+ * maintain a low power state regardless of whether
+ * the Bluetooth module drives the pin in either
+ * direction or leaves the pin fully unpowered.
+ */
+ bias-bus-hold;
+ };
+
+ qup_uart7_sleep_rts: qup-uart7-sleep-rts-state {
+ pins = "gpio29";
+ function = "gpio";
+ /*
+ * Configure pull-down on RTS. As RTS is active low
+ * signal, pull it low to indicate the BT SoC that it
+ * can wakeup the system anytime from suspend state by
+ * pulling RX low (by sending wakeup bytes).
+ */
+ bias-pull-down;
+ };
+
+ qup_uart7_sleep_tx: qup-uart7-sleep-tx-state {
+ pins = "gpio30";
+ function = "gpio";
+ /*
+ * Configure pull-up on TX when it isn't actively driven
+ * to prevent BT SoC from receiving garbage during sleep.
+ */
+ bias-pull-up;
+ };
+
+ qup_uart7_sleep_rx: qup-uart7-sleep-rx-state {
+ pins = "gpio31";
+ function = "gpio";
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module
+ * is floating which may cause spurious wakeups.
+ */
+ bias-pull-up;
+ };
+
+ oled_reset_n: oled-reset-n-state {
+ pins = "gpio44";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ aw86224_reset_default: aw86224-reset-default-state {
+ pins = "gpio46";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ aw86224_int_default: aw86224-int-default-state {
+ pins = "gpio47";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ mdp_vsync_p: mdp-vsync-p-state {
+ pins = "gpio80";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ ts_int_n: ts-int-n-state {
+ pins = "gpio81";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ bt_en: bt-en-state {
+ pins = "gpio85";
+ function = "gpio";
+ output-low;
+ bias-disable;
+ };
+
+ ts_reset_n: ts-int-n-state {
+ pins = "gpio105";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&uart7 {
+ /delete-property/ interrupts;
+ interrupts-extended = <&intc GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>,
+ <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-1 = <&qup_uart7_sleep_cts>,
+ <&qup_uart7_sleep_rts>,
+ <&qup_uart7_sleep_tx>,
+ <&qup_uart7_sleep_rx>;
+ pinctrl-names = "default",
+ "sleep";
+
+ status = "okay";
+
+ bluetooth: bluetooth {
+ compatible = "qcom,wcn6750-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+
+ max-speed = <3200000>;
+
+ qcom,local-bd-address-broken;
+ };
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l7b_2p96>;
+ vcc-max-microamp = <800000>;
+
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <900000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vdd_a_ufs_0_core>;
+ vdda-pll-supply = <&vdd_a_ufs_0_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ /* USB 2.0 only */
+ qcom,select-utmi-as-pipe-clk;
+ maximum-speed = "high-speed";
+
+ /* Remove USB3 phy */
+ phys = <&usb_1_hsphy>;
+ phy-names = "usb2-phy";
+
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vdd_a_usbhs_core>;
+ vdda18-supply = <&vdd_a_usbhs_1p8>;
+ vdda33-supply = <&vdd_a_usbhs_3p1>;
+
+ status = "okay";
+};
+
+&venus {
+ firmware-name = "qcom/sm7325/motorola/dubai/vpu20_1v.mbn";
+
+ status = "okay";
+};
+
+&wifi {
+ qcom,calibration-variant = "Motorola_dubai";
+
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-29 10:44 UTC (permalink / raw)
To: Richard Acayan
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
In-Reply-To: <20260328014041.83777-4-mailingradian@gmail.com>
On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> the first 6 CPUs are in the little cluster and the next 2 are in the big
> cluster. Define the clusters in the match data and define the different
> cluster configuration for SDM670.
>
> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> the cluster.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 13 deletions(-)
>
> +static const struct lmh_soc_data sdm670_lmh_data = {
> + .enable_algos = true,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
> +
> +static const struct lmh_soc_data sdm845_lmh_data = {
> + .enable_algos = true,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
These tables made me wonder, can we determine this information from the
DT? For example, by reading the qcom,freq-domain property. But...
> +
> +static const struct lmh_soc_data sm8150_lmh_data = {
> + .enable_algos = false,
> + .node_ids = {
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER0_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + LMH_CLUSTER1_NODE_ID,
> + },
> +};
... this might be problematic, unless this entry is broken. On SM8150 we
have three freq domains, but up to now we were programming two clustern
nodes. Of course it is possible to define that node_id is 0 for freq
domain 0 and 1 for domains 1 and 2.
> +
> static const struct of_device_id lmh_table[] = {
> - { .compatible = "qcom,sc8180x-lmh", },
> - { .compatible = "qcom,sdm845-lmh", .data = (void *)LMH_ENABLE_ALGOS},
> - { .compatible = "qcom,sm8150-lmh", },
> + { .compatible = "qcom,sc8180x-lmh", .data = &sm8150_lmh_data },
> + { .compatible = "qcom,sdm670-lmh", .data = &sdm670_lmh_data },
> + { .compatible = "qcom,sdm845-lmh", .data = &sdm845_lmh_data },
> + { .compatible = "qcom,sm8150-lmh", .data = &sm8150_lmh_data },
> {}
> };
> MODULE_DEVICE_TABLE(of, lmh_table);
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC v2 08/17] RISC-V: QoS: add resctrl interface for CBQRI controllers
From: guo.wenjia23 @ 2026-03-29 10:27 UTC (permalink / raw)
To: fustini
Cc: pjw, palmer, aou, alex, rkrcmar, samuel.holland, aricciardi,
npitre, mindal, atish.patra, atishp, vasu, ved, cuiyunhui, cp0613,
zhiwei_liu, liwei1518, liu.qingtao2, reinette.chatre, tony.luck,
babu.moger, peternewman, fenghua.yu, james.morse, ben.horgan,
Dave.Martin, fustini, linux-kernel, linux-riscv, x86, robh,
rafael, lenb, robert.moore, sunilvl, krzk+dt, conor+dt,
paul.walmsley, linux-acpi, acpica-devel, devicetree
In-Reply-To: <20260128-ssqosid-cbqri-v2-8-dca586b091b9@kernel.org>
Hi Drew,
On Thu, Jan 29, 2026 at 4:28 AM Drew Fustini <fustini@kernel.org> wrote:>
> Add interface for CBQRI controller drivers to make use of the resctrl
> filesystem.
>
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
> ---
> arch/riscv/kernel/qos/qos_resctrl.c | 1192 +++++++++++++++++++++++++++++++++++
> 1 file changed, 1192 insertions(+)
>
> ...
>
> +
> +int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> + u32 closid, enum resctrl_conf_type t, u32 cfg_val)
> +{
> + struct cbqri_controller *ctrl;
> + struct cbqri_resctrl_dom *dom;
> + struct cbqri_config cfg;
> + int err = 0;
> +
> + dom = container_of(d, struct cbqri_resctrl_dom, resctrl_ctrl_dom);
> + ctrl = dom->hw_ctrl;
> +
> + if (!r->alloc_capable)
> + return -EINVAL;
> +
> + switch (r->rid) {
> + case RDT_RESOURCE_L2:
> + case RDT_RESOURCE_L3:
> + cfg.cbm = cfg_val;
> + err = cbqri_apply_cache_config(dom, closid, t, &cfg);
> + break;
> + case RDT_RESOURCE_MBA:
> + /* covert from percentage to bandwidth blocks */
> + cfg.rbwb = cfg_val * ctrl->bc.nbwblks / 100;
Should use bc.mrbwb to calculate rbwb?
I think bc.nbwblks represent the available bw blks in the controller. It should should decrease as they are allocated.
> + err = cbqri_apply_bw_config(dom, closid, t, &cfg);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return err;
> +}
>
> ...
>
> +u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> + u32 closid, enum resctrl_conf_type type)
> +{
> + struct cbqri_resctrl_dom *hw_dom;
> + struct cbqri_controller *ctrl;
> + int reg_offset;
> + u32 percent;
> + u32 rbwb;
> + u64 reg;
> + int err;
> +
> + hw_dom = container_of(d, struct cbqri_resctrl_dom, resctrl_ctrl_dom);
> +
> + ctrl = hw_dom->hw_ctrl;
> +
> + if (!r->alloc_capable)
> + return resctrl_get_default_ctrl(r);
> +
> + switch (r->rid) {
> + case RDT_RESOURCE_L2:
> + case RDT_RESOURCE_L3:
> + /* Clear cc_block_mask before read limit operation */
> + cbqri_set_cbm(ctrl, 0);
> +
> + /* Capacity read limit operation for RCID (closid) */
> + err = cbqri_cc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT, type, closid);
> + if (err < 0) {
> + pr_err("%s(): operation failed: err = %d", __func__, err);
> + return resctrl_get_default_ctrl(r);
> + }
> +
> + /* Read capacity block mask for RCID (closid) */
> + reg_offset = CBQRI_CC_BLOCK_MASK_OFF;
> + reg = ioread64(ctrl->base + reg_offset);
> +
> + /* Update the config value for the closid in this domain */
> + hw_dom->ctrl_val[closid] = reg;
> + return hw_dom->ctrl_val[closid];
> +
> + case RDT_RESOURCE_MBA:
> + /* Capacity read limit operation for RCID (closid) */
> + err = cbqri_bc_alloc_op(ctrl, CBQRI_CC_ALLOC_CTL_OP_READ_LIMIT, closid);
> + if (err < 0) {
> + pr_err("%s(): operation failed: err = %d", __func__, err);
> + return resctrl_get_default_ctrl(r);
> + }
> +
> + hw_dom->ctrl_val[closid] = cbqri_get_rbwb(ctrl);
> +
> + /* Convert from bandwidth blocks to percent */
> + rbwb = hw_dom->ctrl_val[closid];
> + rbwb *= 100;
> + percent = rbwb / ctrl->bc.nbwblks;
> + if (rbwb % ctrl->bc.nbwblks)
Same Question.
> + percent++;
> + return percent;
> +
> + default:
> + return resctrl_get_default_ctrl(r);
> + }
> +}
Sorry for my previous reply on old patch. Please ignore it. I’m re-sending this comment on v2.
Thank,
Wenjia
郭文佳10158971
^ permalink raw reply
* Re: [PATCH v3 0/3] thermal: spacemit: Add support for SpacemiT K1 SoC thermal sensor
From: Gong Shuai @ 2026-03-29 10:45 UTC (permalink / raw)
To: shuweiwoo
Cc: alex, aou, conor+dt, daniel.lezcano, devicetree, dlan, krzk+dt,
krzysztof.kozlowski, linux-kernel, linux-pm, linux-riscv,
lukasz.luba, p.zabel, palmer, pjw, rafael, robh, rui.zhang,
spacemit, gsh517025
In-Reply-To: <20260119-patchv2-k1-thermal-v3-0-3d82c9ebe8a4@163.com>
Hi Shuwei,
> Introduce support for the on-die thermal sensor found
> on the SpacemiT K1 SoC.
>
> Include the device tree binding documentation in YAML format, the
> thermal sensor driver implementation, and the device tree changes to
> enable the sensor on K1 SoC.
>
> ---
> Changes in v3:
> - Fix indentation and variable types
> - Simplify clock management and redundant assignments
> - Link to v2: https://lore.kernel.org/r/20251216-patchv2-k1-thermal-v1-0-d4b31fe9c904@163.com
>
> Changes in v2:
> - Move driver to drivers/thermal/spacemit/ and update Kconfig/Makefile
> - Address reviewer feedback on style and structure
> - Improve variable naming and comments
> - Link to v1: https://lore.kernel.org/r/20251127-b4-k1-thermal-v1-0-f32ce47b1aba@163.com
>
> ---
> Shuwei Wu (3):
> dt-bindings: thermal: Add SpacemiT K1 thermal sensor
> thermal: spacemit: k1: Add thermal sensor support
> riscv: dts: spacemit: Add thermal sensor for K1 SoC
>
> .../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 101 ++++++++
> drivers/thermal/Kconfig | 2 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/spacemit/Kconfig | 19 ++
> drivers/thermal/spacemit/Makefile | 3 +
> drivers/thermal/spacemit/k1_tsensor.c | 281 +++++++++++++++++++++
> 7 files changed, 483 insertions(+)
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251215-patchv2-k1-thermal-5ffb838fc1cc
>
> Best regards,
> --
> Shuwei Wu <shuweiwoo@163.com>
This patch series works well on OrangePi-RV2 with mainline kernel 7.0.0-rc5
$ cat /sys/class/thermal/thermal_zone*/type
soc-thermal
package-thermal
gpu-thermal
cluster0-thermal
cluster1-thermal
$ cat /sys/class/thermal/thermal_zone*/temp
35000
37000
36000
36000
37000
$ sensors
cluster1_thermal-virtual-0
Adapter: Virtual device
temp1: +38.0 C
gpu_thermal-virtual-0
Adapter: Virtual device
temp1: +36.0 C
soc_thermal-virtual-0
Adapter: Virtual device
temp1: +36.0 C
cluster0_thermal-virtual-0
Adapter: Virtual device
temp1: +37.0 C
package_thermal-virtual-0
Adapter: Virtual device
temp1: +37.0 C
Tested-by: Gong Shuai <gsh517025@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Dmitry Baryshkov @ 2026-03-29 10:54 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <0322e0b3-bce8-4415-90b2-d14445986e23@kernel.org>
On Fri, Mar 27, 2026 at 11:40:51PM +0000, Bryan O'Donoghue wrote:
> On 27/03/2026 23:23, Dmitry Baryshkov wrote:
> > On Sat, Mar 28, 2026 at 01:12:22AM +0200, Vladimir Zapolskiy wrote:
> > > On 3/28/26 00:29, Bryan O'Donoghue wrote:
> > > > On 27/03/2026 20:51, Dmitry Baryshkov wrote:
> > > > > > That's just not true. If you read the camx source code you can see
> > > > > > split/combo mode 2+1 1+1 data/clock mode requires special programming of the
> > > > > > PHY to support.
> > > > > This needs to be identified from the data-lanes / clock-lanes topology.
> > > > > And once you do that, there would be (probably) no difference in the
> > > > > hardware definition.
> > > > >
> > > > >
> > > > > In other words, I'd also ask to drop this mode from the DT. This
> > > > > infromation can and should be deduced from other, already-defined
> > > > > properties.
> > > >
> > > > It still needs to be communicated to the PHY from the controller,
> > > > however that is not a problem I am trying to solve now.
> > > >
> > > > If I can't get consensus for PHY_QCOM_CSI2_MODE_SPLIT_DPHY then so be it.
> > > >
> > > > I'll aim for DPHY only and we can come back to this topic when someone
> > > > actually tries to enable it.
> > > >
> > >
> > > DPHY may be the only supported phy type in the driver, it does not matter
> > > at this point, however it's totally essential to cover the called by you
> > > 'split mode' right from the beginning in the renewed device tree binding
> > > descriptions of CAMSS IPs to progress further.
> >
> > Okay. How would we describe that there are two sensors connected to the
> > single PHY anyway? How would it be described with the current bindings?
> >
> > --
> > With best wishes
> > Dmitry
>
> Assuming you add endpoints to the PHY i.e. that is what Neil appears to be
> asking for and I personally am _fine_ with that, then it should just be
>
> port@0
> port@1
>
> if port@1 exists, you know you are in split-phy mode.
>
> Its actually straight forward enough, really. To be clear though I can write
> that yaml - the _most_ support I'm willing to put into the PHY code is to
> detect the port@1 and say "nope not supported yet", since like CPHY its not.
SGTM. But let's define the schema for those usecases.
>
> ---
> bod
--
With best wishes
Dmitry
^ 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