[PATCH 1/7] arm64: dts: qcom: pm660: Use unique ADC5_VCOIN address in node name

[PATCH 1/7] arm64: dts: qcom: pm660: Use unique ADC5_VCOIN address in node name

[Marijn Suijten]

The register address in the node name is shadowing vph_pwr@83, whereas
the ADC5_VCOIN register resolves to 0x85.  Fix this copy-paste
discrepancy.

Fixes: 4bf097540506 ("arm64: dts: qcom: pm660: Add VADC and temp alarm nodes")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 arch/arm64/boot/dts/qcom/pm660.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
index c482663aad56..42f9c51b9c1e 100644
--- a/arch/arm64/boot/dts/qcom/pm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
@@ -163,7 +163,7 @@ vadc_vph_pwr: vph_pwr@83 {
 				qcom,pre-scaling = <1 3>;
 			};

-			vcoin: vcoin@83 {
+			vcoin: vcoin@85 {
 				reg = <ADC5_VCOIN>;
 				qcom,decimation = <1024>;
 				qcom,pre-scaling = <1 3>;
--
2.36.1

[PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Marijn Suijten]

The pm6125 comes with 9 GPIOs, without holes.

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 22dbcba752d0..ef7a4a9450a4 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -20,6 +20,7 @@ properties:
           - qcom,pm2250-gpio
           - qcom,pm660-gpio
           - qcom,pm660l-gpio
+          - qcom,pm6125-gpio
           - qcom,pm6150-gpio
           - qcom,pm6150l-gpio
           - qcom,pm6350-gpio
@@ -107,6 +108,7 @@ $defs:
         description:
           List of gpio pins affected by the properties specified in
           this subnode.  Valid pins are
+                 - gpio1-gpio9 for pm6125
                  - gpio1-gpio10 for pm6150
                  - gpio1-gpio12 for pm6150l
                  - gpio1-gpio9 for pm6350
-- 
2.36.1

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Krzysztof Kozlowski]

On 12/05/2022 00:06, Marijn Suijten wrote:
> The pm6125 comes with 9 GPIOs, without holes.
> 
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

It's the first version, how did the tag appear here?

> ---
>  Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++
>  1 file changed, 2 insertions(+)


This will need fixups or rebasing on my sets of PMIC gpio schema cleanup:

https://lore.kernel.org/all/20220507194913.261121-1-krzysztof.kozlowski@linaro.org/
https://lore.kernel.org/all/20220508135932.132378-2-krzysztof.kozlowski@linaro.org/

Bjorn,
let us know preferred order (who should rebase on who).

Best regards,
Krzysztof

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Marijn Suijten]

On 2022-05-13 10:19:56, Krzysztof Kozlowski wrote:
> On 12/05/2022 00:06, Marijn Suijten wrote:
> > The pm6125 comes with 9 GPIOs, without holes.
> > 
> > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> 
> It's the first version, how did the tag appear here?

We are friends and review each-others patches offline before spamming
the mailing list with them, to save readers and maintainers here from
pointing out glaring mistakes.  I hope this is standard practice in
companies too, or do you recommend aganst us doing this?

> > ---
> >  Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> 
> This will need fixups or rebasing on my sets of PMIC gpio schema cleanup:

Ack.

> https://lore.kernel.org/all/20220507194913.261121-1-krzysztof.kozlowski@linaro.org/
> https://lore.kernel.org/all/20220508135932.132378-2-krzysztof.kozlowski@linaro.org/
> 
> Bjorn,
> let us know preferred order (who should rebase on who).

I prefer yours to be applied first, so that I can retest this
patchseries with stricter / more correct dt-bindings introduced by it.
My series can also be resent with the notice that it has already been
rebased on top of your series, after collecting more reviews.  Where
necessary, I can review your series too if that helps getting it in
sooner.

- Marijn

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Krzysztof Kozlowski]

On 13/05/2022 11:17, Marijn Suijten wrote:
> On 2022-05-13 10:19:56, Krzysztof Kozlowski wrote:
>> On 12/05/2022 00:06, Marijn Suijten wrote:
>>> The pm6125 comes with 9 GPIOs, without holes.
>>>
>>> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
>>
>> It's the first version, how did the tag appear here?
> 
> We are friends and review each-others patches offline before spamming
> the mailing list with them, to save readers and maintainers here from
> pointing out glaring mistakes.  I hope this is standard practice in
> companies too, or do you recommend aganst us doing this?

I personally recommend against it because I prefer public discussions.
Especially that such practice in some companies mean that tag is added
automatically, without actual review. There are some folks, from other
subsystems and architectures, which never publicly replied to anything
(so we don't know if they actually exist, what's their credibility,
knowledge, experience etc) but they appear on hundreds of reviews.

Other people don't mind this practice.

Anyway, it's not a stopper from anything, I was wondering.

> 
>>> ---
>>>  Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>
>>
>> This will need fixups or rebasing on my sets of PMIC gpio schema cleanup:
> 
> Ack.
> 
>> https://lore.kernel.org/all/20220507194913.261121-1-krzysztof.kozlowski@linaro.org/
>> https://lore.kernel.org/all/20220508135932.132378-2-krzysztof.kozlowski@linaro.org/
>>
>> Bjorn,
>> let us know preferred order (who should rebase on who).
> 
> I prefer yours to be applied first, so that I can retest this
> patchseries with stricter / more correct dt-bindings introduced by it.
> My series can also be resent with the notice that it has already been
> rebased on top of your series, after collecting more reviews.  Where
> necessary, I can review your series too if that helps getting it in
> sooner.

Sounds good. It's in Bjorn's hands now. :)


Best regards,
Krzysztof

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Linus Walleij]

On Fri, May 13, 2022 at 11:37 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:

> >> This will need fixups or rebasing on my sets of PMIC gpio schema cleanup:
> >
> > Ack.
> >
> >> https://lore.kernel.org/all/20220507194913.261121-1-krzysztof.kozlowski@linaro.org/
> >> https://lore.kernel.org/all/20220508135932.132378-2-krzysztof.kozlowski@linaro.org/
> >>
> >> Bjorn,
> >> let us know preferred order (who should rebase on who).
> >
> > I prefer yours to be applied first, so that I can retest this
> > patchseries with stricter / more correct dt-bindings introduced by it.
> > My series can also be resent with the notice that it has already been
> > rebased on top of your series, after collecting more reviews.  Where
> > necessary, I can review your series too if that helps getting it in
> > sooner.
>
> Sounds good. It's in Bjorn's hands now. :)

Ugh can I get that with a pull request? Maybe Krzysztof can provide?

BTW I have high confidence in you Krzysztof after all your work on the
Samsung pin controllers, can you and Bjorn
discuss maybe adding you as comaintainer for Qualcomm pin controllers,
it's not like Bjorn has too little to do.

Yours,
Linus Walleij

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Krzysztof Kozlowski]

On 13/05/2022 23:09, Linus Walleij wrote:
>>> I prefer yours to be applied first, so that I can retest this
>>> patchseries with stricter / more correct dt-bindings introduced by it.
>>> My series can also be resent with the notice that it has already been
>>> rebased on top of your series, after collecting more reviews.  Where
>>> necessary, I can review your series too if that helps getting it in
>>> sooner.
>>
>> Sounds good. It's in Bjorn's hands now. :)
> 
> Ugh can I get that with a pull request? Maybe Krzysztof can provide?

Ah, I completely forgot that this is actually pinctrl, so it's not Bjorn
but you. :) Of course then it can go via Pinctrl tree, in any order you
prefer and anyway it's not my call. :)

> 
> BTW I have high confidence in you Krzysztof after all your work on the
> Samsung pin controllers, can you and Bjorn
> discuss maybe adding you as comaintainer for Qualcomm pin controllers,
> it's not like Bjorn has too little to do.

Sure, I am happy to help here. I'll talk with Bjorn.

Best regards,
Krzysztof

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Bjorn Andersson]

On Wed 11 May 15:06 PDT 2022, Marijn Suijten wrote:

> The pm6125 comes with 9 GPIOs, without holes.
> 
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> index 22dbcba752d0..ef7a4a9450a4 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> @@ -20,6 +20,7 @@ properties:
>            - qcom,pm2250-gpio
>            - qcom,pm660-gpio
>            - qcom,pm660l-gpio
> +          - qcom,pm6125-gpio
>            - qcom,pm6150-gpio
>            - qcom,pm6150l-gpio
>            - qcom,pm6350-gpio
> @@ -107,6 +108,7 @@ $defs:
>          description:
>            List of gpio pins affected by the properties specified in
>            this subnode.  Valid pins are
> +                 - gpio1-gpio9 for pm6125
>                   - gpio1-gpio10 for pm6150
>                   - gpio1-gpio12 for pm6150l
>                   - gpio1-gpio9 for pm6350
> -- 
> 2.36.1
> 

Re: [PATCH 2/7] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm6125 compatible

[Linus Walleij]

On Thu, May 12, 2022 at 12:06 AM Marijn Suijten
<marijn.suijten@somainline.org> wrote:

> The pm6125 comes with 9 GPIOs, without holes.
>
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

This patch 2/7 applied to the pinctrl tree.

Yours,
Linus Walleij

[PATCH 3/7] pinctrl: qcom: spmi-gpio: Add pm6125 compatible

[Marijn Suijten]

The pm6125 has 9 GPIOs with no holes inbetween.

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index a0c45b305981..fd5fff9adff0 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -1146,6 +1146,7 @@ static const struct of_device_id pmic_gpio_of_match[] = {
 	{ .compatible = "qcom,pm660-gpio", .data = (void *) 13 },
 	/* pm660l has 12 GPIOs with holes on 1, 2, 10, 11 and 12 */
 	{ .compatible = "qcom,pm660l-gpio", .data = (void *) 12 },
+	{ .compatible = "qcom,pm6125-gpio", .data = (void *) 9 },
 	{ .compatible = "qcom,pm6150-gpio", .data = (void *) 10 },
 	{ .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
 	{ .compatible = "qcom,pm6350-gpio", .data = (void *) 9 },
-- 
2.36.1

Re: [PATCH 3/7] pinctrl: qcom: spmi-gpio: Add pm6125 compatible

[Bjorn Andersson]

On Wed 11 May 15:06 PDT 2022, Marijn Suijten wrote:

> The pm6125 has 9 GPIOs with no holes inbetween.
> 
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

> ---
>  drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index a0c45b305981..fd5fff9adff0 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1146,6 +1146,7 @@ static const struct of_device_id pmic_gpio_of_match[] = {
>  	{ .compatible = "qcom,pm660-gpio", .data = (void *) 13 },
>  	/* pm660l has 12 GPIOs with holes on 1, 2, 10, 11 and 12 */
>  	{ .compatible = "qcom,pm660l-gpio", .data = (void *) 12 },
> +	{ .compatible = "qcom,pm6125-gpio", .data = (void *) 9 },
>  	{ .compatible = "qcom,pm6150-gpio", .data = (void *) 10 },
>  	{ .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
>  	{ .compatible = "qcom,pm6350-gpio", .data = (void *) 9 },
> -- 
> 2.36.1
> 

Re: [PATCH 3/7] pinctrl: qcom: spmi-gpio: Add pm6125 compatible

[Linus Walleij]

On Thu, May 12, 2022 at 12:06 AM Marijn Suijten
<marijn.suijten@somainline.org> wrote:

> The pm6125 has 9 GPIOs with no holes inbetween.
>
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

This patch 3/7 applied to the pinctrl tree.

Yours,
Linus Walleij

[PATCH 4/7] iio: adc: qcom-spmi-adc5: Add missing VCOIN/AMUX_THM3/GPIO# channels

[Marijn Suijten]

These channels are specified in downstream kernels [1] and actively used
by ie. the Sony Seine platform on the SM6125 SoC.

[1]: https://source.codeaurora.org/quic/la/kernel/msm-4.14/tree/drivers/iio/adc/qcom-spmi-adc5.c?h=LA.UM.7.11.r1-05200-NICOBAR.0#n688

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 drivers/iio/adc/qcom-spmi-adc5.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index 87438d1e5c0b..69c7fd44d34c 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -526,6 +526,8 @@ static const struct adc5_channels adc5_chans_pmic[ADC5_MAX_CHANNEL] = {
 					SCALE_HW_CALIB_DEFAULT)
 	[ADC5_VBAT_SNS]		= ADC5_CHAN_VOLT("vbat_sns", 1,
 					SCALE_HW_CALIB_DEFAULT)
+	[ADC5_VCOIN]		= ADC5_CHAN_VOLT("vcoin", 1,
+					SCALE_HW_CALIB_DEFAULT)
 	[ADC5_DIE_TEMP]		= ADC5_CHAN_TEMP("die_temp", 0,
 					SCALE_HW_CALIB_PMIC_THERM)
 	[ADC5_USB_IN_I]		= ADC5_CHAN_VOLT("usb_in_i_uv", 0,
@@ -549,6 +551,16 @@ static const struct adc5_channels adc5_chans_pmic[ADC5_MAX_CHANNEL] = {
 					SCALE_HW_CALIB_THERM_100K_PULLUP)
 	[ADC5_AMUX_THM2]	= ADC5_CHAN_TEMP("amux_thm2", 0,
 					SCALE_HW_CALIB_PM5_SMB_TEMP)
+	[ADC5_AMUX_THM3]	= ADC5_CHAN_TEMP("amux_thm3", 0,
+					SCALE_HW_CALIB_PM5_SMB_TEMP)
+	[ADC5_GPIO1_100K_PU]	= ADC5_CHAN_TEMP("gpio1_100k_pu", 0,
+					SCALE_HW_CALIB_THERM_100K_PULLUP)
+	[ADC5_GPIO2_100K_PU]	= ADC5_CHAN_TEMP("gpio2_100k_pu", 0,
+					SCALE_HW_CALIB_THERM_100K_PULLUP)
+	[ADC5_GPIO3_100K_PU]	= ADC5_CHAN_TEMP("gpio3_100k_pu", 0,
+					SCALE_HW_CALIB_THERM_100K_PULLUP)
+	[ADC5_GPIO4_100K_PU]	= ADC5_CHAN_TEMP("gpio4_100k_pu", 0,
+					SCALE_HW_CALIB_THERM_100K_PULLUP)
 };
 
 static const struct adc5_channels adc7_chans_pmic[ADC5_MAX_CHANNEL] = {
-- 
2.36.1

Re: [PATCH 4/7] iio: adc: qcom-spmi-adc5: Add missing VCOIN/AMUX_THM3/GPIO# channels

[Jonathan Cameron]

On Thu, 12 May 2022 00:06:10 +0200
Marijn Suijten <marijn.suijten@somainline.org> wrote:

> These channels are specified in downstream kernels [1] and actively used
> by ie. the Sony Seine platform on the SM6125 SoC.

Looking at the links, some of them are on that platform but not all.
Better to make that explicit in this description.

> 
> [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.14/tree/drivers/iio/adc/qcom-spmi-adc5.c?h=LA.UM.7.11.r1-05200-NICOBAR.0#n688
> 
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>

I'm not keen on patches with no context being
sent to mailing lists. Please cc all lists (and preferably individuals)
on at least the cover letter so we can see overall discussion.

If nothing else, I've no idea if intent is that the patches go through different
trees or all need to merge via one route.

Patch itself looks fine,

Jonathan


> ---
>  drivers/iio/adc/qcom-spmi-adc5.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
> index 87438d1e5c0b..69c7fd44d34c 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -526,6 +526,8 @@ static const struct adc5_channels adc5_chans_pmic[ADC5_MAX_CHANNEL] = {
>  					SCALE_HW_CALIB_DEFAULT)
>  	[ADC5_VBAT_SNS]		= ADC5_CHAN_VOLT("vbat_sns", 1,
>  					SCALE_HW_CALIB_DEFAULT)
> +	[ADC5_VCOIN]		= ADC5_CHAN_VOLT("vcoin", 1,
> +					SCALE_HW_CALIB_DEFAULT)
>  	[ADC5_DIE_TEMP]		= ADC5_CHAN_TEMP("die_temp", 0,
>  					SCALE_HW_CALIB_PMIC_THERM)
>  	[ADC5_USB_IN_I]		= ADC5_CHAN_VOLT("usb_in_i_uv", 0,
> @@ -549,6 +551,16 @@ static const struct adc5_channels adc5_chans_pmic[ADC5_MAX_CHANNEL] = {
>  					SCALE_HW_CALIB_THERM_100K_PULLUP)
>  	[ADC5_AMUX_THM2]	= ADC5_CHAN_TEMP("amux_thm2", 0,
>  					SCALE_HW_CALIB_PM5_SMB_TEMP)
> +	[ADC5_AMUX_THM3]	= ADC5_CHAN_TEMP("amux_thm3", 0,
> +					SCALE_HW_CALIB_PM5_SMB_TEMP)
> +	[ADC5_GPIO1_100K_PU]	= ADC5_CHAN_TEMP("gpio1_100k_pu", 0,
> +					SCALE_HW_CALIB_THERM_100K_PULLUP)
> +	[ADC5_GPIO2_100K_PU]	= ADC5_CHAN_TEMP("gpio2_100k_pu", 0,
> +					SCALE_HW_CALIB_THERM_100K_PULLUP)
> +	[ADC5_GPIO3_100K_PU]	= ADC5_CHAN_TEMP("gpio3_100k_pu", 0,
> +					SCALE_HW_CALIB_THERM_100K_PULLUP)
> +	[ADC5_GPIO4_100K_PU]	= ADC5_CHAN_TEMP("gpio4_100k_pu", 0,
> +					SCALE_HW_CALIB_THERM_100K_PULLUP)
>  };
>  
>  static const struct adc5_channels adc7_chans_pmic[ADC5_MAX_CHANNEL] = {

Re: [PATCH 4/7] iio: adc: qcom-spmi-adc5: Add missing VCOIN/AMUX_THM3/GPIO# channels

[Marijn Suijten]

On 2022-05-14 17:13:12, Jonathan Cameron wrote:
> On Thu, 12 May 2022 00:06:10 +0200
> Marijn Suijten <marijn.suijten@somainline.org> wrote:
> 
> > These channels are specified in downstream kernels [1] and actively used
> > by ie. the Sony Seine platform on the SM6125 SoC.
> 
> Looking at the links, some of them are on that platform but not all.
> Better to make that explicit in this description.

This has already been queued up for v2.  Adding these seemed easy at the
time but they are in fact not used, and I ended up sending the wrong
patch.

Just so that we're on the same page: only ADC5_AMUX_THM3 and
ADC5_GPIO2_100K_PU are unused by my platform.  It seems the first should
be dropped, but the latter can probably stay in the patch with an
explicit mention.  If you think both should stay, there are a bunch more
channels defined in the downstream kernel as per [1] and I'm not sure if
all should be added for completeness.

> > 
> > [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.14/tree/drivers/iio/adc/qcom-spmi-adc5.c?h=LA.UM.7.11.r1-05200-NICOBAR.0#n688
> > 
> > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> 
> I'm not keen on patches with no context being
> sent to mailing lists. Please cc all lists (and preferably individuals)
> on at least the cover letter so we can see overall discussion.

That can be attributed to the terrible workflow for sending
patch-series.  Somehow only `git send-email` supports --cc-cmd yet I'd
expect it on `git format-patch` for auditing and possibly copying to the
cover letter, if `git format-patch --cover-letter` couldn't do this from
the beginning.
At the same time `git send-email` has --[to/cc]-cover options to
propagate email addresses from the cover letter to all the individual
patch-replies, but not the inverse :(

In the end this leaves me manually running get_maintainer.pl over the
entire formatted patch-series, and manually copy-pasting + editing the
addresses into the cover letter... Which is easy to forget and is no
different here.

My apologies for (yet again) accidentally not sending at least the cover
letter to everyone.  That's a gross oversight, and I'm probably - no, I
must - be doing something wrong.  Suggestions and/or documentation
references are welcome.

> If nothing else, I've no idea if intent is that the patches go through different
> trees or all need to merge via one route.

I have no idea either, and have not yet had an answer to a similar
question on a different list.  Usually it seems the maintainers work out
amongst themselves who picks what patch, putting them on hold where
necessary to preseve ordering.  If not, should the sender split patches
across multiple series, either holding off sending part of it or linking
to a dependent series?

In this particular case DT has to wait for these driver patches to land,
otherwise they may define channels that do not exist and unnecessarily
fail probe.

> Patch itself looks fine,

Thanks.

Looking forward to your suggestions and answers,

- Marijn

> [..]

Re: [PATCH 4/7] iio: adc: qcom-spmi-adc5: Add missing VCOIN/AMUX_THM3/GPIO# channels

[Jonathan Cameron]

On Sun, 15 May 2022 17:30:04 +0200
Marijn Suijten <marijn.suijten@somainline.org> wrote:

> On 2022-05-14 17:13:12, Jonathan Cameron wrote:
> > On Thu, 12 May 2022 00:06:10 +0200
> > Marijn Suijten <marijn.suijten@somainline.org> wrote:
> >   
> > > These channels are specified in downstream kernels [1] and actively used
> > > by ie. the Sony Seine platform on the SM6125 SoC.  
> > 
> > Looking at the links, some of them are on that platform but not all.
> > Better to make that explicit in this description.  
> 
> This has already been queued up for v2.  Adding these seemed easy at the
> time but they are in fact not used, and I ended up sending the wrong
> patch.
> 
> Just so that we're on the same page: only ADC5_AMUX_THM3 and
> ADC5_GPIO2_100K_PU are unused by my platform.  It seems the first should
> be dropped, but the latter can probably stay in the patch with an
> explicit mention.  If you think both should stay, there are a bunch more
> channels defined in the downstream kernel as per [1] and I'm not sure if
> all should be added for completeness.

Probably better to add them with a comment for platforms on which they
apply (either in commit log or alongside the definitions in the code).

Longer term we should think about whether the code can be adjusted
to not need an explicit definition for these multi purpose channels
though letting the dt itself describe them (under constraints of the
hardware platform).  Not worth doing before this patch though.

> 
> > > 
> > > [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.14/tree/drivers/iio/adc/qcom-spmi-adc5.c?h=LA.UM.7.11.r1-05200-NICOBAR.0#n688
> > > 
> > > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>  
> > 
> > I'm not keen on patches with no context being
> > sent to mailing lists. Please cc all lists (and preferably individuals)
> > on at least the cover letter so we can see overall discussion.  
> 
> That can be attributed to the terrible workflow for sending
> patch-series.  Somehow only `git send-email` supports --cc-cmd yet I'd
> expect it on `git format-patch` for auditing and possibly copying to the
> cover letter, if `git format-patch --cover-letter` couldn't do this from
> the beginning.

It would definitely be nice as an option.  Can't do it every time because
on tree wide change the cc list can become so large the mailing lists
reject it.

> At the same time `git send-email` has --[to/cc]-cover options to
> propagate email addresses from the cover letter to all the individual
> patch-replies, but not the inverse :(
> 
> In the end this leaves me manually running get_maintainer.pl over the
> entire formatted patch-series, and manually copy-pasting + editing the
> addresses into the cover letter... Which is easy to forget and is no
> different here.
> 
> My apologies for (yet again) accidentally not sending at least the cover
> letter to everyone.  That's a gross oversight, and I'm probably - no, I
> must - be doing something wrong.  Suggestions and/or documentation
> references are welcome.

Andy Shevchenko has some scripts to try and help with this:
https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh

I've not started using them myself (not gotten around to it yet!) but
he's pointed to them when I've missed people from cover letter cc lists
in the past.

> 
> > If nothing else, I've no idea if intent is that the patches go through different
> > trees or all need to merge via one route.  
> 
> I have no idea either, and have not yet had an answer to a similar
> question on a different list.  Usually it seems the maintainers work out
> amongst themselves who picks what patch, putting them on hold where
> necessary to preseve ordering.  If not, should the sender split patches
> across multiple series, either holding off sending part of it or linking
> to a dependent series?

In this case I think I can pick this patch up directly into the IIO tree
once everyone else is happy. As you note dts patches normally wait on
knowing the necessary support is heading in.  If you have a view on what
makes sense as the submitter it's good to stick it in the cover letter, but
in this case sounds like you don't. :)

Given we are near the end of this cycle, we are probably looking at next
cycle anyway now, so plenty of time to figure it out!

> 
> In this particular case DT has to wait for these driver patches to land,
> otherwise they may define channels that do not exist and unnecessarily
> fail probe.
> 
> > Patch itself looks fine,  
> 
> Thanks.
> 
> Looking forward to your suggestions and answers,
> 
> - Marijn
> 
> > [..]  

Re: [PATCH 4/7] iio: adc: qcom-spmi-adc5: Add missing VCOIN/AMUX_THM3/GPIO# channels

[Jonathan Cameron]

On Sun, 15 May 2022 17:57:14 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Sun, 15 May 2022 17:30:04 +0200
> Marijn Suijten <marijn.suijten@somainline.org> wrote:
> 
> > On 2022-05-14 17:13:12, Jonathan Cameron wrote:  
> > > On Thu, 12 May 2022 00:06:10 +0200
> > > Marijn Suijten <marijn.suijten@somainline.org> wrote:
> > >     
> > > > These channels are specified in downstream kernels [1] and actively used
> > > > by ie. the Sony Seine platform on the SM6125 SoC.    
> > > 
> > > Looking at the links, some of them are on that platform but not all.
> > > Better to make that explicit in this description.    
> > 
> > This has already been queued up for v2.  Adding these seemed easy at the
> > time but they are in fact not used, and I ended up sending the wrong
> > patch.
> > 
> > Just so that we're on the same page: only ADC5_AMUX_THM3 and
> > ADC5_GPIO2_100K_PU are unused by my platform.  It seems the first should
> > be dropped, but the latter can probably stay in the patch with an
> > explicit mention.  If you think both should stay, there are a bunch more
> > channels defined in the downstream kernel as per [1] and I'm not sure if
> > all should be added for completeness.  
> 
> Probably better to add them with a comment for platforms on which they
> apply (either in commit log or alongside the definitions in the code).
By 'them' I mean add the ones used on your platform only.  Let others
add theirs when / if boards using them are upstreamed.

(realised I'd been very unclear just after hitting send!)


> 
> Longer term we should think about whether the code can be adjusted
> to not need an explicit definition for these multi purpose channels
> though letting the dt itself describe them (under constraints of the
> hardware platform).  Not worth doing before this patch though.
> 
> >   
> > > > 
> > > > [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.14/tree/drivers/iio/adc/qcom-spmi-adc5.c?h=LA.UM.7.11.r1-05200-NICOBAR.0#n688
> > > > 
> > > > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>    
> > > 
> > > I'm not keen on patches with no context being
> > > sent to mailing lists. Please cc all lists (and preferably individuals)
> > > on at least the cover letter so we can see overall discussion.    
> > 
> > That can be attributed to the terrible workflow for sending
> > patch-series.  Somehow only `git send-email` supports --cc-cmd yet I'd
> > expect it on `git format-patch` for auditing and possibly copying to the
> > cover letter, if `git format-patch --cover-letter` couldn't do this from
> > the beginning.  
> 
> It would definitely be nice as an option.  Can't do it every time because
> on tree wide change the cc list can become so large the mailing lists
> reject it.
> 
> > At the same time `git send-email` has --[to/cc]-cover options to
> > propagate email addresses from the cover letter to all the individual
> > patch-replies, but not the inverse :(
> > 
> > In the end this leaves me manually running get_maintainer.pl over the
> > entire formatted patch-series, and manually copy-pasting + editing the
> > addresses into the cover letter... Which is easy to forget and is no
> > different here.
> > 
> > My apologies for (yet again) accidentally not sending at least the cover
> > letter to everyone.  That's a gross oversight, and I'm probably - no, I
> > must - be doing something wrong.  Suggestions and/or documentation
> > references are welcome.  
> 
> Andy Shevchenko has some scripts to try and help with this:
> https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh
> 
> I've not started using them myself (not gotten around to it yet!) but
> he's pointed to them when I've missed people from cover letter cc lists
> in the past.
> 
> >   
> > > If nothing else, I've no idea if intent is that the patches go through different
> > > trees or all need to merge via one route.    
> > 
> > I have no idea either, and have not yet had an answer to a similar
> > question on a different list.  Usually it seems the maintainers work out
> > amongst themselves who picks what patch, putting them on hold where
> > necessary to preseve ordering.  If not, should the sender split patches
> > across multiple series, either holding off sending part of it or linking
> > to a dependent series?  
> 
> In this case I think I can pick this patch up directly into the IIO tree
> once everyone else is happy. As you note dts patches normally wait on
> knowing the necessary support is heading in.  If you have a view on what
> makes sense as the submitter it's good to stick it in the cover letter, but
> in this case sounds like you don't. :)
> 
> Given we are near the end of this cycle, we are probably looking at next
> cycle anyway now, so plenty of time to figure it out!
> 
> > 
> > In this particular case DT has to wait for these driver patches to land,
> > otherwise they may define channels that do not exist and unnecessarily
> > fail probe.
> >   
> > > Patch itself looks fine,    
> > 
> > Thanks.
> > 
> > Looking forward to your suggestions and answers,
> > 
> > - Marijn
> >   
> > > [..]    
> 

[PATCH 5/7] arm64: dts: qcom: Add PM6125 PMIC

[Marijn Suijten]

This PMIC is commonly used on boards with an SM6125 SoC and looks very
similar in layout to the PM6150.

Downstream declares more nodes to be available, but these have been
omitted from this patch: the pwm/lpg block is unused on my reference
device making it impossible to test/validate, and the spmi-clkdiv does
not have a single device-tree binding using this driver yet, hence
inclusion is better postponed until ie. audio which uses these clocks is
brought up.

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 arch/arm64/boot/dts/qcom/pm6125.dtsi | 156 +++++++++++++++++++++++++++
 1 file changed, 156 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/pm6125.dtsi

diff --git a/arch/arm64/boot/dts/qcom/pm6125.dtsi b/arch/arm64/boot/dts/qcom/pm6125.dtsi
new file mode 100644
index 000000000000..5028001f8213
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm6125.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: BSD-3-Clause
+
+#include <dt-bindings/iio/qcom,spmi-vadc.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/spmi/spmi.h>
+
+/ {
+	thermal-zones {
+		pm6125-thermal {
+			polling-delay-passive = <100>;
+			polling-delay = <0>;
+
+			thermal-sensors = <&pm6125_temp>;
+
+			trips {
+				trip0 {
+					temperature = <95000>;
+					hysteresis = <0>;
+					type = "passive";
+				};
+
+				trip1 {
+					temperature = <115000>;
+					hysteresis = <0>;
+					type = "hot";
+				};
+
+				trip2 {
+					temperature = <145000>;
+					hysteresis = <0>;
+					type = "critical";
+				};
+			};
+		};
+	};
+};
+
+&spmi_bus {
+	pmic@0 {
+		compatible = "qcom,pm6125", "qcom,spmi-pmic";
+		reg = <0x0 SPMI_USID>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		pm6125_pon: pon@800 {
+			compatible = "qcom,pm8998-pon";
+			reg = <0x800>;
+			mode-bootloader = <0x2>;
+			mode-recovery = <0x1>;
+
+			pon_pwrkey: pwrkey {
+				compatible = "qcom,pm8941-pwrkey";
+				interrupts = <0x0 0x8 0x0 IRQ_TYPE_EDGE_BOTH>;
+				debounce = <15625>;
+				linux,code = <KEY_POWER>;
+				bias-pull-up;
+				status = "disabled";
+			};
+
+			pon_resin: resin {
+				compatible = "qcom,pm8941-resin";
+				interrupts = <0x0 0x8 0x1 IRQ_TYPE_EDGE_BOTH>;
+				debounce = <15625>;
+				bias-pull-up;
+				status = "disabled";
+			};
+		};
+
+		pm6125_temp: temp-alarm@2400 {
+			compatible = "qcom,spmi-temp-alarm";
+			reg = <0x2400>;
+			interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_RISING>;
+			io-channels = <&pm6125_adc ADC5_DIE_TEMP>;
+			io-channel-names = "thermal";
+			#thermal-sensor-cells = <0>;
+		};
+
+		pm6125_adc: adc@3100 {
+			compatible = "qcom,spmi-adc5";
+			reg = <0x3100>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+			#io-channel-cells = <1>;
+
+			ref-gnd@0 {
+				reg = <ADC5_REF_GND>;
+				qcom,pre-scaling = <1 1>;
+			};
+
+			vref-1p25@1 {
+				reg = <ADC5_1P25VREF>;
+				qcom,pre-scaling = <1 1>;
+			};
+
+			die-temp@6 {
+				reg = <ADC5_DIE_TEMP>;
+				qcom,pre-scaling = <1 1>;
+			};
+
+			vph-pwr@83 {
+				reg = <ADC5_VPH_PWR>;
+				qcom,pre-scaling = <1 3>;
+			};
+
+			vcoin@85 {
+				reg = <ADC5_VCOIN>;
+				qcom,pre-scaling = <1 3>;
+			};
+
+			xo-therm@4c {
+				reg = <ADC5_XO_THERM_100K_PU>;
+				qcom,pre-scaling = <1 1>;
+				qcom,hw-settle-time = <200>;
+				qcom,ratiometric;
+			};
+		};
+
+		pm6125_adc_tm: adc-tm@3500 {
+			compatible = "qcom,spmi-adc-tm5";
+			reg = <0x3500>;
+			interrupts = <0x0 0x35 0x0 IRQ_TYPE_EDGE_RISING>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#thermal-sensor-cells = <1>;
+			status = "disabled";
+		};
+
+		pm6125_rtc: rtc@6000 {
+			compatible = "qcom,pm8941-rtc";
+			reg = <0x6000>, <0x6100>;
+			reg-names = "rtc", "alarm";
+			interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
+			status = "disabled";
+		};
+
+		pm6125_gpio: gpios@c000 {
+			compatible = "qcom,pm6125-gpio", "qcom,spmi-gpio";
+			reg = <0xc000>;
+			gpio-controller;
+			gpio-ranges = <&pm6125_gpio 0 0 9>;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+
+	pmic@1 {
+		compatible = "qcom,pm6125", "qcom,spmi-pmic";
+		reg = <0x1 SPMI_USID>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
-- 
2.36.1

Re: [PATCH 5/7] arm64: dts: qcom: Add PM6125 PMIC

[Krzysztof Kozlowski]

On 12/05/2022 00:06, Marijn Suijten wrote:
> This PMIC is commonly used on boards with an SM6125 SoC and looks very
> similar in layout to the PM6150.
> 
> Downstream declares more nodes to be available, but these have been
> omitted from this patch: the pwm/lpg block is unused on my reference
> device making it impossible to test/validate, and the spmi-clkdiv does
> not have a single device-tree binding using this driver yet, hence
> inclusion is better postponed until ie. audio which uses these clocks is
> brought up.
> 
> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>

Two reviews on first patch... :)

> +
> +	pmic@1 {
> +		compatible = "qcom,pm6125", "qcom,spmi-pmic";
> +		reg = <0x1 SPMI_USID>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;

No children, so this should not be needed, I think.

> +	};
> +};


Best regards,
Krzysztof

Re: [PATCH 5/7] arm64: dts: qcom: Add PM6125 PMIC

[Marijn Suijten]

On 2022-05-13 10:24:04, Krzysztof Kozlowski wrote:
> On 12/05/2022 00:06, Marijn Suijten wrote:
> > This PMIC is commonly used on boards with an SM6125 SoC and looks very
> > similar in layout to the PM6150.
> > 
> > Downstream declares more nodes to be available, but these have been
> > omitted from this patch: the pwm/lpg block is unused on my reference
> > device making it impossible to test/validate, and the spmi-clkdiv does
> > not have a single device-tree binding using this driver yet, hence
> > inclusion is better postponed until ie. audio which uses these clocks is
> > brought up.
> > 
> > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> 
> Two reviews on first patch... :)

Same story here, we review each-others patches in advance and it'd be
annoying to have them re-send their approval through the mailing list;
only for me/us to pick it up in a v2.

> > +
> > +	pmic@1 {
> > +		compatible = "qcom,pm6125", "qcom,spmi-pmic";
> > +		reg = <0x1 SPMI_USID>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> 
> No children, so this should not be needed, I think.

The size-cells or the entire node?  There's a PWM/LPG block here
according to downstream DT, but my device doesn't use it so I can't test
that it is valid.  I can add it anyway, presuming reviewers here have
the ability to validate it for me with a reference manual.

- Marijn

Re: [PATCH 5/7] arm64: dts: qcom: Add PM6125 PMIC

[Krzysztof Kozlowski]

On 13/05/2022 11:25, Marijn Suijten wrote:
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>
>> No children, so this should not be needed, I think.
> 
> The size-cells or the entire node?  There's a PWM/LPG block here
> according to downstream DT, but my device doesn't use it so I can't test
> that it is valid.  I can add it anyway, presuming reviewers here have
> the ability to validate it for me with a reference manual.


I mean only the address/size cells. They are needed for the children,
unless some binding expects it?


Best regards,
Krzysztof

[PATCH 6/7] arm64: dts: qcom: sm6125-seine: Include PM6125 and configure PON

[Marijn Suijten]

The Sony Xperia Seine board uses the PM6125; include it and configure
the PON buttons that provide the power and volume-up key.

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 .../boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
index 038970c0b68e..c5967140d028 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
@@ -6,8 +6,8 @@
 /dts-v1/;
 
 #include "sm6125.dtsi"
+#include "pm6125.dtsi"
 #include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
 #include <dt-bindings/input/gpio-keys.h>
 
 / {
@@ -88,6 +88,15 @@ &hsusb_phy1 {
 	status = "okay";
 };
 
+&pon_pwrkey {
+	status = "okay";
+};
+
+&pon_resin {
+	status = "okay";
+	linux,code = <KEY_VOLUMEUP>;
+};
+
 &sdc2_off_state {
 	sd-cd {
 		pins = "gpio98";
-- 
2.36.1

[PATCH 7/7] arm64: dts: qcom: sm6125-seine: Configure additional trinket thermistors

[Marijn Suijten]

In addition to PMIC-specific (pm6125) thermistors downstream extends
this set with the rf-pa0/rf-pa1, quiet, camera-flash and UFS/eMMC
thermistors in sm6125 (trinket) board and seine-specific DT files.  All
thermistors report sensible temperature readings in userspace.

The sensors are also added to their respective Thermal Monitor node,
with thermal zones to match where applicable: emmc-ufs and camera-flash
are not available on the TM5 block, hence cannot be configured with a
tripping point and will not have a thermal zone.

Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
---
 .../qcom/sm6125-sony-xperia-seine-pdx201.dts  | 150 ++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
index c5967140d028..ca7f074a62a9 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dts
@@ -82,12 +82,162 @@ cmdline_mem: memory@ffd00000 {
 			no-map;
 		};
 	};
+
+	thermal-zones {
+		rf-pa0-thermal {
+			polling-delay-passive = <0>;
+			polling-delay = <0>;
+			thermal-sensors = <&pm6125_adc_tm 0>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "critical";
+				};
+			};
+		};
+
+		quiet-thermal {
+			polling-delay-passive = <0>;
+			polling-delay = <5000>;
+			thermal-sensors = <&pm6125_adc_tm 1>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "critical";
+				};
+			};
+		};
+
+		xo-thermal {
+			polling-delay-passive = <0>;
+			polling-delay = <0>;
+			thermal-sensors = <&pm6125_adc_tm 2>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "critical";
+				};
+			};
+		};
+
+		rf-pa1-thermal {
+			polling-delay-passive = <0>;
+			polling-delay = <0>;
+			thermal-sensors = <&pm6125_adc_tm 3>;
+
+			trips {
+				active-config0 {
+					temperature = <125000>;
+					hysteresis = <1000>;
+					type = "critical";
+				};
+			};
+		};
+	};
 };
 
 &hsusb_phy1 {
 	status = "okay";
 };
 
+&pm6125_adc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&camera_flash_therm &emmc_ufs_therm &rf_pa1_therm>;
+
+	rf-pa0-therm@4d {
+		reg = <ADC5_AMUX_THM1_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+
+	quiet-therm@4e {
+		reg = <ADC5_AMUX_THM2_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+
+	camera-flash-therm@52 {
+		reg = <ADC5_GPIO1_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+
+	emmc-ufs-therm@54 {
+		reg = <ADC5_GPIO3_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+
+	rf-pa1-therm@55 {
+		reg = <ADC5_GPIO4_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+		qcom,pre-scaling = <1 1>;
+	};
+};
+
+&pm6125_adc_tm {
+	status = "okay";
+
+	rf-pa0-therm@0 {
+		reg = <0>;
+		io-channels = <&pm6125_adc ADC5_AMUX_THM1_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+	};
+
+	quiet-therm@1 {
+		reg = <1>;
+		io-channels = <&pm6125_adc ADC5_AMUX_THM2_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+	};
+
+	xo-therm@2 {
+		reg = <2>;
+		io-channels = <&pm6125_adc ADC5_XO_THERM_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+	};
+
+	rf-pa1-therm@3 {
+		reg = <3>;
+		io-channels = <&pm6125_adc ADC5_GPIO4_100K_PU>;
+		qcom,ratiometric;
+		qcom,hw-settle-time = <200>;
+	};
+};
+
+&pm6125_gpio {
+	camera_flash_therm: camera-flash-therm {
+		pins = "gpio3";
+		function = "normal";
+		bias-high-impedance;
+	};
+
+	emmc_ufs_therm: emmc-ufs-therm {
+		pins = "gpio6";
+		function = "normal";
+		bias-high-impedance;
+	};
+
+	rf_pa1_therm: rf-pa1-therm {
+		pins = "gpio7";
+		function = "normal";
+		bias-high-impedance;
+	};
+};
+
 &pon_pwrkey {
 	status = "okay";
 };
-- 
2.36.1

Re: [PATCH 7/7] arm64: dts: qcom: sm6125-seine: Configure additional trinket thermistors

[Krzysztof Kozlowski]

On 12/05/2022 00:06, Marijn Suijten wrote:
> +
> +&pm6125_gpio {
> +	camera_flash_therm: camera-flash-therm {

Align with dtschema please:

https://lore.kernel.org/all/20220507194913.261121-6-krzysztof.kozlowski@linaro.org/

> +		pins = "gpio3";
> +		function = "normal";

I think there are macros for the function

> +		bias-high-impedance;
> +	};
> +
> +	emmc_ufs_therm: emmc-ufs-therm {
> +		pins = "gpio6";
> +		function = "normal";
> +		bias-high-impedance;
> +	};
> +
> +	rf_pa1_therm: rf-pa1-therm {
> +		pins = "gpio7";
> +		function = "normal";
> +		bias-high-impedance;



Best regards,
Krzysztof