[PATCH v3 00/11] Armada thermal: improvements and A7K/A8K SoCs support

[PATCH v3 00/11] Armada thermal: improvements and A7K/A8K SoCs support

[Miquel Raynal]

Hi,

This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.

For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.

DT bindings documentation is updated to match existing code. A new
property is introduced to identify thermal zones, see the commit using
it for more details.

Armada AP806 and CP110 DT are also updated with thermal nodes.

Thank you,
Miquèl


Baruch Siach (4):
  dt-bindings: thermal: Describe Armada AP806 and CP110
  thermal: armada: Use msleep for long delays
  thermal: armada: Add support for Armada AP806
  thermal: armada: Add support for Armada CP110

Miquel Raynal (7):
  thermal: armada: Simplify the check of the validity bit
  thermal: armada: Rationalize register accesses
  thermal: armada: Update Kconfig and module description
  thermal: armada: Change sensors trim default value
  thermal: armada: Wait sensors validity before exiting the init
    callback
  thermal: armada: Give useful names to the thermal zone
  ARM64: dts: marvell: Add thermal support for A7K/A8K

 .../devicetree/bindings/thermal/armada-thermal.txt |  29 ++-
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      |   7 +
 .../boot/dts/marvell/armada-cp110-master.dtsi      |   7 +
 .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |   7 +
 drivers/thermal/Kconfig                            |   4 +-
 drivers/thermal/armada_thermal.c                   | 225 ++++++++++++++++-----
 6 files changed, 222 insertions(+), 57 deletions(-)

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 00/11] Armada thermal: improvements and A7K/A8K SoCs support

[Miquel Raynal]

Hi,

This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.

For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.

DT bindings documentation is updated to match existing code. A new
property is introduced to identify thermal zones, see the commit using
it for more details.

Armada AP806 and CP110 DT are also updated with thermal nodes.

Thank you,
Miqu?l


Baruch Siach (4):
  dt-bindings: thermal: Describe Armada AP806 and CP110
  thermal: armada: Use msleep for long delays
  thermal: armada: Add support for Armada AP806
  thermal: armada: Add support for Armada CP110

Miquel Raynal (7):
  thermal: armada: Simplify the check of the validity bit
  thermal: armada: Rationalize register accesses
  thermal: armada: Update Kconfig and module description
  thermal: armada: Change sensors trim default value
  thermal: armada: Wait sensors validity before exiting the init
    callback
  thermal: armada: Give useful names to the thermal zone
  ARM64: dts: marvell: Add thermal support for A7K/A8K

 .../devicetree/bindings/thermal/armada-thermal.txt |  29 ++-
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      |   7 +
 .../boot/dts/marvell/armada-cp110-master.dtsi      |   7 +
 .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |   7 +
 drivers/thermal/Kconfig                            |   4 +-
 drivers/thermal/armada_thermal.c                   | 225 ++++++++++++++++-----
 6 files changed, 222 insertions(+), 57 deletions(-)

-- 
2.11.0

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.

Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.

Also add a note about the new property "marvell,thermal-zone-name" to
help identify the zones from the sysfs.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: reword, additional details, new
property]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 .../devicetree/bindings/thermal/armada-thermal.txt | 29 ++++++++++++++++++----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..1602dc2ee220 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -7,17 +7,36 @@ Required properties:
 		marvell,armada375-thermal
 		marvell,armada380-thermal
 		marvell,armadaxp-thermal
+		marvell,armada-ap806-thermal
+		marvell,armada-cp110-thermal
 
 - reg:		Device's register space.
 		Two entries are expected, see the examples below.
-		The first one is required for the sensor register;
-		the second one is required for the control register
-		to be used for sensor initialization (a.k.a. calibration).
+		The first one points to the status register (4B).
+		The second one points to the control registers (8B).
+		Note: with legacy bindings, the second entry pointed
+		only on the so called "control MSB" ("control 1"), was
+		4B wide and did not let the possibility to reach the
+		"control LSB" ("control 0") register.
 
-Example:
+Optional properties:
 
+- marvell,thermal-zone-name: The name to identify the thermal zone
+                             within the sysfs, useful when multiple
+                             thermal zones are registered (AP, CPx...).
+
+Examples:
+
+	/* Legacy bindings */
 	thermal@d0018300 {
 		compatible = "marvell,armada370-thermal";
-                reg = <0xd0018300 0x4
+		reg = <0xd0018300 0x4
 		       0xd0018304 0x4>;
 	};
+
+	ap_thermal: thermal@6f8084 {
+		compatible = "marvell,armada-ap806-thermal";
+		reg = <0x6f808C 0x4>,
+		      <0x6f8084 0x8>;
+		marvell,thermal-zone-name = "ap_thermal_zone";
+	};
-- 
2.11.0

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.

Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.

Also add a note about the new property "marvell,thermal-zone-name" to
help identify the zones from the sysfs.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: reword, additional details, new
property]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 .../devicetree/bindings/thermal/armada-thermal.txt | 29 ++++++++++++++++++----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..1602dc2ee220 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -7,17 +7,36 @@ Required properties:
 		marvell,armada375-thermal
 		marvell,armada380-thermal
 		marvell,armadaxp-thermal
+		marvell,armada-ap806-thermal
+		marvell,armada-cp110-thermal
 
 - reg:		Device's register space.
 		Two entries are expected, see the examples below.
-		The first one is required for the sensor register;
-		the second one is required for the control register
-		to be used for sensor initialization (a.k.a. calibration).
+		The first one points to the status register (4B).
+		The second one points to the control registers (8B).
+		Note: with legacy bindings, the second entry pointed
+		only on the so called "control MSB" ("control 1"), was
+		4B wide and did not let the possibility to reach the
+		"control LSB" ("control 0") register.
 
-Example:
+Optional properties:
 
+- marvell,thermal-zone-name: The name to identify the thermal zone
+                             within the sysfs, useful when multiple
+                             thermal zones are registered (AP, CPx...).
+
+Examples:
+
+	/* Legacy bindings */
 	thermal at d0018300 {
 		compatible = "marvell,armada370-thermal";
-                reg = <0xd0018300 0x4
+		reg = <0xd0018300 0x4
 		       0xd0018304 0x4>;
 	};
+
+	ap_thermal: thermal at 6f8084 {
+		compatible = "marvell,armada-ap806-thermal";
+		reg = <0x6f808C 0x4>,
+		      <0x6f8084 0x8>;
+		marvell,thermal-zone-name = "ap_thermal_zone";
+	};
-- 
2.11.0

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Baruch Siach]

Hi Miquel

On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> +- marvell,thermal-zone-name: The name to identify the thermal zone
> +                             within the sysfs, useful when multiple
> +                             thermal zones are registered (AP, CPx...).

I don't think that would be acceptable. DT is about describing the hardware. 
sysfs is a Linux implementation detail which is not tied to any specific 
hardware. If this is accepted, the property should be named 
'linux,thermal-zone-name'.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Baruch Siach]

Hi Miquel

On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> +- marvell,thermal-zone-name: The name to identify the thermal zone
> +                             within the sysfs, useful when multiple
> +                             thermal zones are registered (AP, CPx...).

I don't think that would be acceptable. DT is about describing the hardware. 
sysfs is a Linux implementation detail which is not tied to any specific 
hardware. If this is accepted, the property should be named 
'linux,thermal-zone-name'.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Baruch,

On Fri, 15 Dec 2017 10:27:59 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:

> Hi Miquel
> 
> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > +                             within the sysfs, useful when multiple
> > +                             thermal zones are registered (AP,
> > CPx...).  
> 
> I don't think that would be acceptable. DT is about describing the
> hardware. sysfs is a Linux implementation detail which is not tied to
> any specific hardware. If this is accepted, the property should be
> named 'linux,thermal-zone-name'.

You are right the sysfs mention should not appear in the description.

Otherwise for the naming I'm not sure "linux," is a valid prefix in
that case.

Miquèl

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Baruch,

On Fri, 15 Dec 2017 10:27:59 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miquel
> 
> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > +                             within the sysfs, useful when multiple
> > +                             thermal zones are registered (AP,
> > CPx...).  
> 
> I don't think that would be acceptable. DT is about describing the
> hardware. sysfs is a Linux implementation detail which is not tied to
> any specific hardware. If this is accepted, the property should be
> named 'linux,thermal-zone-name'.

You are right the sysfs mention should not appear in the description.

Otherwise for the naming I'm not sure "linux," is a valid prefix in
that case.

Miqu?l

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Baruch Siach]

HI Miquèl

On Fri, Dec 15, 2017 at 09:32:03AM +0100, Miquel RAYNAL wrote:
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > 
> > On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > > +                             within the sysfs, useful when multiple
> > > +                             thermal zones are registered (AP,
> > > CPx...).  
> > 
> > I don't think that would be acceptable. DT is about describing the
> > hardware. sysfs is a Linux implementation detail which is not tied to
> > any specific hardware. If this is accepted, the property should be
> > named 'linux,thermal-zone-name'.
> 
> You are right the sysfs mention should not appear in the description.

My comment was not about the description language. I don't think that this 
property is acceptable at all. But I'll let DT maintainers comment on that.

> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

We use the 'linux' prefix for input key names and led triggers, for example.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Baruch Siach]

HI Miqu?l

On Fri, Dec 15, 2017 at 09:32:03AM +0100, Miquel RAYNAL wrote:
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > 
> > On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > > +                             within the sysfs, useful when multiple
> > > +                             thermal zones are registered (AP,
> > > CPx...).  
> > 
> > I don't think that would be acceptable. DT is about describing the
> > hardware. sysfs is a Linux implementation detail which is not tied to
> > any specific hardware. If this is accepted, the property should be
> > named 'linux,thermal-zone-name'.
> 
> You are right the sysfs mention should not appear in the description.

My comment was not about the description language. I don't think that this 
property is acceptable at all. But I'll let DT maintainers comment on that.

> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

We use the 'linux' prefix for input key names and led triggers, for example.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On ven., déc. 15 2017, Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hello Baruch,
>
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
>
>> Hi Miquel
>> 
>> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
>> > +- marvell,thermal-zone-name: The name to identify the thermal zone
>> > +                             within the sysfs, useful when multiple
>> > +                             thermal zones are registered (AP,
>> > CPx...).  
>> 
>> I don't think that would be acceptable. DT is about describing the
>> hardware. sysfs is a Linux implementation detail which is not tied to
>> any specific hardware. If this is accepted, the property should be
>> named 'linux,thermal-zone-name'.
>
> You are right the sysfs mention should not appear in the description.
>
> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

Actually the choice between linux or marvell make me realize that there
is something wrong. Having a name associated to a device is something
pretty usual with the device tree, however it is as the class device
level, such as clock-names, line-name, or regulator-name. So in my
opinion if we want to support naming from device tree it would be done
for all the thermal device not just for the Marvell one.

However I don't think we need it. For example for the clocks we created
the name dynamically using of the base address of the register to keep
them unique.

Gregory


>
> Miquèl
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On ven., d?c. 15 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> Hello Baruch,
>
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
>
>> Hi Miquel
>> 
>> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
>> > +- marvell,thermal-zone-name: The name to identify the thermal zone
>> > +                             within the sysfs, useful when multiple
>> > +                             thermal zones are registered (AP,
>> > CPx...).  
>> 
>> I don't think that would be acceptable. DT is about describing the
>> hardware. sysfs is a Linux implementation detail which is not tied to
>> any specific hardware. If this is accepted, the property should be
>> named 'linux,thermal-zone-name'.
>
> You are right the sysfs mention should not appear in the description.
>
> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.

Actually the choice between linux or marvell make me realize that there
is something wrong. Having a name associated to a device is something
pretty usual with the device tree, however it is as the class device
level, such as clock-names, line-name, or regulator-name. So in my
opinion if we want to support naming from device tree it would be done
for all the thermal device not just for the Marvell one.

However I don't think we need it. For example for the clocks we created
the name dynamically using of the base address of the register to keep
them unique.

Gregory


>
> Miqu?l
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Baruch and Gregory,

On Fri, 15 Dec 2017 09:44:19 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Miquel,
>  
>  On ven., déc. 15 2017, Miquel RAYNAL
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > Hello Baruch,
> >
> > On Fri, 15 Dec 2017 10:27:59 +0200
> > Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> >  
> >> Hi Miquel
> >> 
> >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:  
> >> > +- marvell,thermal-zone-name: The name to identify the thermal
> >> > zone
> >> > +                             within the sysfs, useful when
> >> > multiple
> >> > +                             thermal zones are registered (AP,
> >> > CPx...).    
> >> 
> >> I don't think that would be acceptable. DT is about describing the
> >> hardware. sysfs is a Linux implementation detail which is not tied
> >> to any specific hardware. If this is accepted, the property should
> >> be named 'linux,thermal-zone-name'.  
> >
> > You are right the sysfs mention should not appear in the
> > description.

Actually, you are right for all of it, this property should not
exist, sorry for my too quick answer.

> >
> > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > that case.  

Thank you both for your explanations, I was also wrong about the prefix.

> 
> Actually the choice between linux or marvell make me realize that
> there is something wrong. Having a name associated to a device is
> something pretty usual with the device tree, however it is as the
> class device level, such as clock-names, line-name, or
> regulator-name. So in my opinion if we want to support naming from
> device tree it would be done for all the thermal device not just for
> the Marvell one.
> 
> However I don't think we need it. For example for the clocks we
> created the name dynamically using of the base address of the
> register to keep them unique.

I was convinced that dev_name's would be the same but after trying it on
a 8040-DB, using dev_name(&pdev->dev) gives:

    f06f808c.thermal
    f2400078.thermal
    f4400078.thermal

which I found meaningful enough.

I will drop the property and use dev_name instead. I still need your
help to solve one problem though: how to make the distinction between
using "armada_thermal" (the previous name) and dev_name() ? If I don't
it kind of breaks userspace, doesn't it ?

Thank you,
Miquèl

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Baruch and Gregory,

On Fri, 15 Dec 2017 09:44:19 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On ven., d?c. 15 2017, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> 
> > Hello Baruch,
> >
> > On Fri, 15 Dec 2017 10:27:59 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> >  
> >> Hi Miquel
> >> 
> >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:  
> >> > +- marvell,thermal-zone-name: The name to identify the thermal
> >> > zone
> >> > +                             within the sysfs, useful when
> >> > multiple
> >> > +                             thermal zones are registered (AP,
> >> > CPx...).    
> >> 
> >> I don't think that would be acceptable. DT is about describing the
> >> hardware. sysfs is a Linux implementation detail which is not tied
> >> to any specific hardware. If this is accepted, the property should
> >> be named 'linux,thermal-zone-name'.  
> >
> > You are right the sysfs mention should not appear in the
> > description.

Actually, you are right for all of it, this property should not
exist, sorry for my too quick answer.

> >
> > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > that case.  

Thank you both for your explanations, I was also wrong about the prefix.

> 
> Actually the choice between linux or marvell make me realize that
> there is something wrong. Having a name associated to a device is
> something pretty usual with the device tree, however it is as the
> class device level, such as clock-names, line-name, or
> regulator-name. So in my opinion if we want to support naming from
> device tree it would be done for all the thermal device not just for
> the Marvell one.
> 
> However I don't think we need it. For example for the clocks we
> created the name dynamically using of the base address of the
> register to keep them unique.

I was convinced that dev_name's would be the same but after trying it on
a 8040-DB, using dev_name(&pdev->dev) gives:

    f06f808c.thermal
    f2400078.thermal
    f4400078.thermal

which I found meaningful enough.

I will drop the property and use dev_name instead. I still need your
help to solve one problem though: how to make the distinction between
using "armada_thermal" (the previous name) and dev_name() ? If I don't
it kind of breaks userspace, doesn't it ?

Thank you,
Miqu?l

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Rob Herring]

On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> Hello Baruch and Gregory,
> 
> On Fri, 15 Dec 2017 09:44:19 +0100
> Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > Hi Miquel,
> >  
> >  On ven., déc. 15 2017, Miquel RAYNAL
> > <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > 
> > > Hello Baruch,
> > >
> > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > >  
> > >> Hi Miquel
> > >> 
> > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:  
> > >> > +- marvell,thermal-zone-name: The name to identify the thermal
> > >> > zone
> > >> > +                             within the sysfs, useful when
> > >> > multiple
> > >> > +                             thermal zones are registered (AP,
> > >> > CPx...).    
> > >> 
> > >> I don't think that would be acceptable. DT is about describing the
> > >> hardware. sysfs is a Linux implementation detail which is not tied
> > >> to any specific hardware. If this is accepted, the property should
> > >> be named 'linux,thermal-zone-name'.  
> > >
> > > You are right the sysfs mention should not appear in the
> > > description.
> 
> Actually, you are right for all of it, this property should not
> exist, sorry for my too quick answer.
> 
> > >
> > > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > > that case.  
> 
> Thank you both for your explanations, I was also wrong about the prefix.
> 
> > 
> > Actually the choice between linux or marvell make me realize that
> > there is something wrong. Having a name associated to a device is
> > something pretty usual with the device tree, however it is as the
> > class device level, such as clock-names, line-name, or
> > regulator-name. So in my opinion if we want to support naming from
> > device tree it would be done for all the thermal device not just for
> > the Marvell one.
> > 
> > However I don't think we need it. For example for the clocks we
> > created the name dynamically using of the base address of the
> > register to keep them unique.
> 
> I was convinced that dev_name's would be the same but after trying it on
> a 8040-DB, using dev_name(&pdev->dev) gives:
> 
>     f06f808c.thermal
>     f2400078.thermal
>     f4400078.thermal
> 
> which I found meaningful enough.
> 
> I will drop the property and use dev_name instead. I still need your
> help to solve one problem though: how to make the distinction between
> using "armada_thermal" (the previous name) and dev_name() ? If I don't
> it kind of breaks userspace, doesn't it ?

No. The /sys/devices/... or /sys/bus/platform/... paths and names are 
not guaranteed to be stable. These changed for every platform converted 
to DT for example. Userspace should be accessing things through 
/sys/class/... (or deal with changes).

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Rob Herring]

On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> Hello Baruch and Gregory,
> 
> On Fri, 15 Dec 2017 09:44:19 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> 
> > Hi Miquel,
> >  
> >  On ven., d?c. 15 2017, Miquel RAYNAL
> > <miquel.raynal@free-electrons.com> wrote:
> > 
> > > Hello Baruch,
> > >
> > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > Baruch Siach <baruch@tkos.co.il> wrote:
> > >  
> > >> Hi Miquel
> > >> 
> > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:  
> > >> > +- marvell,thermal-zone-name: The name to identify the thermal
> > >> > zone
> > >> > +                             within the sysfs, useful when
> > >> > multiple
> > >> > +                             thermal zones are registered (AP,
> > >> > CPx...).    
> > >> 
> > >> I don't think that would be acceptable. DT is about describing the
> > >> hardware. sysfs is a Linux implementation detail which is not tied
> > >> to any specific hardware. If this is accepted, the property should
> > >> be named 'linux,thermal-zone-name'.  
> > >
> > > You are right the sysfs mention should not appear in the
> > > description.
> 
> Actually, you are right for all of it, this property should not
> exist, sorry for my too quick answer.
> 
> > >
> > > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > > that case.  
> 
> Thank you both for your explanations, I was also wrong about the prefix.
> 
> > 
> > Actually the choice between linux or marvell make me realize that
> > there is something wrong. Having a name associated to a device is
> > something pretty usual with the device tree, however it is as the
> > class device level, such as clock-names, line-name, or
> > regulator-name. So in my opinion if we want to support naming from
> > device tree it would be done for all the thermal device not just for
> > the Marvell one.
> > 
> > However I don't think we need it. For example for the clocks we
> > created the name dynamically using of the base address of the
> > register to keep them unique.
> 
> I was convinced that dev_name's would be the same but after trying it on
> a 8040-DB, using dev_name(&pdev->dev) gives:
> 
>     f06f808c.thermal
>     f2400078.thermal
>     f4400078.thermal
> 
> which I found meaningful enough.
> 
> I will drop the property and use dev_name instead. I still need your
> help to solve one problem though: how to make the distinction between
> using "armada_thermal" (the previous name) and dev_name() ? If I don't
> it kind of breaks userspace, doesn't it ?

No. The /sys/devices/... or /sys/bus/platform/... paths and names are 
not guaranteed to be stable. These changed for every platform converted 
to DT for example. Userspace should be accessing things through 
/sys/class/... (or deal with changes).

Rob

Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Rob,

On Fri, 15 Dec 2017 17:28:54 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> > Hello Baruch and Gregory,
> > 
> > On Fri, 15 Dec 2017 09:44:19 +0100
> > Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >   
> > > Hi Miquel,
> > >  
> > >  On ven., déc. 15 2017, Miquel RAYNAL
> > > <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > >   
> > > > Hello Baruch,
> > > >
> > > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > > Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > > >    
> > > >> Hi Miquel
> > > >> 
> > > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal
> > > >> wrote:    
> > > >> > +- marvell,thermal-zone-name: The name to identify the
> > > >> > thermal zone
> > > >> > +                             within the sysfs, useful when
> > > >> > multiple
> > > >> > +                             thermal zones are registered
> > > >> > (AP, CPx...).      
> > > >> 
> > > >> I don't think that would be acceptable. DT is about describing
> > > >> the hardware. sysfs is a Linux implementation detail which is
> > > >> not tied to any specific hardware. If this is accepted, the
> > > >> property should be named 'linux,thermal-zone-name'.    
> > > >
> > > > You are right the sysfs mention should not appear in the
> > > > description.  
> > 
> > Actually, you are right for all of it, this property should not
> > exist, sorry for my too quick answer.
> >   
> > > >
> > > > Otherwise for the naming I'm not sure "linux," is a valid
> > > > prefix in that case.    
> > 
> > Thank you both for your explanations, I was also wrong about the
> > prefix. 
> > > 
> > > Actually the choice between linux or marvell make me realize that
> > > there is something wrong. Having a name associated to a device is
> > > something pretty usual with the device tree, however it is as the
> > > class device level, such as clock-names, line-name, or
> > > regulator-name. So in my opinion if we want to support naming from
> > > device tree it would be done for all the thermal device not just
> > > for the Marvell one.
> > > 
> > > However I don't think we need it. For example for the clocks we
> > > created the name dynamically using of the base address of the
> > > register to keep them unique.  
> > 
> > I was convinced that dev_name's would be the same but after trying
> > it on a 8040-DB, using dev_name(&pdev->dev) gives:
> > 
> >     f06f808c.thermal
> >     f2400078.thermal
> >     f4400078.thermal
> > 
> > which I found meaningful enough.
> > 
> > I will drop the property and use dev_name instead. I still need your
> > help to solve one problem though: how to make the distinction
> > between using "armada_thermal" (the previous name) and dev_name() ?
> > If I don't it kind of breaks userspace, doesn't it ?  
> 
> No. The /sys/devices/... or /sys/bus/platform/... paths and names are 
> not guaranteed to be stable. These changed for every platform
> converted to DT for example. Userspace should be accessing things
> through /sys/class/... (or deal with changes).

Ok, thanks for the explanation.

I will sent a v4 early next week about all the changes requested.

Thank you all for reviewing.
Miquèl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110

[Miquel RAYNAL]

Hello Rob,

On Fri, 15 Dec 2017 17:28:54 -0600
Rob Herring <robh@kernel.org> wrote:

> On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> > Hello Baruch and Gregory,
> > 
> > On Fri, 15 Dec 2017 09:44:19 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >   
> > > Hi Miquel,
> > >  
> > >  On ven., d?c. 15 2017, Miquel RAYNAL
> > > <miquel.raynal@free-electrons.com> wrote:
> > >   
> > > > Hello Baruch,
> > > >
> > > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > > Baruch Siach <baruch@tkos.co.il> wrote:
> > > >    
> > > >> Hi Miquel
> > > >> 
> > > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal
> > > >> wrote:    
> > > >> > +- marvell,thermal-zone-name: The name to identify the
> > > >> > thermal zone
> > > >> > +                             within the sysfs, useful when
> > > >> > multiple
> > > >> > +                             thermal zones are registered
> > > >> > (AP, CPx...).      
> > > >> 
> > > >> I don't think that would be acceptable. DT is about describing
> > > >> the hardware. sysfs is a Linux implementation detail which is
> > > >> not tied to any specific hardware. If this is accepted, the
> > > >> property should be named 'linux,thermal-zone-name'.    
> > > >
> > > > You are right the sysfs mention should not appear in the
> > > > description.  
> > 
> > Actually, you are right for all of it, this property should not
> > exist, sorry for my too quick answer.
> >   
> > > >
> > > > Otherwise for the naming I'm not sure "linux," is a valid
> > > > prefix in that case.    
> > 
> > Thank you both for your explanations, I was also wrong about the
> > prefix. 
> > > 
> > > Actually the choice between linux or marvell make me realize that
> > > there is something wrong. Having a name associated to a device is
> > > something pretty usual with the device tree, however it is as the
> > > class device level, such as clock-names, line-name, or
> > > regulator-name. So in my opinion if we want to support naming from
> > > device tree it would be done for all the thermal device not just
> > > for the Marvell one.
> > > 
> > > However I don't think we need it. For example for the clocks we
> > > created the name dynamically using of the base address of the
> > > register to keep them unique.  
> > 
> > I was convinced that dev_name's would be the same but after trying
> > it on a 8040-DB, using dev_name(&pdev->dev) gives:
> > 
> >     f06f808c.thermal
> >     f2400078.thermal
> >     f4400078.thermal
> > 
> > which I found meaningful enough.
> > 
> > I will drop the property and use dev_name instead. I still need your
> > help to solve one problem though: how to make the distinction
> > between using "armada_thermal" (the previous name) and dev_name() ?
> > If I don't it kind of breaks userspace, doesn't it ?  
> 
> No. The /sys/devices/... or /sys/bus/platform/... paths and names are 
> not guaranteed to be stable. These changed for every platform
> converted to DT for example. Userspace should be accessing things
> through /sys/class/... (or deal with changes).

Ok, thanks for the explanation.

I will sent a v4 early next week about all the changes requested.

Thank you all for reviewing.
Miqu?l

[PATCH v3 02/11] thermal: armada: Use msleep for long delays

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
 	reg &= ~PMU_TDC0_START_CAL_MASK;
 	writel(reg, priv->control);
 
-	mdelay(10);
+	msleep(10);
 }
 
 static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
 	reg &= ~A375_HW_RESETn;
 
 	writel(reg, priv->control + 4);
-	mdelay(20);
+	msleep(20);
 
 	reg |= A375_HW_RESETn;
 	writel(reg, priv->control + 4);
-	mdelay(50);
+	msleep(50);
 }
 
 static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	if (!(reg & A380_HW_RESET)) {
 		reg |= A380_HW_RESET;
 		writel(reg, priv->control);
-		mdelay(10);
+		msleep(10);
 	}
 }
 
-- 
2.11.0

[PATCH v3 02/11] thermal: armada: Use msleep for long delays

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
 	reg &= ~PMU_TDC0_START_CAL_MASK;
 	writel(reg, priv->control);
 
-	mdelay(10);
+	msleep(10);
 }
 
 static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
 	reg &= ~A375_HW_RESETn;
 
 	writel(reg, priv->control + 4);
-	mdelay(20);
+	msleep(20);
 
 	reg |= A375_HW_RESETn;
 	writel(reg, priv->control + 4);
-	mdelay(50);
+	msleep(50);
 }
 
 static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	if (!(reg & A380_HW_RESET)) {
 		reg |= A380_HW_RESET;
 		writel(reg, priv->control);
-		mdelay(10);
+		msleep(10);
 	}
 }
 
-- 
2.11.0

Re: [PATCH v3 02/11] thermal: armada: Use msleep for long delays

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> From: Baruch Siach <baruch@tkos.co.il>
>
> Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
> All delays are called from the probe routine, where scheduling is
> allowed.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 706d74798cbe..6c4af2622d4f 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
>  	writel(reg, priv->control);
>  
> -	mdelay(10);
> +	msleep(10);
>  }
>  
>  static void armada375_init_sensor(struct platform_device *pdev,
> @@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
>  	reg &= ~A375_HW_RESETn;
>  
>  	writel(reg, priv->control + 4);
> -	mdelay(20);
> +	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
>  	writel(reg, priv->control + 4);
> -	mdelay(50);
> +	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
> @@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
>  		writel(reg, priv->control);
> -		mdelay(10);
> +		msleep(10);
>  	}
>  }
>  
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v3 02/11] thermal: armada: Use msleep for long delays

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> From: Baruch Siach <baruch@tkos.co.il>
>
> Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
> All delays are called from the probe routine, where scheduling is
> allowed.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 706d74798cbe..6c4af2622d4f 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
>  	writel(reg, priv->control);
>  
> -	mdelay(10);
> +	msleep(10);
>  }
>  
>  static void armada375_init_sensor(struct platform_device *pdev,
> @@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
>  	reg &= ~A375_HW_RESETn;
>  
>  	writel(reg, priv->control + 4);
> -	mdelay(20);
> +	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
>  	writel(reg, priv->control + 4);
> -	mdelay(50);
> +	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
> @@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
>  		writel(reg, priv->control);
> -		mdelay(10);
> +		msleep(10);
>  	}
>  }
>  
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Miquel Raynal]

All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.

The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.

Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/thermal/armada_thermal.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..26698f2d3ca7 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
 #include <linux/of_device.h>
 #include <linux/thermal.h>
 
-#define THERMAL_VALID_MASK		0x1
-
 /* Thermal Manager Control and Status Register */
 #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
 #define PMU_TM_DISABLE_OFFS		0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
 	/* Register shift and mask to access the sensor temperature */
 	unsigned int temp_shift;
 	unsigned int temp_mask;
-	unsigned int is_valid_shift;
+	unsigned int is_valid_bit;
 };
 
 static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
 	unsigned long reg = readl_relaxed(priv->sensor);
 
-	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+	return reg & priv->data->is_valid_bit;
 }
 
 static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
 static const struct armada_thermal_data armada370_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada370_init_sensor,
-	.is_valid_shift = 9,
+	.is_valid_bit = BIT(9),
 	.temp_shift = 10,
 	.temp_mask = 0x1ff,
 	.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
 static const struct armada_thermal_data armada375_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada375_init_sensor,
-	.is_valid_shift = 10,
+	.is_valid_bit = BIT(10),
 	.temp_shift = 0,
 	.temp_mask = 0x1ff,
 	.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
 static const struct armada_thermal_data armada380_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada380_init_sensor,
-	.is_valid_shift = 10,
+	.is_valid_bit = BIT(10),
 	.temp_shift = 0,
 	.temp_mask = 0x3ff,
 	.coef_b = 1172499100UL,
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Miquel Raynal]

All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.

The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..26698f2d3ca7 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
 #include <linux/of_device.h>
 #include <linux/thermal.h>
 
-#define THERMAL_VALID_MASK		0x1
-
 /* Thermal Manager Control and Status Register */
 #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
 #define PMU_TM_DISABLE_OFFS		0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
 	/* Register shift and mask to access the sensor temperature */
 	unsigned int temp_shift;
 	unsigned int temp_mask;
-	unsigned int is_valid_shift;
+	unsigned int is_valid_bit;
 };
 
 static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
 	unsigned long reg = readl_relaxed(priv->sensor);
 
-	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+	return reg & priv->data->is_valid_bit;
 }
 
 static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
 static const struct armada_thermal_data armada370_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada370_init_sensor,
-	.is_valid_shift = 9,
+	.is_valid_bit = BIT(9),
 	.temp_shift = 10,
 	.temp_mask = 0x1ff,
 	.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
 static const struct armada_thermal_data armada375_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada375_init_sensor,
-	.is_valid_shift = 10,
+	.is_valid_bit = BIT(10),
 	.temp_shift = 0,
 	.temp_mask = 0x1ff,
 	.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
 static const struct armada_thermal_data armada380_data = {
 	.is_valid = armada_is_valid,
 	.init_sensor = armada380_init_sensor,
-	.is_valid_shift = 10,
+	.is_valid_bit = BIT(10),
 	.temp_shift = 0,
 	.temp_mask = 0x3ff,
 	.coef_b = 1172499100UL,
-- 
2.11.0

Re: [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
>
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
>  
> -#define THERMAL_VALID_MASK		0x1
> -
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
>  #define PMU_TM_DISABLE_OFFS		0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
>  	unsigned int temp_mask;
> -	unsigned int is_valid_shift;
> +	unsigned int is_valid_bit;
>  };
>  
>  static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	unsigned long reg = readl_relaxed(priv->sensor);
>  
> -	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> +	return reg & priv->data->is_valid_bit;
>  }
>  
>  static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
>  static const struct armada_thermal_data armada370_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada370_init_sensor,
> -	.is_valid_shift = 9,
> +	.is_valid_bit = BIT(9),
>  	.temp_shift = 10,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
>  static const struct armada_thermal_data armada375_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada375_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
>  static const struct armada_thermal_data armada380_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada380_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x3ff,
>  	.coef_b = 1172499100UL,
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
>
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
>  
> -#define THERMAL_VALID_MASK		0x1
> -
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
>  #define PMU_TM_DISABLE_OFFS		0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
>  	unsigned int temp_mask;
> -	unsigned int is_valid_shift;
> +	unsigned int is_valid_bit;
>  };
>  
>  static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	unsigned long reg = readl_relaxed(priv->sensor);
>  
> -	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> +	return reg & priv->data->is_valid_bit;
>  }
>  
>  static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
>  static const struct armada_thermal_data armada370_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada370_init_sensor,
> -	.is_valid_shift = 9,
> +	.is_valid_bit = BIT(9),
>  	.temp_shift = 10,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
>  static const struct armada_thermal_data armada375_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada375_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
>  static const struct armada_thermal_data armada380_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada380_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x3ff,
>  	.coef_b = 1172499100UL,
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Baruch Siach]

Hi Miquel,

On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
> 
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/thermal/armada_thermal.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
>  
> -#define THERMAL_VALID_MASK		0x1
> -
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
>  #define PMU_TM_DISABLE_OFFS		0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
>  	unsigned int temp_mask;
> -	unsigned int is_valid_shift;
> +	unsigned int is_valid_bit;

Type should be u32 now, I think.

>  };
>  
>  static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	unsigned long reg = readl_relaxed(priv->sensor);

u32 here also, I think. But that's unrelated to this patch.

> -	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> +	return reg & priv->data->is_valid_bit;
>  }
>  
>  static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
>  static const struct armada_thermal_data armada370_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada370_init_sensor,
> -	.is_valid_shift = 9,
> +	.is_valid_bit = BIT(9),
>  	.temp_shift = 10,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
>  static const struct armada_thermal_data armada375_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada375_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
>  static const struct armada_thermal_data armada380_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada380_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x3ff,
>  	.coef_b = 1172499100UL,

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Baruch Siach]

Hi Miquel,

On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
> 
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
>  
> -#define THERMAL_VALID_MASK		0x1
> -
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
>  #define PMU_TM_DISABLE_OFFS		0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
>  	unsigned int temp_mask;
> -	unsigned int is_valid_shift;
> +	unsigned int is_valid_bit;

Type should be u32 now, I think.

>  };
>  
>  static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	unsigned long reg = readl_relaxed(priv->sensor);

u32 here also, I think. But that's unrelated to this patch.

> -	return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> +	return reg & priv->data->is_valid_bit;
>  }
>  
>  static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
>  static const struct armada_thermal_data armada370_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada370_init_sensor,
> -	.is_valid_shift = 9,
> +	.is_valid_bit = BIT(9),
>  	.temp_shift = 10,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
>  static const struct armada_thermal_data armada375_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada375_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x1ff,
>  	.coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
>  static const struct armada_thermal_data armada380_data = {
>  	.is_valid = armada_is_valid,
>  	.init_sensor = armada380_init_sensor,
> -	.is_valid_shift = 10,
> +	.is_valid_bit = BIT(10),
>  	.temp_shift = 0,
>  	.temp_mask = 0x3ff,
>  	.coef_b = 1172499100UL,

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Miquel RAYNAL]

Hello Baruch,

On Fri, 15 Dec 2017 10:33:16 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miquel,
> 
> On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> > All Armada SoCs use one bit to declare if the sensor values are
> > valid. This bit moves across the versions of the IP.
> > 
> > The method until then was to do both a shift and compare with an
> > useless flag of "0x1". It is clearer and quicker to directly save
> > the value that must be ANDed instead of the bit position and do a
> > single bitwise AND operation.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  drivers/thermal/armada_thermal.c | 12 +++++-------
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 6c4af2622d4f..26698f2d3ca7
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -24,8 +24,6 @@
> >  #include <linux/of_device.h>
> >  #include <linux/thermal.h>
> >  
> > -#define THERMAL_VALID_MASK		0x1
> > -
> >  /* Thermal Manager Control and Status Register */
> >  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
> >  #define PMU_TM_DISABLE_OFFS		0
> > @@ -67,7 +65,7 @@ struct armada_thermal_data {
> >  	/* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> >  	unsigned int temp_mask;
> > -	unsigned int is_valid_shift;
> > +	unsigned int is_valid_bit;  
> 
> Type should be u32 now, I think.

Indeed, I'll change it in next version.

> 
> >  };
> >  
> >  static void armadaxp_init_sensor(struct platform_device *pdev,
> > @@ -151,7 +149,7 @@ static bool armada_is_valid(struct
> > armada_thermal_priv *priv) {
> >  	unsigned long reg = readl_relaxed(priv->sensor);  
> 
> u32 here also, I think. But that's unrelated to this patch.

I completely agree, actually this is done in the next patch, moving all
"unsigned long reg" to "u32 reg" while renaming the registers
pointers, hope this is fine?

> 
> > -	return (reg >> priv->data->is_valid_shift) &
> > THERMAL_VALID_MASK;
> > +	return reg & priv->data->is_valid_bit;
> >  }
> >  
> >  static int armada_get_temp(struct thermal_zone_device *thermal,
> > @@ -199,7 +197,7 @@ static const struct armada_thermal_data
> > armadaxp_data = { static const struct armada_thermal_data
> > armada370_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada370_init_sensor,
> > -	.is_valid_shift = 9,
> > +	.is_valid_bit = BIT(9),
> >  	.temp_shift = 10,
> >  	.temp_mask = 0x1ff,
> >  	.coef_b = 3153000000UL,
> > @@ -210,7 +208,7 @@ static const struct armada_thermal_data
> > armada370_data = { static const struct armada_thermal_data
> > armada375_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada375_init_sensor,
> > -	.is_valid_shift = 10,
> > +	.is_valid_bit = BIT(10),
> >  	.temp_shift = 0,
> >  	.temp_mask = 0x1ff,
> >  	.coef_b = 3171900000UL,
> > @@ -221,7 +219,7 @@ static const struct armada_thermal_data
> > armada375_data = { static const struct armada_thermal_data
> > armada380_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada380_init_sensor,
> > -	.is_valid_shift = 10,
> > +	.is_valid_bit = BIT(10),
> >  	.temp_shift = 0,
> >  	.temp_mask = 0x3ff,
> >  	.coef_b = 1172499100UL,  
> 
> baruch
> 


Best regards,
Miquèl

[PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit

[Miquel RAYNAL]

Hello Baruch,

On Fri, 15 Dec 2017 10:33:16 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miquel,
> 
> On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> > All Armada SoCs use one bit to declare if the sensor values are
> > valid. This bit moves across the versions of the IP.
> > 
> > The method until then was to do both a shift and compare with an
> > useless flag of "0x1". It is clearer and quicker to directly save
> > the value that must be ANDed instead of the bit position and do a
> > single bitwise AND operation.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  drivers/thermal/armada_thermal.c | 12 +++++-------
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 6c4af2622d4f..26698f2d3ca7
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -24,8 +24,6 @@
> >  #include <linux/of_device.h>
> >  #include <linux/thermal.h>
> >  
> > -#define THERMAL_VALID_MASK		0x1
> > -
> >  /* Thermal Manager Control and Status Register */
> >  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
> >  #define PMU_TM_DISABLE_OFFS		0
> > @@ -67,7 +65,7 @@ struct armada_thermal_data {
> >  	/* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> >  	unsigned int temp_mask;
> > -	unsigned int is_valid_shift;
> > +	unsigned int is_valid_bit;  
> 
> Type should be u32 now, I think.

Indeed, I'll change it in next version.

> 
> >  };
> >  
> >  static void armadaxp_init_sensor(struct platform_device *pdev,
> > @@ -151,7 +149,7 @@ static bool armada_is_valid(struct
> > armada_thermal_priv *priv) {
> >  	unsigned long reg = readl_relaxed(priv->sensor);  
> 
> u32 here also, I think. But that's unrelated to this patch.

I completely agree, actually this is done in the next patch, moving all
"unsigned long reg" to "u32 reg" while renaming the registers
pointers, hope this is fine?

> 
> > -	return (reg >> priv->data->is_valid_shift) &
> > THERMAL_VALID_MASK;
> > +	return reg & priv->data->is_valid_bit;
> >  }
> >  
> >  static int armada_get_temp(struct thermal_zone_device *thermal,
> > @@ -199,7 +197,7 @@ static const struct armada_thermal_data
> > armadaxp_data = { static const struct armada_thermal_data
> > armada370_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada370_init_sensor,
> > -	.is_valid_shift = 9,
> > +	.is_valid_bit = BIT(9),
> >  	.temp_shift = 10,
> >  	.temp_mask = 0x1ff,
> >  	.coef_b = 3153000000UL,
> > @@ -210,7 +208,7 @@ static const struct armada_thermal_data
> > armada370_data = { static const struct armada_thermal_data
> > armada375_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada375_init_sensor,
> > -	.is_valid_shift = 10,
> > +	.is_valid_bit = BIT(10),
> >  	.temp_shift = 0,
> >  	.temp_mask = 0x1ff,
> >  	.coef_b = 3171900000UL,
> > @@ -221,7 +219,7 @@ static const struct armada_thermal_data
> > armada375_data = { static const struct armada_thermal_data
> > armada380_data = { .is_valid = armada_is_valid,
> >  	.init_sensor = armada380_init_sensor,
> > -	.is_valid_shift = 10,
> > +	.is_valid_bit = BIT(10),
> >  	.temp_shift = 0,
> >  	.temp_mask = 0x3ff,
> >  	.coef_b = 1172499100UL,  
> 
> baruch
> 


Best regards,
Miqu?l

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel Raynal]

Bindings were incomplete for a long time by only exposing one of the two
available control registers. To ease the migration to the full bindings
(already in use for the Armada 375 SoC), rename the pointers for
clarification. This way, it will only be needed to add another pointer
to access the other control register when the time comes.

This avoids dangerous situations where the offset 0 of the control
area can be either one register or the other depending on the bindings
used. After this change, device trees of other SoCs could be migrated to
the "full" bindings if they may benefit from features from the
unaccessible register, without any change in the driver.

Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
 1 file changed, 55 insertions(+), 31 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 26698f2d3ca7..e5b184cee79b 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -39,12 +39,21 @@
 #define A375_HW_RESETn			BIT(8)
 #define A380_HW_RESET			BIT(8)
 
+/* Legacy bindings */
+#define LEGACY_CONTROL_MEM_LEN		0x4
+
+/* Current bindings with the 2 control registers under the same memory area */
+#define LEGACY_CONTROL1_OFFSET		0x0
+#define CONTROL0_OFFSET			0x0
+#define CONTROL1_OFFSET			0x4
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
 struct armada_thermal_priv {
-	void __iomem *sensor;
-	void __iomem *control;
+	void __iomem *status;
+	void __iomem *control0;
+	void __iomem *control1;
 	struct armada_thermal_data *data;
 };
 
@@ -71,45 +80,45 @@ struct armada_thermal_data {
 static void armadaxp_init_sensor(struct platform_device *pdev,
 				 struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl_relaxed(priv->control);
+	reg = readl_relaxed(priv->control1);
 	reg |= PMU_TDC0_OTF_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reference calibration value */
 	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
 	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reset the sensor */
-	reg = readl_relaxed(priv->control);
-	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+	reg = readl_relaxed(priv->control1);
+	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
 
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Enable the sensor */
-	reg = readl_relaxed(priv->sensor);
+	reg = readl_relaxed(priv->status);
 	reg &= ~PMU_TM_DISABLE_MASK;
-	writel(reg, priv->sensor);
+	writel(reg, priv->status);
 }
 
 static void armada370_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl_relaxed(priv->control);
+	reg = readl_relaxed(priv->control1);
 	reg |= PMU_TDC0_OTF_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reference calibration value */
 	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
 	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	reg &= ~PMU_TDC0_START_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	msleep(10);
 }
@@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
 static void armada375_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl(priv->control + 4);
+	reg = readl(priv->control1);
 	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
 	reg &= ~A375_READOUT_INVERT;
 	reg &= ~A375_HW_RESETn;
 
-	writel(reg, priv->control + 4);
+	writel(reg, priv->control1);
 	msleep(20);
 
 	reg |= A375_HW_RESETn;
-	writel(reg, priv->control + 4);
+	writel(reg, priv->control1);
 	msleep(50);
 }
 
 static void armada380_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg = readl_relaxed(priv->control);
+	u32 reg = readl_relaxed(priv->control1);
 
 	/* Reset hardware once */
 	if (!(reg & A380_HW_RESET)) {
 		reg |= A380_HW_RESET;
-		writel(reg, priv->control);
+		writel(reg, priv->control1);
 		msleep(10);
 	}
 }
 
 static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
-	unsigned long reg = readl_relaxed(priv->sensor);
+	u32 reg = readl_relaxed(priv->status);
 
 	return reg & priv->data->is_valid_bit;
 }
@@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 			  int *temp)
 {
 	struct armada_thermal_priv *priv = thermal->devdata;
-	unsigned long reg;
+	u32 reg;
 	unsigned long m, b, div;
 
 	/* Valid check */
@@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 		return -EIO;
 	}
 
-	reg = readl_relaxed(priv->sensor);
+	reg = readl_relaxed(priv->status);
 	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
 
 	/* Get formula coeficients */
@@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
 
 static int armada_thermal_probe(struct platform_device *pdev)
 {
+	void __iomem *control = NULL;
 	struct thermal_zone_device *thermal;
 	const struct of_device_id *match;
 	struct armada_thermal_priv *priv;
@@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->sensor))
-		return PTR_ERR(priv->sensor);
+	priv->status = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->status))
+		return PTR_ERR(priv->status);
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	priv->control = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->control))
-		return PTR_ERR(priv->control);
+	control = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(control))
+		return PTR_ERR(control);
+
+	/*
+	 * Legacy DT bindings only described "control1" register (also referred
+	 * as "control MSB" on old documentation). New bindings cover
+	 * "control0/control LSB" and "control1/control MSB" registers within
+	 * the same resource, which is then of size 8 instead of 4.
+	 */
+	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
+		/* ->control0 unavailable in this configuration */
+		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
+	} else {
+		priv->control0 = control + CONTROL0_OFFSET;
+		priv->control1 = control + CONTROL1_OFFSET;
+	}
 
 	priv->data = (struct armada_thermal_data *)match->data;
 	priv->data->init_sensor(pdev, priv);
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel Raynal]

Bindings were incomplete for a long time by only exposing one of the two
available control registers. To ease the migration to the full bindings
(already in use for the Armada 375 SoC), rename the pointers for
clarification. This way, it will only be needed to add another pointer
to access the other control register when the time comes.

This avoids dangerous situations where the offset 0 of the control
area can be either one register or the other depending on the bindings
used. After this change, device trees of other SoCs could be migrated to
the "full" bindings if they may benefit from features from the
unaccessible register, without any change in the driver.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
 1 file changed, 55 insertions(+), 31 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 26698f2d3ca7..e5b184cee79b 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -39,12 +39,21 @@
 #define A375_HW_RESETn			BIT(8)
 #define A380_HW_RESET			BIT(8)
 
+/* Legacy bindings */
+#define LEGACY_CONTROL_MEM_LEN		0x4
+
+/* Current bindings with the 2 control registers under the same memory area */
+#define LEGACY_CONTROL1_OFFSET		0x0
+#define CONTROL0_OFFSET			0x0
+#define CONTROL1_OFFSET			0x4
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
 struct armada_thermal_priv {
-	void __iomem *sensor;
-	void __iomem *control;
+	void __iomem *status;
+	void __iomem *control0;
+	void __iomem *control1;
 	struct armada_thermal_data *data;
 };
 
@@ -71,45 +80,45 @@ struct armada_thermal_data {
 static void armadaxp_init_sensor(struct platform_device *pdev,
 				 struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl_relaxed(priv->control);
+	reg = readl_relaxed(priv->control1);
 	reg |= PMU_TDC0_OTF_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reference calibration value */
 	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
 	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reset the sensor */
-	reg = readl_relaxed(priv->control);
-	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+	reg = readl_relaxed(priv->control1);
+	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
 
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Enable the sensor */
-	reg = readl_relaxed(priv->sensor);
+	reg = readl_relaxed(priv->status);
 	reg &= ~PMU_TM_DISABLE_MASK;
-	writel(reg, priv->sensor);
+	writel(reg, priv->status);
 }
 
 static void armada370_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl_relaxed(priv->control);
+	reg = readl_relaxed(priv->control1);
 	reg |= PMU_TDC0_OTF_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	/* Reference calibration value */
 	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
 	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	reg &= ~PMU_TDC0_START_CAL_MASK;
-	writel(reg, priv->control);
+	writel(reg, priv->control1);
 
 	msleep(10);
 }
@@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
 static void armada375_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg;
+	u32 reg;
 
-	reg = readl(priv->control + 4);
+	reg = readl(priv->control1);
 	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
 	reg &= ~A375_READOUT_INVERT;
 	reg &= ~A375_HW_RESETn;
 
-	writel(reg, priv->control + 4);
+	writel(reg, priv->control1);
 	msleep(20);
 
 	reg |= A375_HW_RESETn;
-	writel(reg, priv->control + 4);
+	writel(reg, priv->control1);
 	msleep(50);
 }
 
 static void armada380_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
-	unsigned long reg = readl_relaxed(priv->control);
+	u32 reg = readl_relaxed(priv->control1);
 
 	/* Reset hardware once */
 	if (!(reg & A380_HW_RESET)) {
 		reg |= A380_HW_RESET;
-		writel(reg, priv->control);
+		writel(reg, priv->control1);
 		msleep(10);
 	}
 }
 
 static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
-	unsigned long reg = readl_relaxed(priv->sensor);
+	u32 reg = readl_relaxed(priv->status);
 
 	return reg & priv->data->is_valid_bit;
 }
@@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 			  int *temp)
 {
 	struct armada_thermal_priv *priv = thermal->devdata;
-	unsigned long reg;
+	u32 reg;
 	unsigned long m, b, div;
 
 	/* Valid check */
@@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 		return -EIO;
 	}
 
-	reg = readl_relaxed(priv->sensor);
+	reg = readl_relaxed(priv->status);
 	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
 
 	/* Get formula coeficients */
@@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
 
 static int armada_thermal_probe(struct platform_device *pdev)
 {
+	void __iomem *control = NULL;
 	struct thermal_zone_device *thermal;
 	const struct of_device_id *match;
 	struct armada_thermal_priv *priv;
@@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->sensor))
-		return PTR_ERR(priv->sensor);
+	priv->status = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->status))
+		return PTR_ERR(priv->status);
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	priv->control = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->control))
-		return PTR_ERR(priv->control);
+	control = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(control))
+		return PTR_ERR(control);
+
+	/*
+	 * Legacy DT bindings only described "control1" register (also referred
+	 * as "control MSB" on old documentation). New bindings cover
+	 * "control0/control LSB" and "control1/control MSB" registers within
+	 * the same resource, which is then of size 8 instead of 4.
+	 */
+	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
+		/* ->control0 unavailable in this configuration */
+		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
+	} else {
+		priv->control0 = control + CONTROL0_OFFSET;
+		priv->control1 = control + CONTROL1_OFFSET;
+	}
 
 	priv->data = (struct armada_thermal_data *)match->data;
 	priv->data->init_sensor(pdev, priv);
-- 
2.11.0

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miquèl,

On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
> 
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
>  1 file changed, 55 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
>  #define A375_HW_RESETn			BIT(8)
>  #define A380_HW_RESET			BIT(8)
>  
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN		0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET		0x0
> +#define CONTROL0_OFFSET			0x0
> +#define CONTROL1_OFFSET			0x4
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
>  struct armada_thermal_priv {
> -	void __iomem *sensor;
> -	void __iomem *control;
> +	void __iomem *status;
> +	void __iomem *control0;
> +	void __iomem *control1;

The 'status' -> 'sensor' rename is not mentioned in the commit log. I'd say it 
is a matter for a separate patch.

Otherwise, good cleanup.

baruch

>  	struct armada_thermal_data *data;
>  };
>  
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
>  static void armadaxp_init_sensor(struct platform_device *pdev,
>  				 struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reset the sensor */
> -	reg = readl_relaxed(priv->control);
> -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +	reg = readl_relaxed(priv->control1);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>  
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Enable the sensor */
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg &= ~PMU_TM_DISABLE_MASK;
> -	writel(reg, priv->sensor);
> +	writel(reg, priv->status);
>  }
>  
>  static void armada370_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	msleep(10);
>  }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  static void armada375_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl(priv->control + 4);
> +	reg = readl(priv->control1);
>  	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
>  	reg &= ~A375_READOUT_INVERT;
>  	reg &= ~A375_HW_RESETn;
>  
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->control);
> +	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
> -		writel(reg, priv->control);
> +		writel(reg, priv->control1);
>  		msleep(10);
>  	}
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->sensor);
> +	u32 reg = readl_relaxed(priv->status);
>  
>  	return reg & priv->data->is_valid_bit;
>  }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  			  int *temp)
>  {
>  	struct armada_thermal_priv *priv = thermal->devdata;
> -	unsigned long reg;
> +	u32 reg;
>  	unsigned long m, b, div;
>  
>  	/* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  		return -EIO;
>  	}
>  
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>  
>  	/* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>  
>  static int armada_thermal_probe(struct platform_device *pdev)
>  {
> +	void __iomem *control = NULL;
>  	struct thermal_zone_device *thermal;
>  	const struct of_device_id *match;
>  	struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->sensor))
> -		return PTR_ERR(priv->sensor);
> +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->status))
> +		return PTR_ERR(priv->status);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->control))
> -		return PTR_ERR(priv->control);
> +	control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(control))
> +		return PTR_ERR(control);
> +
> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}
>  
>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miqu?l,

On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
> 
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
>  1 file changed, 55 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
>  #define A375_HW_RESETn			BIT(8)
>  #define A380_HW_RESET			BIT(8)
>  
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN		0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET		0x0
> +#define CONTROL0_OFFSET			0x0
> +#define CONTROL1_OFFSET			0x4
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
>  struct armada_thermal_priv {
> -	void __iomem *sensor;
> -	void __iomem *control;
> +	void __iomem *status;
> +	void __iomem *control0;
> +	void __iomem *control1;

The 'status' -> 'sensor' rename is not mentioned in the commit log. I'd say it 
is a matter for a separate patch.

Otherwise, good cleanup.

baruch

>  	struct armada_thermal_data *data;
>  };
>  
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
>  static void armadaxp_init_sensor(struct platform_device *pdev,
>  				 struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reset the sensor */
> -	reg = readl_relaxed(priv->control);
> -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +	reg = readl_relaxed(priv->control1);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>  
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Enable the sensor */
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg &= ~PMU_TM_DISABLE_MASK;
> -	writel(reg, priv->sensor);
> +	writel(reg, priv->status);
>  }
>  
>  static void armada370_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	msleep(10);
>  }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  static void armada375_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl(priv->control + 4);
> +	reg = readl(priv->control1);
>  	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
>  	reg &= ~A375_READOUT_INVERT;
>  	reg &= ~A375_HW_RESETn;
>  
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->control);
> +	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
> -		writel(reg, priv->control);
> +		writel(reg, priv->control1);
>  		msleep(10);
>  	}
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->sensor);
> +	u32 reg = readl_relaxed(priv->status);
>  
>  	return reg & priv->data->is_valid_bit;
>  }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  			  int *temp)
>  {
>  	struct armada_thermal_priv *priv = thermal->devdata;
> -	unsigned long reg;
> +	u32 reg;
>  	unsigned long m, b, div;
>  
>  	/* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  		return -EIO;
>  	}
>  
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>  
>  	/* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>  
>  static int armada_thermal_probe(struct platform_device *pdev)
>  {
> +	void __iomem *control = NULL;
>  	struct thermal_zone_device *thermal;
>  	const struct of_device_id *match;
>  	struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->sensor))
> -		return PTR_ERR(priv->sensor);
> +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->status))
> +		return PTR_ERR(priv->status);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->control))
> -		return PTR_ERR(priv->control);
> +	control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(control))
> +		return PTR_ERR(control);
> +
> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}
>  
>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel RAYNAL]

On Fri, 15 Dec 2017 10:56:22 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:

> Hi Miquèl,
> 
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of
> > the two available control registers. To ease the migration to the
> > full bindings (already in use for the Armada 375 SoC), rename the
> > pointers for clarification. This way, it will only be needed to add
> > another pointer to access the other control register when the time
> > comes.
> > 
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the
> > bindings used. After this change, device trees of other SoCs could
> > be migrated to the "full" bindings if they may benefit from
> > features from the unaccessible register, without any change in the
> > driver.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> >  drivers/thermal/armada_thermal.c | 86
> > +++++++++++++++++++++++++--------------- 1 file changed, 55
> > insertions(+), 31 deletions(-)
> > 
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 26698f2d3ca7..e5b184cee79b
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -39,12 +39,21 @@
> >  #define A375_HW_RESETn			BIT(8)
> >  #define A380_HW_RESET			BIT(8)
> >  
> > +/* Legacy bindings */
> > +#define LEGACY_CONTROL_MEM_LEN		0x4
> > +
> > +/* Current bindings with the 2 control registers under the same
> > memory area */ +#define LEGACY_CONTROL1_OFFSET		0x0
> > +#define CONTROL0_OFFSET			0x0
> > +#define CONTROL1_OFFSET			0x4
> > +
> >  struct armada_thermal_data;
> >  
> >  /* Marvell EBU Thermal Sensor Dev Structure */
> >  struct armada_thermal_priv {
> > -	void __iomem *sensor;
> > -	void __iomem *control;
> > +	void __iomem *status;
> > +	void __iomem *control0;
> > +	void __iomem *control1;  
> 
> The 'status' -> 'sensor' rename is not mentioned in the commit log.
> I'd say it is a matter for a separate patch.

Sure, I'll split.

> 
> Otherwise, good cleanup.

Thanks!

Miquèl

> 
> baruch
> 
> >  	struct armada_thermal_data *data;
> >  };
> >  
> > @@ -71,45 +80,45 @@ struct armada_thermal_data {
> >  static void armadaxp_init_sensor(struct platform_device *pdev,
> >  				 struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl_relaxed(priv->control);
> > +	reg = readl_relaxed(priv->control1);
> >  	reg |= PMU_TDC0_OTF_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reference calibration value */
> >  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> >  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reset the sensor */
> > -	reg = readl_relaxed(priv->control);
> > -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> > +	reg = readl_relaxed(priv->control1);
> > +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
> >  
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Enable the sensor */
> > -	reg = readl_relaxed(priv->sensor);
> > +	reg = readl_relaxed(priv->status);
> >  	reg &= ~PMU_TM_DISABLE_MASK;
> > -	writel(reg, priv->sensor);
> > +	writel(reg, priv->status);
> >  }
> >  
> >  static void armada370_init_sensor(struct platform_device *pdev,
> >  				  struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl_relaxed(priv->control);
> > +	reg = readl_relaxed(priv->control1);
> >  	reg |= PMU_TDC0_OTF_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reference calibration value */
> >  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> >  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	reg &= ~PMU_TDC0_START_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	msleep(10);
> >  }
> > @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct
> > platform_device *pdev, static void armada375_init_sensor(struct
> > platform_device *pdev, struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl(priv->control + 4);
> > +	reg = readl(priv->control1);
> >  	reg &= ~(A375_UNIT_CONTROL_MASK <<
> > A375_UNIT_CONTROL_SHIFT); reg &= ~A375_READOUT_INVERT;
> >  	reg &= ~A375_HW_RESETn;
> >  
> > -	writel(reg, priv->control + 4);
> > +	writel(reg, priv->control1);
> >  	msleep(20);
> >  
> >  	reg |= A375_HW_RESETn;
> > -	writel(reg, priv->control + 4);
> > +	writel(reg, priv->control1);
> >  	msleep(50);
> >  }
> >  
> >  static void armada380_init_sensor(struct platform_device *pdev,
> >  				  struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg = readl_relaxed(priv->control);
> > +	u32 reg = readl_relaxed(priv->control1);
> >  
> >  	/* Reset hardware once */
> >  	if (!(reg & A380_HW_RESET)) {
> >  		reg |= A380_HW_RESET;
> > -		writel(reg, priv->control);
> > +		writel(reg, priv->control1);
> >  		msleep(10);
> >  	}
> >  }
> >  
> >  static bool armada_is_valid(struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg = readl_relaxed(priv->sensor);
> > +	u32 reg = readl_relaxed(priv->status);
> >  
> >  	return reg & priv->data->is_valid_bit;
> >  }
> > @@ -156,7 +165,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> >  {
> >  	struct armada_thermal_priv *priv = thermal->devdata;
> > -	unsigned long reg;
> > +	u32 reg;
> >  	unsigned long m, b, div;
> >  
> >  	/* Valid check */
> > @@ -166,7 +175,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, return -EIO;
> >  	}
> >  
> > -	reg = readl_relaxed(priv->sensor);
> > +	reg = readl_relaxed(priv->status);
> >  	reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask; 
> >  	/* Get formula coeficients */
> > @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of,
> > armada_thermal_id_table); 
> >  static int armada_thermal_probe(struct platform_device *pdev)
> >  {
> > +	void __iomem *control = NULL;
> >  	struct thermal_zone_device *thermal;
> >  	const struct of_device_id *match;
> >  	struct armada_thermal_priv *priv;
> > @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) return -ENOMEM;
> >  
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> > -	if (IS_ERR(priv->sensor))
> > -		return PTR_ERR(priv->sensor);
> > +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv->status))
> > +		return PTR_ERR(priv->status);
> >  
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> > -	if (IS_ERR(priv->control))
> > -		return PTR_ERR(priv->control);
> > +	control = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(control))
> > +		return PTR_ERR(control);
> > +
> > +	/*
> > +	 * Legacy DT bindings only described "control1" register
> > (also referred
> > +	 * as "control MSB" on old documentation). New bindings
> > cover
> > +	 * "control0/control LSB" and "control1/control MSB"
> > registers within
> > +	 * the same resource, which is then of size 8 instead of 4.
> > +	 */
> > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > +		/* ->control0 unavailable in this configuration */
> > +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > +	} else {
> > +		priv->control0 = control + CONTROL0_OFFSET;
> > +		priv->control1 = control + CONTROL1_OFFSET;
> > +	}
> >  
> >  	priv->data = (struct armada_thermal_data *)match->data;
> >  	priv->data->init_sensor(pdev, priv);  
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel RAYNAL]

On Fri, 15 Dec 2017 10:56:22 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miqu?l,
> 
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of
> > the two available control registers. To ease the migration to the
> > full bindings (already in use for the Armada 375 SoC), rename the
> > pointers for clarification. This way, it will only be needed to add
> > another pointer to access the other control register when the time
> > comes.
> > 
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the
> > bindings used. After this change, device trees of other SoCs could
> > be migrated to the "full" bindings if they may benefit from
> > features from the unaccessible register, without any change in the
> > driver.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  drivers/thermal/armada_thermal.c | 86
> > +++++++++++++++++++++++++--------------- 1 file changed, 55
> > insertions(+), 31 deletions(-)
> > 
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 26698f2d3ca7..e5b184cee79b
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -39,12 +39,21 @@
> >  #define A375_HW_RESETn			BIT(8)
> >  #define A380_HW_RESET			BIT(8)
> >  
> > +/* Legacy bindings */
> > +#define LEGACY_CONTROL_MEM_LEN		0x4
> > +
> > +/* Current bindings with the 2 control registers under the same
> > memory area */ +#define LEGACY_CONTROL1_OFFSET		0x0
> > +#define CONTROL0_OFFSET			0x0
> > +#define CONTROL1_OFFSET			0x4
> > +
> >  struct armada_thermal_data;
> >  
> >  /* Marvell EBU Thermal Sensor Dev Structure */
> >  struct armada_thermal_priv {
> > -	void __iomem *sensor;
> > -	void __iomem *control;
> > +	void __iomem *status;
> > +	void __iomem *control0;
> > +	void __iomem *control1;  
> 
> The 'status' -> 'sensor' rename is not mentioned in the commit log.
> I'd say it is a matter for a separate patch.

Sure, I'll split.

> 
> Otherwise, good cleanup.

Thanks!

Miqu?l

> 
> baruch
> 
> >  	struct armada_thermal_data *data;
> >  };
> >  
> > @@ -71,45 +80,45 @@ struct armada_thermal_data {
> >  static void armadaxp_init_sensor(struct platform_device *pdev,
> >  				 struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl_relaxed(priv->control);
> > +	reg = readl_relaxed(priv->control1);
> >  	reg |= PMU_TDC0_OTF_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reference calibration value */
> >  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> >  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reset the sensor */
> > -	reg = readl_relaxed(priv->control);
> > -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> > +	reg = readl_relaxed(priv->control1);
> > +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
> >  
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Enable the sensor */
> > -	reg = readl_relaxed(priv->sensor);
> > +	reg = readl_relaxed(priv->status);
> >  	reg &= ~PMU_TM_DISABLE_MASK;
> > -	writel(reg, priv->sensor);
> > +	writel(reg, priv->status);
> >  }
> >  
> >  static void armada370_init_sensor(struct platform_device *pdev,
> >  				  struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl_relaxed(priv->control);
> > +	reg = readl_relaxed(priv->control1);
> >  	reg |= PMU_TDC0_OTF_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	/* Reference calibration value */
> >  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> >  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	reg &= ~PMU_TDC0_START_CAL_MASK;
> > -	writel(reg, priv->control);
> > +	writel(reg, priv->control1);
> >  
> >  	msleep(10);
> >  }
> > @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct
> > platform_device *pdev, static void armada375_init_sensor(struct
> > platform_device *pdev, struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg;
> > +	u32 reg;
> >  
> > -	reg = readl(priv->control + 4);
> > +	reg = readl(priv->control1);
> >  	reg &= ~(A375_UNIT_CONTROL_MASK <<
> > A375_UNIT_CONTROL_SHIFT); reg &= ~A375_READOUT_INVERT;
> >  	reg &= ~A375_HW_RESETn;
> >  
> > -	writel(reg, priv->control + 4);
> > +	writel(reg, priv->control1);
> >  	msleep(20);
> >  
> >  	reg |= A375_HW_RESETn;
> > -	writel(reg, priv->control + 4);
> > +	writel(reg, priv->control1);
> >  	msleep(50);
> >  }
> >  
> >  static void armada380_init_sensor(struct platform_device *pdev,
> >  				  struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg = readl_relaxed(priv->control);
> > +	u32 reg = readl_relaxed(priv->control1);
> >  
> >  	/* Reset hardware once */
> >  	if (!(reg & A380_HW_RESET)) {
> >  		reg |= A380_HW_RESET;
> > -		writel(reg, priv->control);
> > +		writel(reg, priv->control1);
> >  		msleep(10);
> >  	}
> >  }
> >  
> >  static bool armada_is_valid(struct armada_thermal_priv *priv)
> >  {
> > -	unsigned long reg = readl_relaxed(priv->sensor);
> > +	u32 reg = readl_relaxed(priv->status);
> >  
> >  	return reg & priv->data->is_valid_bit;
> >  }
> > @@ -156,7 +165,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> >  {
> >  	struct armada_thermal_priv *priv = thermal->devdata;
> > -	unsigned long reg;
> > +	u32 reg;
> >  	unsigned long m, b, div;
> >  
> >  	/* Valid check */
> > @@ -166,7 +175,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, return -EIO;
> >  	}
> >  
> > -	reg = readl_relaxed(priv->sensor);
> > +	reg = readl_relaxed(priv->status);
> >  	reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask; 
> >  	/* Get formula coeficients */
> > @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of,
> > armada_thermal_id_table); 
> >  static int armada_thermal_probe(struct platform_device *pdev)
> >  {
> > +	void __iomem *control = NULL;
> >  	struct thermal_zone_device *thermal;
> >  	const struct of_device_id *match;
> >  	struct armada_thermal_priv *priv;
> > @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) return -ENOMEM;
> >  
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> > -	if (IS_ERR(priv->sensor))
> > -		return PTR_ERR(priv->sensor);
> > +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(priv->status))
> > +		return PTR_ERR(priv->status);
> >  
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> > -	if (IS_ERR(priv->control))
> > -		return PTR_ERR(priv->control);
> > +	control = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(control))
> > +		return PTR_ERR(control);
> > +
> > +	/*
> > +	 * Legacy DT bindings only described "control1" register
> > (also referred
> > +	 * as "control MSB" on old documentation). New bindings
> > cover
> > +	 * "control0/control LSB" and "control1/control MSB"
> > registers within
> > +	 * the same resource, which is then of size 8 instead of 4.
> > +	 */
> > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > +		/* ->control0 unavailable in this configuration */
> > +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > +	} else {
> > +		priv->control0 = control + CONTROL0_OFFSET;
> > +		priv->control1 = control + CONTROL1_OFFSET;
> > +	}
> >  
> >  	priv->data = (struct armada_thermal_data *)match->data;
> >  	priv->data->init_sensor(pdev, priv);  
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
>  1 file changed, 55 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
>  #define A375_HW_RESETn			BIT(8)
>  #define A380_HW_RESET			BIT(8)
>  
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN		0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET		0x0
> +#define CONTROL0_OFFSET			0x0
> +#define CONTROL1_OFFSET			0x4
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
>  struct armada_thermal_priv {
> -	void __iomem *sensor;
> -	void __iomem *control;
> +	void __iomem *status;
> +	void __iomem *control0;
> +	void __iomem *control1;
>  	struct armada_thermal_data *data;
>  };
>  
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
>  static void armadaxp_init_sensor(struct platform_device *pdev,
>  				 struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reset the sensor */
> -	reg = readl_relaxed(priv->control);
> -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +	reg = readl_relaxed(priv->control1);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>  
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Enable the sensor */
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg &= ~PMU_TM_DISABLE_MASK;
> -	writel(reg, priv->sensor);
> +	writel(reg, priv->status);
>  }
>  
>  static void armada370_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	msleep(10);
>  }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  static void armada375_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl(priv->control + 4);
> +	reg = readl(priv->control1);
>  	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
>  	reg &= ~A375_READOUT_INVERT;
>  	reg &= ~A375_HW_RESETn;
>  
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->control);
> +	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
> -		writel(reg, priv->control);
> +		writel(reg, priv->control1);
>  		msleep(10);
>  	}
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->sensor);
> +	u32 reg = readl_relaxed(priv->status);
>  
>  	return reg & priv->data->is_valid_bit;
>  }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  			  int *temp)
>  {
>  	struct armada_thermal_priv *priv = thermal->devdata;
> -	unsigned long reg;
> +	u32 reg;
>  	unsigned long m, b, div;
>  
>  	/* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  		return -EIO;
>  	}
>  
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>  
>  	/* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>  
>  static int armada_thermal_probe(struct platform_device *pdev)
>  {
> +	void __iomem *control = NULL;
>  	struct thermal_zone_device *thermal;
>  	const struct of_device_id *match;
>  	struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->sensor))
> -		return PTR_ERR(priv->sensor);
> +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->status))
> +		return PTR_ERR(priv->status);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->control))
> -		return PTR_ERR(priv->control);
> +	control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(control))
> +		return PTR_ERR(control);
> +
> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}
>  
>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory
> ---
>  drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
>  1 file changed, 55 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
>  #define A375_HW_RESETn			BIT(8)
>  #define A380_HW_RESET			BIT(8)
>  
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN		0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET		0x0
> +#define CONTROL0_OFFSET			0x0
> +#define CONTROL1_OFFSET			0x4
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
>  struct armada_thermal_priv {
> -	void __iomem *sensor;
> -	void __iomem *control;
> +	void __iomem *status;
> +	void __iomem *control0;
> +	void __iomem *control1;
>  	struct armada_thermal_data *data;
>  };
>  
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
>  static void armadaxp_init_sensor(struct platform_device *pdev,
>  				 struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reset the sensor */
> -	reg = readl_relaxed(priv->control);
> -	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> +	reg = readl_relaxed(priv->control1);
> +	writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>  
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Enable the sensor */
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg &= ~PMU_TM_DISABLE_MASK;
> -	writel(reg, priv->sensor);
> +	writel(reg, priv->status);
>  }
>  
>  static void armada370_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl_relaxed(priv->control);
> +	reg = readl_relaxed(priv->control1);
>  	reg |= PMU_TDC0_OTF_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	/* Reference calibration value */
>  	reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
>  	reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	reg &= ~PMU_TDC0_START_CAL_MASK;
> -	writel(reg, priv->control);
> +	writel(reg, priv->control1);
>  
>  	msleep(10);
>  }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
>  static void armada375_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg;
> +	u32 reg;
>  
> -	reg = readl(priv->control + 4);
> +	reg = readl(priv->control1);
>  	reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
>  	reg &= ~A375_READOUT_INVERT;
>  	reg &= ~A375_HW_RESETn;
>  
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(20);
>  
>  	reg |= A375_HW_RESETn;
> -	writel(reg, priv->control + 4);
> +	writel(reg, priv->control1);
>  	msleep(50);
>  }
>  
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->control);
> +	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
>  	if (!(reg & A380_HW_RESET)) {
>  		reg |= A380_HW_RESET;
> -		writel(reg, priv->control);
> +		writel(reg, priv->control1);
>  		msleep(10);
>  	}
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
> -	unsigned long reg = readl_relaxed(priv->sensor);
> +	u32 reg = readl_relaxed(priv->status);
>  
>  	return reg & priv->data->is_valid_bit;
>  }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  			  int *temp)
>  {
>  	struct armada_thermal_priv *priv = thermal->devdata;
> -	unsigned long reg;
> +	u32 reg;
>  	unsigned long m, b, div;
>  
>  	/* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  		return -EIO;
>  	}
>  
> -	reg = readl_relaxed(priv->sensor);
> +	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>  
>  	/* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>  
>  static int armada_thermal_probe(struct platform_device *pdev)
>  {
> +	void __iomem *control = NULL;
>  	struct thermal_zone_device *thermal;
>  	const struct of_device_id *match;
>  	struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->sensor))
> -		return PTR_ERR(priv->sensor);
> +	priv->status = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->status))
> +		return PTR_ERR(priv->status);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -	priv->control = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(priv->control))
> -		return PTR_ERR(priv->control);
> +	control = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(control))
> +		return PTR_ERR(control);
> +
> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}
>  
>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miquèl,

On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
> 
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---

[...]

> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}

I think we need to add a check here that the control registers area size 
matches the expected value given the compatible string. In case of mismatch 
probe should fail.

>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miqu?l,

On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
> 
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---

[...]

> +	/*
> +	 * Legacy DT bindings only described "control1" register (also referred
> +	 * as "control MSB" on old documentation). New bindings cover
> +	 * "control0/control LSB" and "control1/control MSB" registers within
> +	 * the same resource, which is then of size 8 instead of 4.
> +	 */
> +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> +		/* ->control0 unavailable in this configuration */
> +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> +	} else {
> +		priv->control0 = control + CONTROL0_OFFSET;
> +		priv->control1 = control + CONTROL1_OFFSET;
> +	}

I think we need to add a check here that the control registers area size 
matches the expected value given the compatible string. In case of mismatch 
probe should fail.

>  	priv->data = (struct armada_thermal_data *)match->data;
>  	priv->data->init_sensor(pdev, priv);

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miquèl,

On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of the two
> > available control registers. To ease the migration to the full bindings
> > (already in use for the Armada 375 SoC), rename the pointers for
> > clarification. This way, it will only be needed to add another pointer
> > to access the other control register when the time comes.
> > 
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the bindings
> > used. After this change, device trees of other SoCs could be migrated to
> > the "full" bindings if they may benefit from features from the
> > unaccessible register, without any change in the driver.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> 
> [...]
> 
> > +	/*
> > +	 * Legacy DT bindings only described "control1" register (also referred
> > +	 * as "control MSB" on old documentation). New bindings cover
> > +	 * "control0/control LSB" and "control1/control MSB" registers within
> > +	 * the same resource, which is then of size 8 instead of 4.
> > +	 */
> > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > +		/* ->control0 unavailable in this configuration */
> > +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > +	} else {
> > +		priv->control0 = control + CONTROL0_OFFSET;
> > +		priv->control1 = control + CONTROL1_OFFSET;
> > +	}
> 
> I think we need to add a check here that the control registers area size 
> matches the expected value given the compatible string. In case of mismatch 
> probe should fail.

One more thing. You should probably use resource_size() instead of open coding 
it. resource_size() does "res->end - res->start + 1". Are you sure your code 
is correct?

> >  	priv->data = (struct armada_thermal_data *)match->data;
> >  	priv->data->init_sensor(pdev, priv);

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Baruch Siach]

Hi Miqu?l,

On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of the two
> > available control registers. To ease the migration to the full bindings
> > (already in use for the Armada 375 SoC), rename the pointers for
> > clarification. This way, it will only be needed to add another pointer
> > to access the other control register when the time comes.
> > 
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the bindings
> > used. After this change, device trees of other SoCs could be migrated to
> > the "full" bindings if they may benefit from features from the
> > unaccessible register, without any change in the driver.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> 
> [...]
> 
> > +	/*
> > +	 * Legacy DT bindings only described "control1" register (also referred
> > +	 * as "control MSB" on old documentation). New bindings cover
> > +	 * "control0/control LSB" and "control1/control MSB" registers within
> > +	 * the same resource, which is then of size 8 instead of 4.
> > +	 */
> > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > +		/* ->control0 unavailable in this configuration */
> > +		priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > +	} else {
> > +		priv->control0 = control + CONTROL0_OFFSET;
> > +		priv->control1 = control + CONTROL1_OFFSET;
> > +	}
> 
> I think we need to add a check here that the control registers area size 
> matches the expected value given the compatible string. In case of mismatch 
> probe should fail.

One more thing. You should probably use resource_size() instead of open coding 
it. resource_size() does "res->end - res->start + 1". Are you sure your code 
is correct?

> >  	priv->data = (struct armada_thermal_data *)match->data;
> >  	priv->data->init_sensor(pdev, priv);

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel RAYNAL]

On Mon, 18 Dec 2017 00:02:35 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:

> Hi Miquèl,
> 
> On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> > On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:  
> > > Bindings were incomplete for a long time by only exposing one of
> > > the two available control registers. To ease the migration to the
> > > full bindings (already in use for the Armada 375 SoC), rename the
> > > pointers for clarification. This way, it will only be needed to
> > > add another pointer to access the other control register when the
> > > time comes.
> > > 
> > > This avoids dangerous situations where the offset 0 of the control
> > > area can be either one register or the other depending on the
> > > bindings used. After this change, device trees of other SoCs
> > > could be migrated to the "full" bindings if they may benefit from
> > > features from the unaccessible register, without any change in
> > > the driver.
> > > 
> > > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > ---  
> > 
> > [...]
> >   
> > > +	/*
> > > +	 * Legacy DT bindings only described "control1" register
> > > (also referred
> > > +	 * as "control MSB" on old documentation). New bindings
> > > cover
> > > +	 * "control0/control LSB" and "control1/control MSB"
> > > registers within
> > > +	 * the same resource, which is then of size 8 instead of
> > > 4.
> > > +	 */
> > > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > > +		/* ->control0 unavailable in this configuration
> > > */
> > > +		priv->control1 = control +
> > > LEGACY_CONTROL1_OFFSET;
> > > +	} else {
> > > +		priv->control0 = control + CONTROL0_OFFSET;
> > > +		priv->control1 = control + CONTROL1_OFFSET;
> > > +	}  
> > 
> > I think we need to add a check here that the control registers area
> > size matches the expected value given the compatible string. In
> > case of mismatch probe should fail.  

Ok I will check here for the bindings used.

Still, in the a380_init() I will have to check if control0 is
valid or not because this function should handle both bindings.

> 
> One more thing. You should probably use resource_size() instead of
> open coding it. resource_size() does "res->end - res->start + 1". Are
> you sure your code is correct?

It is not regarding the implementation of resource_size() (which I'm
gonna use).

> 
> > >  	priv->data = (struct armada_thermal_data *)match->data;
> > >  	priv->data->init_sensor(pdev, priv);  
> 
> baruch
> 

Thank you,
Miquèl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/11] thermal: armada: Rationalize register accesses

[Miquel RAYNAL]

On Mon, 18 Dec 2017 00:02:35 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miqu?l,
> 
> On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> > On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:  
> > > Bindings were incomplete for a long time by only exposing one of
> > > the two available control registers. To ease the migration to the
> > > full bindings (already in use for the Armada 375 SoC), rename the
> > > pointers for clarification. This way, it will only be needed to
> > > add another pointer to access the other control register when the
> > > time comes.
> > > 
> > > This avoids dangerous situations where the offset 0 of the control
> > > area can be either one register or the other depending on the
> > > bindings used. After this change, device trees of other SoCs
> > > could be migrated to the "full" bindings if they may benefit from
> > > features from the unaccessible register, without any change in
> > > the driver.
> > > 
> > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > ---  
> > 
> > [...]
> >   
> > > +	/*
> > > +	 * Legacy DT bindings only described "control1" register
> > > (also referred
> > > +	 * as "control MSB" on old documentation). New bindings
> > > cover
> > > +	 * "control0/control LSB" and "control1/control MSB"
> > > registers within
> > > +	 * the same resource, which is then of size 8 instead of
> > > 4.
> > > +	 */
> > > +	if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > > +		/* ->control0 unavailable in this configuration
> > > */
> > > +		priv->control1 = control +
> > > LEGACY_CONTROL1_OFFSET;
> > > +	} else {
> > > +		priv->control0 = control + CONTROL0_OFFSET;
> > > +		priv->control1 = control + CONTROL1_OFFSET;
> > > +	}  
> > 
> > I think we need to add a check here that the control registers area
> > size matches the expected value given the compatible string. In
> > case of mismatch probe should fail.  

Ok I will check here for the bindings used.

Still, in the a380_init() I will have to check if control0 is
valid or not because this function should handle both bindings.

> 
> One more thing. You should probably use resource_size() instead of
> open coding it. resource_size() does "res->end - res->start + 1". Are
> you sure your code is correct?

It is not regarding the implementation of resource_size() (which I'm
gonna use).

> 
> > >  	priv->data = (struct armada_thermal_data *)match->data;
> > >  	priv->data->init_sensor(pdev, priv);  
> 
> baruch
> 

Thank you,
Miqu?l

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel Raynal]

From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>

The AP806 component is integrated in the Armada 8k and 7k lines of
processors.

The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() to handle signed values.

Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/thermal/armada_thermal.c | 51 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index e5b184cee79b..279d01937bb8 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -47,6 +47,11 @@
 #define CONTROL0_OFFSET			0x0
 #define CONTROL1_OFFSET			0x4
 
+/* TSEN refers to the temperature sensors within the AP */
+#define CONTROL0_TSEN_START		BIT(0)
+#define CONTROL0_TSEN_RESET		BIT(1)
+#define CONTROL0_TSEN_ENABLE		BIT(2)
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -70,6 +75,7 @@ struct armada_thermal_data {
 	unsigned long coef_m;
 	unsigned long coef_div;
 	bool inverted;
+	bool signed_sample;
 
 	/* Register shift and mask to access the sensor temperature */
 	unsigned int temp_shift;
@@ -154,6 +160,24 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	}
 }
 
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+				     struct armada_thermal_priv *priv)
+{
+	u32 reg;
+
+	if (!priv->control0) {
+		dev_err(&pdev->dev,
+			"Cannot access to control0 (control LSB) register\n");
+		return;
+	}
+
+	reg = readl_relaxed(priv->control0);
+	reg &= ~CONTROL0_TSEN_RESET;
+	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
+	writel(reg, priv->control0);
+	msleep(10);
+}
+
 static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
 	u32 reg = readl_relaxed(priv->status);
@@ -167,6 +191,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 	struct armada_thermal_priv *priv = thermal->devdata;
 	u32 reg;
 	unsigned long m, b, div;
+	int sample;
 
 	/* Valid check */
 	if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -177,6 +202,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 
 	reg = readl_relaxed(priv->status);
 	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+	if (priv->data->signed_sample)
+		/* The most significant bit is the sign bit */
+		sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+	else
+		sample = reg;
 
 	/* Get formula coeficients */
 	b = priv->data->coef_b;
@@ -184,9 +214,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 	div = priv->data->coef_div;
 
 	if (priv->data->inverted)
-		*temp = ((m * reg) - b) / div;
+		*temp = ((m * sample) - b) / div;
 	else
-		*temp = (b - (m * reg)) / div;
+		*temp = (b - (m * sample)) / div;
 	return 0;
 }
 
@@ -237,6 +267,19 @@ static const struct armada_thermal_data armada380_data = {
 	.inverted = true,
 };
 
+static const struct armada_thermal_data armada_ap806_data = {
+	.is_valid = armada_is_valid,
+	.init_sensor = armada_ap806_init_sensor,
+	.is_valid_bit = BIT(16),
+	.temp_shift = 0,
+	.temp_mask = 0x3ff,
+	.coef_b = -150000,
+	.coef_m = 423UL,
+	.coef_div = 1,
+	.inverted = true,
+	.signed_sample = true,
+};
+
 static const struct of_device_id armada_thermal_id_table[] = {
 	{
 		.compatible = "marvell,armadaxp-thermal",
@@ -255,6 +298,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
 		.data       = &armada380_data,
 	},
 	{
+		.compatible = "marvell,armada-ap806-thermal",
+		.data       = &armada_ap806_data,
+	},
+	{
 		/* sentinel */
 	},
 };
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

The AP806 component is integrated in the Armada 8k and 7k lines of
processors.

The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() to handle signed values.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 51 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index e5b184cee79b..279d01937bb8 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -47,6 +47,11 @@
 #define CONTROL0_OFFSET			0x0
 #define CONTROL1_OFFSET			0x4
 
+/* TSEN refers to the temperature sensors within the AP */
+#define CONTROL0_TSEN_START		BIT(0)
+#define CONTROL0_TSEN_RESET		BIT(1)
+#define CONTROL0_TSEN_ENABLE		BIT(2)
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -70,6 +75,7 @@ struct armada_thermal_data {
 	unsigned long coef_m;
 	unsigned long coef_div;
 	bool inverted;
+	bool signed_sample;
 
 	/* Register shift and mask to access the sensor temperature */
 	unsigned int temp_shift;
@@ -154,6 +160,24 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	}
 }
 
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+				     struct armada_thermal_priv *priv)
+{
+	u32 reg;
+
+	if (!priv->control0) {
+		dev_err(&pdev->dev,
+			"Cannot access to control0 (control LSB) register\n");
+		return;
+	}
+
+	reg = readl_relaxed(priv->control0);
+	reg &= ~CONTROL0_TSEN_RESET;
+	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
+	writel(reg, priv->control0);
+	msleep(10);
+}
+
 static bool armada_is_valid(struct armada_thermal_priv *priv)
 {
 	u32 reg = readl_relaxed(priv->status);
@@ -167,6 +191,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 	struct armada_thermal_priv *priv = thermal->devdata;
 	u32 reg;
 	unsigned long m, b, div;
+	int sample;
 
 	/* Valid check */
 	if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -177,6 +202,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 
 	reg = readl_relaxed(priv->status);
 	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+	if (priv->data->signed_sample)
+		/* The most significant bit is the sign bit */
+		sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+	else
+		sample = reg;
 
 	/* Get formula coeficients */
 	b = priv->data->coef_b;
@@ -184,9 +214,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
 	div = priv->data->coef_div;
 
 	if (priv->data->inverted)
-		*temp = ((m * reg) - b) / div;
+		*temp = ((m * sample) - b) / div;
 	else
-		*temp = (b - (m * reg)) / div;
+		*temp = (b - (m * sample)) / div;
 	return 0;
 }
 
@@ -237,6 +267,19 @@ static const struct armada_thermal_data armada380_data = {
 	.inverted = true,
 };
 
+static const struct armada_thermal_data armada_ap806_data = {
+	.is_valid = armada_is_valid,
+	.init_sensor = armada_ap806_init_sensor,
+	.is_valid_bit = BIT(16),
+	.temp_shift = 0,
+	.temp_mask = 0x3ff,
+	.coef_b = -150000,
+	.coef_m = 423UL,
+	.coef_div = 1,
+	.inverted = true,
+	.signed_sample = true,
+};
+
 static const struct of_device_id armada_thermal_id_table[] = {
 	{
 		.compatible = "marvell,armadaxp-thermal",
@@ -255,6 +298,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
 		.data       = &armada380_data,
 	},
 	{
+		.compatible = "marvell,armada-ap806-thermal",
+		.data       = &armada_ap806_data,
+	},
+	{
 		/* sentinel */
 	},
 };
-- 
2.11.0

Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> The AP806 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() to handle signed values.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Maybe you should mention that you have made some changes at least to be
able to use the previous modification you have done.

> ---
>  drivers/thermal/armada_thermal.c | 51 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index e5b184cee79b..279d01937bb8 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -47,6 +47,11 @@
>  #define CONTROL0_OFFSET			0x0
>  #define CONTROL1_OFFSET			0x4
>  
> +/* TSEN refers to the temperature sensors within the AP */
> +#define CONTROL0_TSEN_START		BIT(0)
> +#define CONTROL0_TSEN_RESET		BIT(1)
> +#define CONTROL0_TSEN_ENABLE		BIT(2)
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -70,6 +75,7 @@ struct armada_thermal_data {
>  	unsigned long coef_m;
>  	unsigned long coef_div;
>  	bool inverted;
> +	bool signed_sample;
>  
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
> @@ -154,6 +160,24 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	}
>  }
>  
> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> +				     struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	if (!priv->control0) {
> +		dev_err(&pdev->dev,
> +			"Cannot access to control0 (control LSB) register\n");
> +		return;
> +	}
> +
> +	reg = readl_relaxed(priv->control0);
> +	reg &= ~CONTROL0_TSEN_RESET;
> +	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> +	writel(reg, priv->control0);
> +	msleep(10);
> +}
> +
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	u32 reg = readl_relaxed(priv->status);
> @@ -167,6 +191,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  	struct armada_thermal_priv *priv = thermal->devdata;
>  	u32 reg;
>  	unsigned long m, b, div;
> +	int sample;
>  
>  	/* Valid check */
>  	if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> @@ -177,6 +202,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  
>  	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
> +	if (priv->data->signed_sample)
> +		/* The most significant bit is the sign bit */
> +		sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
> +	else
> +		sample = reg;
>  
>  	/* Get formula coeficients */
>  	b = priv->data->coef_b;
> @@ -184,9 +214,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  	div = priv->data->coef_div;
>  
>  	if (priv->data->inverted)
> -		*temp = ((m * reg) - b) / div;
> +		*temp = ((m * sample) - b) / div;
>  	else
> -		*temp = (b - (m * reg)) / div;
> +		*temp = (b - (m * sample)) / div;
>  	return 0;
>  }
>  
> @@ -237,6 +267,19 @@ static const struct armada_thermal_data armada380_data = {
>  	.inverted = true,
>  };
>  
> +static const struct armada_thermal_data armada_ap806_data = {
> +	.is_valid = armada_is_valid,
> +	.init_sensor = armada_ap806_init_sensor,
> +	.is_valid_bit = BIT(16),
> +	.temp_shift = 0,
> +	.temp_mask = 0x3ff,
> +	.coef_b = -150000,

Don't you expect any side effect by storing a negative value in a
unsigned variable?


Thanks,

Gregory



> +	.coef_m = 423UL,
> +	.coef_div = 1,
> +	.inverted = true,
> +	.signed_sample = true,
> +};
> +
>  static const struct of_device_id armada_thermal_id_table[] = {
>  	{
>  		.compatible = "marvell,armadaxp-thermal",
> @@ -255,6 +298,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
>  		.data       = &armada380_data,
>  	},
>  	{
> +		.compatible = "marvell,armada-ap806-thermal",
> +		.data       = &armada_ap806_data,
> +	},
> +	{
>  		/* sentinel */
>  	},
>  };
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> From: Baruch Siach <baruch@tkos.co.il>
>
> The AP806 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() to handle signed values.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>

Maybe you should mention that you have made some changes at least to be
able to use the previous modification you have done.

> ---
>  drivers/thermal/armada_thermal.c | 51 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index e5b184cee79b..279d01937bb8 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -47,6 +47,11 @@
>  #define CONTROL0_OFFSET			0x0
>  #define CONTROL1_OFFSET			0x4
>  
> +/* TSEN refers to the temperature sensors within the AP */
> +#define CONTROL0_TSEN_START		BIT(0)
> +#define CONTROL0_TSEN_RESET		BIT(1)
> +#define CONTROL0_TSEN_ENABLE		BIT(2)
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -70,6 +75,7 @@ struct armada_thermal_data {
>  	unsigned long coef_m;
>  	unsigned long coef_div;
>  	bool inverted;
> +	bool signed_sample;
>  
>  	/* Register shift and mask to access the sensor temperature */
>  	unsigned int temp_shift;
> @@ -154,6 +160,24 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	}
>  }
>  
> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> +				     struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	if (!priv->control0) {
> +		dev_err(&pdev->dev,
> +			"Cannot access to control0 (control LSB) register\n");
> +		return;
> +	}
> +
> +	reg = readl_relaxed(priv->control0);
> +	reg &= ~CONTROL0_TSEN_RESET;
> +	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> +	writel(reg, priv->control0);
> +	msleep(10);
> +}
> +
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
>  {
>  	u32 reg = readl_relaxed(priv->status);
> @@ -167,6 +191,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  	struct armada_thermal_priv *priv = thermal->devdata;
>  	u32 reg;
>  	unsigned long m, b, div;
> +	int sample;
>  
>  	/* Valid check */
>  	if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> @@ -177,6 +202,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  
>  	reg = readl_relaxed(priv->status);
>  	reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
> +	if (priv->data->signed_sample)
> +		/* The most significant bit is the sign bit */
> +		sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
> +	else
> +		sample = reg;
>  
>  	/* Get formula coeficients */
>  	b = priv->data->coef_b;
> @@ -184,9 +214,9 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>  	div = priv->data->coef_div;
>  
>  	if (priv->data->inverted)
> -		*temp = ((m * reg) - b) / div;
> +		*temp = ((m * sample) - b) / div;
>  	else
> -		*temp = (b - (m * reg)) / div;
> +		*temp = (b - (m * sample)) / div;
>  	return 0;
>  }
>  
> @@ -237,6 +267,19 @@ static const struct armada_thermal_data armada380_data = {
>  	.inverted = true,
>  };
>  
> +static const struct armada_thermal_data armada_ap806_data = {
> +	.is_valid = armada_is_valid,
> +	.init_sensor = armada_ap806_init_sensor,
> +	.is_valid_bit = BIT(16),
> +	.temp_shift = 0,
> +	.temp_mask = 0x3ff,
> +	.coef_b = -150000,

Don't you expect any side effect by storing a negative value in a
unsigned variable?


Thanks,

Gregory



> +	.coef_m = 423UL,
> +	.coef_div = 1,
> +	.inverted = true,
> +	.signed_sample = true,
> +};
> +
>  static const struct of_device_id armada_thermal_id_table[] = {
>  	{
>  		.compatible = "marvell,armadaxp-thermal",
> @@ -255,6 +298,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
>  		.data       = &armada380_data,
>  	},
>  	{
> +		.compatible = "marvell,armada-ap806-thermal",
> +		.data       = &armada_ap806_data,
> +	},
> +	{
>  		/* sentinel */
>  	},
>  };
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel RAYNAL]

Hello Gregory & Baruch,

On Thu, 14 Dec 2017 12:05:43 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:


> > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >  
> >  	if (priv->data->inverted)
> > -		*temp = ((m * reg) - b) / div;
> > +		*temp = ((m * sample) - b) / div;
> >  	else
> > -		*temp = (b - (m * reg)) / div;
> > +		*temp = (b - (m * sample)) / div;
> >  	return 0;
> >  }
> >  
> > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > armada380_data = { .inverted = true,
> >  };
> >  
> > +static const struct armada_thermal_data armada_ap806_data = {
> > +	.is_valid = armada_is_valid,
> > +	.init_sensor = armada_ap806_init_sensor,
> > +	.is_valid_bit = BIT(16),
> > +	.temp_shift = 0,
> > +	.temp_mask = 0x3ff,
> > +	.coef_b = -150000,  
> 
> Don't you expect any side effect by storing a negative value in a
> unsigned variable?

That is a fair question, I did not spot that.

As other values are really close to 2^32 I don't know what is the best
option for us in this case. Should I:
- don't care?
- use signed values? (dangerous IMHO)
- use a union with a signed and an unsigned value? (problem moved to
  ->get_temp())

Thanks for your input.
Miquèl

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel RAYNAL]

Hello Gregory & Baruch,

On Thu, 14 Dec 2017 12:05:43 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:


> > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >  
> >  	if (priv->data->inverted)
> > -		*temp = ((m * reg) - b) / div;
> > +		*temp = ((m * sample) - b) / div;
> >  	else
> > -		*temp = (b - (m * reg)) / div;
> > +		*temp = (b - (m * sample)) / div;
> >  	return 0;
> >  }
> >  
> > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > armada380_data = { .inverted = true,
> >  };
> >  
> > +static const struct armada_thermal_data armada_ap806_data = {
> > +	.is_valid = armada_is_valid,
> > +	.init_sensor = armada_ap806_init_sensor,
> > +	.is_valid_bit = BIT(16),
> > +	.temp_shift = 0,
> > +	.temp_mask = 0x3ff,
> > +	.coef_b = -150000,  
> 
> Don't you expect any side effect by storing a negative value in a
> unsigned variable?

That is a fair question, I did not spot that.

As other values are really close to 2^32 I don't know what is the best
option for us in this case. Should I:
- don't care?
- use signed values? (dangerous IMHO)
- use a union with a signed and an unsigned value? (problem moved to
  ->get_temp())

Thanks for your input.
Miqu?l

Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Baruch Siach]

Hi Miquèl,

On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> Hello Gregory & Baruch,
> 
> On Thu, 14 Dec 2017 12:05:43 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> 
> > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > >  
> > >  	if (priv->data->inverted)
> > > -		*temp = ((m * reg) - b) / div;
> > > +		*temp = ((m * sample) - b) / div;
> > >  	else
> > > -		*temp = (b - (m * reg)) / div;
> > > +		*temp = (b - (m * sample)) / div;
> > >  	return 0;
> > >  }
> > >  
> > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > armada380_data = { .inverted = true,
> > >  };
> > >  
> > > +static const struct armada_thermal_data armada_ap806_data = {
> > > +	.is_valid = armada_is_valid,
> > > +	.init_sensor = armada_ap806_init_sensor,
> > > +	.is_valid_bit = BIT(16),
> > > +	.temp_shift = 0,
> > > +	.temp_mask = 0x3ff,
> > > +	.coef_b = -150000,  
> > 
> > Don't you expect any side effect by storing a negative value in a
> > unsigned variable?
> 
> That is a fair question, I did not spot that.
> 
> As other values are really close to 2^32 I don't know what is the best
> option for us in this case. Should I:
> - don't care?
> - use signed values? (dangerous IMHO)
> - use a union with a signed and an unsigned value? (problem moved to
>   ->get_temp())

Another option is to use s64 type.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Baruch Siach]

Hi Miqu?l,

On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> Hello Gregory & Baruch,
> 
> On Thu, 14 Dec 2017 12:05:43 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> 
> > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > >  
> > >  	if (priv->data->inverted)
> > > -		*temp = ((m * reg) - b) / div;
> > > +		*temp = ((m * sample) - b) / div;
> > >  	else
> > > -		*temp = (b - (m * reg)) / div;
> > > +		*temp = (b - (m * sample)) / div;
> > >  	return 0;
> > >  }
> > >  
> > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > armada380_data = { .inverted = true,
> > >  };
> > >  
> > > +static const struct armada_thermal_data armada_ap806_data = {
> > > +	.is_valid = armada_is_valid,
> > > +	.init_sensor = armada_ap806_init_sensor,
> > > +	.is_valid_bit = BIT(16),
> > > +	.temp_shift = 0,
> > > +	.temp_mask = 0x3ff,
> > > +	.coef_b = -150000,  
> > 
> > Don't you expect any side effect by storing a negative value in a
> > unsigned variable?
> 
> That is a fair question, I did not spot that.
> 
> As other values are really close to 2^32 I don't know what is the best
> option for us in this case. Should I:
> - don't care?
> - use signed values? (dangerous IMHO)
> - use a union with a signed and an unsigned value? (problem moved to
>   ->get_temp())

Another option is to use s64 type.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel RAYNAL]

Hi Baruch,

On Mon, 18 Dec 2017 13:11:56 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miquèl,
> 
> On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> > Hello Gregory & Baruch,
> > 
> > On Thu, 14 Dec 2017 12:05:43 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >   
> > > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > > >  
> > > >  	if (priv->data->inverted)
> > > > -		*temp = ((m * reg) - b) / div;
> > > > +		*temp = ((m * sample) - b) / div;
> > > >  	else
> > > > -		*temp = (b - (m * reg)) / div;
> > > > +		*temp = (b - (m * sample)) / div;
> > > >  	return 0;
> > > >  }
> > > >  
> > > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > > armada380_data = { .inverted = true,
> > > >  };
> > > >  
> > > > +static const struct armada_thermal_data armada_ap806_data = {
> > > > +	.is_valid = armada_is_valid,
> > > > +	.init_sensor = armada_ap806_init_sensor,
> > > > +	.is_valid_bit = BIT(16),
> > > > +	.temp_shift = 0,
> > > > +	.temp_mask = 0x3ff,
> > > > +	.coef_b = -150000,    
> > > 
> > > Don't you expect any side effect by storing a negative value in a
> > > unsigned variable?  
> > 
> > That is a fair question, I did not spot that.
> > 
> > As other values are really close to 2^32 I don't know what is the
> > best option for us in this case. Should I:
> > - don't care?
> > - use signed values? (dangerous IMHO)
> > - use a union with a signed and an unsigned value? (problem moved
> > to ->get_temp())  
> 
> Another option is to use s64 type.

I prefer this one!

Thank you,
Miquèl

> 
> baruch
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Miquel RAYNAL]

Hi Baruch,

On Mon, 18 Dec 2017 13:11:56 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miqu?l,
> 
> On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> > Hello Gregory & Baruch,
> > 
> > On Thu, 14 Dec 2017 12:05:43 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >   
> > > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > > >  
> > > >  	if (priv->data->inverted)
> > > > -		*temp = ((m * reg) - b) / div;
> > > > +		*temp = ((m * sample) - b) / div;
> > > >  	else
> > > > -		*temp = (b - (m * reg)) / div;
> > > > +		*temp = (b - (m * sample)) / div;
> > > >  	return 0;
> > > >  }
> > > >  
> > > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > > armada380_data = { .inverted = true,
> > > >  };
> > > >  
> > > > +static const struct armada_thermal_data armada_ap806_data = {
> > > > +	.is_valid = armada_is_valid,
> > > > +	.init_sensor = armada_ap806_init_sensor,
> > > > +	.is_valid_bit = BIT(16),
> > > > +	.temp_shift = 0,
> > > > +	.temp_mask = 0x3ff,
> > > > +	.coef_b = -150000,    
> > > 
> > > Don't you expect any side effect by storing a negative value in a
> > > unsigned variable?  
> > 
> > That is a fair question, I did not spot that.
> > 
> > As other values are really close to 2^32 I don't know what is the
> > best option for us in this case. Should I:
> > - don't care?
> > - use signed values? (dangerous IMHO)
> > - use a union with a signed and an unsigned value? (problem moved
> > to ->get_temp())  
> 
> Another option is to use s64 type.

I prefer this one!

Thank you,
Miqu?l

> 
> baruch
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Baruch Siach]

Hi Miquèl,

On Thu, Dec 14, 2017 at 11:30:05AM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch@tkos.co.il>
> 
> The AP806 component is integrated in the Armada 8k and 7k lines of
> processors.
> 
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() to handle signed values.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---

[...]

> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> +				     struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	if (!priv->control0) {
> +		dev_err(&pdev->dev,
> +			"Cannot access to control0 (control LSB) register\n");
> +		return;
> +	}

With the probe time control area size validation this check would not be 
needed.

baruch

> +
> +	reg = readl_relaxed(priv->control0);
> +	reg &= ~CONTROL0_TSEN_RESET;
> +	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> +	writel(reg, priv->control0);
> +	msleep(10);
> +}

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH v3 05/11] thermal: armada: Add support for Armada AP806

[Baruch Siach]

Hi Miqu?l,

On Thu, Dec 14, 2017 at 11:30:05AM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch@tkos.co.il>
> 
> The AP806 component is integrated in the Armada 8k and 7k lines of
> processors.
> 
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() to handle signed values.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---

[...]

> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> +				     struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	if (!priv->control0) {
> +		dev_err(&pdev->dev,
> +			"Cannot access to control0 (control LSB) register\n");
> +		return;
> +	}

With the probe time control area size validation this check would not be 
needed.

baruch

> +
> +	reg = readl_relaxed(priv->control0);
> +	reg &= ~CONTROL0_TSEN_RESET;
> +	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> +	writel(reg, priv->control0);
> +	msleep(10);
> +}

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH v3 08/11] thermal: armada: Change sensors trim default value

[Miquel Raynal]

Errata #132698 highlights an error in the default value of Tc trim.
Set this parameter to b'011.

Suggested-by: David Sniatkiwicz <davidsn-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/thermal/armada_thermal.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index da58a8961a37..be141ca53e83 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -46,6 +46,10 @@
 #define CONTROL0_OFFSET			0x0
 #define CONTROL1_OFFSET			0x4
 
+/* Errata fields */
+#define CONTROL0_TSEN_TC_TRIM_MASK	0x7
+#define CONTROL0_TSEN_TC_TRIM_VAL	0x3
+
 /* TSEN refers to the temperature sensors within the AP */
 #define CONTROL0_TSEN_START		BIT(0)
 #define CONTROL0_TSEN_RESET		BIT(1)
@@ -160,6 +164,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
 	writel(reg, priv->control1);
 	msleep(10);
+
+	/* Set Tsen Tc Trim to correct default value (errata #132698) */
+	if (priv->control0) {
+		reg = readl_relaxed(priv->control0);
+		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
+		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
+		writel(reg, priv->control0);
+		msleep(10);
+	}
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 08/11] thermal: armada: Change sensors trim default value

[Miquel Raynal]

Errata #132698 highlights an error in the default value of Tc trim.
Set this parameter to b'011.

Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index da58a8961a37..be141ca53e83 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -46,6 +46,10 @@
 #define CONTROL0_OFFSET			0x0
 #define CONTROL1_OFFSET			0x4
 
+/* Errata fields */
+#define CONTROL0_TSEN_TC_TRIM_MASK	0x7
+#define CONTROL0_TSEN_TC_TRIM_VAL	0x3
+
 /* TSEN refers to the temperature sensors within the AP */
 #define CONTROL0_TSEN_START		BIT(0)
 #define CONTROL0_TSEN_RESET		BIT(1)
@@ -160,6 +164,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
 	writel(reg, priv->control1);
 	msleep(10);
+
+	/* Set Tsen Tc Trim to correct default value (errata #132698) */
+	if (priv->control0) {
+		reg = readl_relaxed(priv->control0);
+		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
+		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
+		writel(reg, priv->control0);
+		msleep(10);
+	}
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
-- 
2.11.0

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

The CP110 component is integrated in the Armada 8k and 7k lines of
processors.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: renamed the register pointers]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 279d01937bb8..f5c911524656 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -37,7 +37,6 @@
 #define A375_UNIT_CONTROL_MASK		0x7
 #define A375_READOUT_INVERT		BIT(15)
 #define A375_HW_RESETn			BIT(8)
-#define A380_HW_RESET			BIT(8)
 
 /* Legacy bindings */
 #define LEGACY_CONTROL_MEM_LEN		0x4
@@ -52,6 +51,10 @@
 #define CONTROL0_TSEN_RESET		BIT(1)
 #define CONTROL0_TSEN_ENABLE		BIT(2)
 
+/* EXT_TSEN refers to the external temperature sensors, out of the AP */
+#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
+#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -153,11 +156,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	u32 reg = readl_relaxed(priv->control1);
 
 	/* Reset hardware once */
-	if (!(reg & A380_HW_RESET)) {
-		reg |= A380_HW_RESET;
-		writel(reg, priv->control1);
-		msleep(10);
-	}
+	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
+	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
+	writel(reg, priv->control1);
+	msleep(10);
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -280,6 +282,18 @@ static const struct armada_thermal_data armada_ap806_data = {
 	.signed_sample = true,
 };
 
+static const struct armada_thermal_data armada_cp110_data = {
+	.is_valid = armada_is_valid,
+	.init_sensor = armada380_init_sensor,
+	.is_valid_bit = BIT(10),
+	.temp_shift = 0,
+	.temp_mask = 0x3ff,
+	.coef_b = 1172499100UL,
+	.coef_m = 2000096UL,
+	.coef_div = 4201,
+	.inverted = true,
+};
+
 static const struct of_device_id armada_thermal_id_table[] = {
 	{
 		.compatible = "marvell,armadaxp-thermal",
@@ -302,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
 		.data       = &armada_ap806_data,
 	},
 	{
+		.compatible = "marvell,armada-cp110-thermal",
+		.data       = &armada_cp110_data,
+	},
+	{
 		/* sentinel */
 	},
 };
-- 
2.11.0

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel Raynal]

From: Baruch Siach <baruch@tkos.co.il>

The CP110 component is integrated in the Armada 8k and 7k lines of
processors.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: renamed the register pointers]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 279d01937bb8..f5c911524656 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -37,7 +37,6 @@
 #define A375_UNIT_CONTROL_MASK		0x7
 #define A375_READOUT_INVERT		BIT(15)
 #define A375_HW_RESETn			BIT(8)
-#define A380_HW_RESET			BIT(8)
 
 /* Legacy bindings */
 #define LEGACY_CONTROL_MEM_LEN		0x4
@@ -52,6 +51,10 @@
 #define CONTROL0_TSEN_RESET		BIT(1)
 #define CONTROL0_TSEN_ENABLE		BIT(2)
 
+/* EXT_TSEN refers to the external temperature sensors, out of the AP */
+#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
+#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -153,11 +156,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	u32 reg = readl_relaxed(priv->control1);
 
 	/* Reset hardware once */
-	if (!(reg & A380_HW_RESET)) {
-		reg |= A380_HW_RESET;
-		writel(reg, priv->control1);
-		msleep(10);
-	}
+	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
+	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
+	writel(reg, priv->control1);
+	msleep(10);
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -280,6 +282,18 @@ static const struct armada_thermal_data armada_ap806_data = {
 	.signed_sample = true,
 };
 
+static const struct armada_thermal_data armada_cp110_data = {
+	.is_valid = armada_is_valid,
+	.init_sensor = armada380_init_sensor,
+	.is_valid_bit = BIT(10),
+	.temp_shift = 0,
+	.temp_mask = 0x3ff,
+	.coef_b = 1172499100UL,
+	.coef_m = 2000096UL,
+	.coef_div = 4201,
+	.inverted = true,
+};
+
 static const struct of_device_id armada_thermal_id_table[] = {
 	{
 		.compatible = "marvell,armadaxp-thermal",
@@ -302,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
 		.data       = &armada_ap806_data,
 	},
 	{
+		.compatible = "marvell,armada-cp110-thermal",
+		.data       = &armada_cp110_data,
+	},
+	{
 		/* sentinel */
 	},
 };
-- 
2.11.0

Re: [PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> The CP110 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: renamed the register pointers]

Actually you did more thant this see below


> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/thermal/armada_thermal.c | 30 ++++++++++++++++++++++++------
>  1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 279d01937bb8..f5c911524656 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -37,7 +37,6 @@
>  #define A375_UNIT_CONTROL_MASK		0x7
>  #define A375_READOUT_INVERT		BIT(15)
>  #define A375_HW_RESETn			BIT(8)
> -#define A380_HW_RESET			BIT(8)
>  
>  /* Legacy bindings */
>  #define LEGACY_CONTROL_MEM_LEN		0x4
> @@ -52,6 +51,10 @@
>  #define CONTROL0_TSEN_RESET		BIT(1)
>  #define CONTROL0_TSEN_ENABLE		BIT(2)
>  
> +/* EXT_TSEN refers to the external temperature sensors, out of the AP */
> +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
You added or rename these values

> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
> -	if (!(reg & A380_HW_RESET)) {
> -		reg |= A380_HW_RESET;
> -		writel(reg, priv->control1);
> -		msleep(10);
> -	}
> +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> +	writel(reg, priv->control1);

And here you modified the behavior of this function.
Did you checked that it is valid for Armada 38x?

Given the comment we had, I thought we should not do anything if
CONTROL1_EXT_TSEN_HW_RESETn was not set.

By the way, if the new sequence is valid, this comment should be removed
or at least updated.

Gregory

> +	msleep(10);
>  }
>  
>  static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -280,6 +282,18 @@ static const struct armada_thermal_data armada_ap806_data = {
>  	.signed_sample = true,
>  };
>  
> +static const struct armada_thermal_data armada_cp110_data = {
> +	.is_valid = armada_is_valid,
> +	.init_sensor = armada380_init_sensor,
> +	.is_valid_bit = BIT(10),
> +	.temp_shift = 0,
> +	.temp_mask = 0x3ff,
> +	.coef_b = 1172499100UL,
> +	.coef_m = 2000096UL,
> +	.coef_div = 4201,
> +	.inverted = true,
> +};
> +
>  static const struct of_device_id armada_thermal_id_table[] = {
>  	{
>  		.compatible = "marvell,armadaxp-thermal",
> @@ -302,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
>  		.data       = &armada_ap806_data,
>  	},
>  	{
> +		.compatible = "marvell,armada-cp110-thermal",
> +		.data       = &armada_cp110_data,
> +	},
> +	{
>  		/* sentinel */
>  	},
>  };
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> From: Baruch Siach <baruch@tkos.co.il>
>
> The CP110 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> [<miquel.raynal@free-electrons.com>: renamed the register pointers]

Actually you did more thant this see below


> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 30 ++++++++++++++++++++++++------
>  1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 279d01937bb8..f5c911524656 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -37,7 +37,6 @@
>  #define A375_UNIT_CONTROL_MASK		0x7
>  #define A375_READOUT_INVERT		BIT(15)
>  #define A375_HW_RESETn			BIT(8)
> -#define A380_HW_RESET			BIT(8)
>  
>  /* Legacy bindings */
>  #define LEGACY_CONTROL_MEM_LEN		0x4
> @@ -52,6 +51,10 @@
>  #define CONTROL0_TSEN_RESET		BIT(1)
>  #define CONTROL0_TSEN_ENABLE		BIT(2)
>  
> +/* EXT_TSEN refers to the external temperature sensors, out of the AP */
> +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
You added or rename these values

> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	u32 reg = readl_relaxed(priv->control1);
>  
>  	/* Reset hardware once */
> -	if (!(reg & A380_HW_RESET)) {
> -		reg |= A380_HW_RESET;
> -		writel(reg, priv->control1);
> -		msleep(10);
> -	}
> +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> +	writel(reg, priv->control1);

And here you modified the behavior of this function.
Did you checked that it is valid for Armada 38x?

Given the comment we had, I thought we should not do anything if
CONTROL1_EXT_TSEN_HW_RESETn was not set.

By the way, if the new sequence is valid, this comment should be removed
or at least updated.

Gregory

> +	msleep(10);
>  }
>  
>  static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -280,6 +282,18 @@ static const struct armada_thermal_data armada_ap806_data = {
>  	.signed_sample = true,
>  };
>  
> +static const struct armada_thermal_data armada_cp110_data = {
> +	.is_valid = armada_is_valid,
> +	.init_sensor = armada380_init_sensor,
> +	.is_valid_bit = BIT(10),
> +	.temp_shift = 0,
> +	.temp_mask = 0x3ff,
> +	.coef_b = 1172499100UL,
> +	.coef_m = 2000096UL,
> +	.coef_div = 4201,
> +	.inverted = true,
> +};
> +
>  static const struct of_device_id armada_thermal_id_table[] = {
>  	{
>  		.compatible = "marvell,armadaxp-thermal",
> @@ -302,6 +316,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
>  		.data       = &armada_ap806_data,
>  	},
>  	{
> +		.compatible = "marvell,armada-cp110-thermal",
> +		.data       = &armada_cp110_data,
> +	},
> +	{
>  		/* sentinel */
>  	},
>  };
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:11:49 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Miquel,
>  
>  On jeu., déc. 14 2017, Miquel Raynal
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> >
> > The CP110 component is integrated in the Armada 8k and 7k lines of
> > processors.
> >
> > Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: renamed the register
> > pointers]  
> 
> Actually you did more thant this see below
> 
> 
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> >  drivers/thermal/armada_thermal.c | 30
> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6
> > deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 279d01937bb8..f5c911524656
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -37,7 +37,6 @@
> >  #define A375_UNIT_CONTROL_MASK		0x7
> >  #define A375_READOUT_INVERT		BIT(15)
> >  #define A375_HW_RESETn			BIT(8)
> > -#define A380_HW_RESET			BIT(8)
> >  
> >  /* Legacy bindings */
> >  #define LEGACY_CONTROL_MEM_LEN		0x4
> > @@ -52,6 +51,10 @@
> >  #define CONTROL0_TSEN_RESET		BIT(1)
> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
> >  
> > +/* EXT_TSEN refers to the external temperature sensors, out of the
> > AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)  
> You added or rename these values
> 
> > +
> >  struct armada_thermal_data;
> >  
> >  /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
> >  
> >  	/* Reset hardware once */
> > -	if (!(reg & A380_HW_RESET)) {
> > -		reg |= A380_HW_RESET;
> > -		writel(reg, priv->control1);
> > -		msleep(10);
> > -	}
> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> > +	writel(reg, priv->control1);  
> 
> And here you modified the behavior of this function.
> Did you checked that it is valid for Armada 38x?

There is nothing about it the documentation and anyway this register
can be accessed later, so writing it is harmless ayway.

> 
> Given the comment we had, I thought we should not do anything if
> CONTROL1_EXT_TSEN_HW_RESETn was not set.

That is the opposite, if it is not set (ie. reset is active), you have
to set it (reset is then disabled).

> 
> By the way, if the new sequence is valid, this comment should be
> removed or at least updated.

That's right, I will in v4.

Thanks for reviewing,
Miquèl


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:11:49 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., d?c. 14 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
> 
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > The CP110 component is integrated in the Armada 8k and 7k lines of
> > processors.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > [<miquel.raynal@free-electrons.com>: renamed the register
> > pointers]  
> 
> Actually you did more thant this see below
> 
> 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  drivers/thermal/armada_thermal.c | 30
> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6
> > deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 279d01937bb8..f5c911524656
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -37,7 +37,6 @@
> >  #define A375_UNIT_CONTROL_MASK		0x7
> >  #define A375_READOUT_INVERT		BIT(15)
> >  #define A375_HW_RESETn			BIT(8)
> > -#define A380_HW_RESET			BIT(8)
> >  
> >  /* Legacy bindings */
> >  #define LEGACY_CONTROL_MEM_LEN		0x4
> > @@ -52,6 +51,10 @@
> >  #define CONTROL0_TSEN_RESET		BIT(1)
> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
> >  
> > +/* EXT_TSEN refers to the external temperature sensors, out of the
> > AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)  
> You added or rename these values
> 
> > +
> >  struct armada_thermal_data;
> >  
> >  /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
> >  
> >  	/* Reset hardware once */
> > -	if (!(reg & A380_HW_RESET)) {
> > -		reg |= A380_HW_RESET;
> > -		writel(reg, priv->control1);
> > -		msleep(10);
> > -	}
> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> > +	writel(reg, priv->control1);  
> 
> And here you modified the behavior of this function.
> Did you checked that it is valid for Armada 38x?

There is nothing about it the documentation and anyway this register
can be accessed later, so writing it is harmless ayway.

> 
> Given the comment we had, I thought we should not do anything if
> CONTROL1_EXT_TSEN_HW_RESETn was not set.

That is the opposite, if it is not set (ie. reset is active), you have
to set it (reset is then disabled).

> 
> By the way, if the new sequence is valid, this comment should be
> removed or at least updated.

That's right, I will in v4.

Thanks for reviewing,
Miqu?l

Re: [PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> On Thu, 14 Dec 2017 12:11:49 +0100
> Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> Hi Miquel,
>>  
>>  On jeu., déc. 14 2017, Miquel Raynal
>> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> 
>> > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>> >
>> > The CP110 component is integrated in the Armada 8k and 7k lines of
>> > processors.
>> >
>> > Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>> > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: renamed the register
>> > pointers]  
>> 
>> Actually you did more thant this see below
>> 
>> 
>> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> > ---
>> >  drivers/thermal/armada_thermal.c | 30
>> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6
>> > deletions(-)
>> >
>> > diff --git a/drivers/thermal/armada_thermal.c
>> > b/drivers/thermal/armada_thermal.c index 279d01937bb8..f5c911524656
>> > 100644 --- a/drivers/thermal/armada_thermal.c
>> > +++ b/drivers/thermal/armada_thermal.c
>> > @@ -37,7 +37,6 @@
>> >  #define A375_UNIT_CONTROL_MASK		0x7
>> >  #define A375_READOUT_INVERT		BIT(15)
>> >  #define A375_HW_RESETn			BIT(8)
>> > -#define A380_HW_RESET			BIT(8)
>> >  
>> >  /* Legacy bindings */
>> >  #define LEGACY_CONTROL_MEM_LEN		0x4
>> > @@ -52,6 +51,10 @@
>> >  #define CONTROL0_TSEN_RESET		BIT(1)
>> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
>> >  
>> > +/* EXT_TSEN refers to the external temperature sensors, out of the
>> > AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
>> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)  
>> You added or rename these values
>> 
>> > +
>> >  struct armada_thermal_data;
>> >  
>> >  /* Marvell EBU Thermal Sensor Dev Structure */
>> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
>> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
>> >  
>> >  	/* Reset hardware once */
>> > -	if (!(reg & A380_HW_RESET)) {
>> > -		reg |= A380_HW_RESET;
>> > -		writel(reg, priv->control1);
>> > -		msleep(10);
>> > -	}
>> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
>> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
>> > +	writel(reg, priv->control1);  
>> 
>> And here you modified the behavior of this function.
>> Did you checked that it is valid for Armada 38x?
>
> There is nothing about it the documentation and anyway this register
> can be accessed later, so writing it is harmless ayway.
>
>> 
>> Given the comment we had, I thought we should not do anything if
>> CONTROL1_EXT_TSEN_HW_RESETn was not set.
>
> That is the opposite, if it is not set (ie. reset is active), you have
> to set it (reset is then disabled).

Actually I was concerned by the "once" for me it means "only one time",
but maybe it just meant it was useless to reset it again but not
harmful.

Gregory

>
>> 
>> By the way, if the new sequence is valid, this comment should be
>> removed or at least updated.
>
> That's right, I will in v4.
>
> Thanks for reviewing,
> Miquèl
>
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> On Thu, 14 Dec 2017 12:11:49 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi Miquel,
>>  
>>  On jeu., d?c. 14 2017, Miquel Raynal
>> <miquel.raynal@free-electrons.com> wrote:
>> 
>> > From: Baruch Siach <baruch@tkos.co.il>
>> >
>> > The CP110 component is integrated in the Armada 8k and 7k lines of
>> > processors.
>> >
>> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> > [<miquel.raynal@free-electrons.com>: renamed the register
>> > pointers]  
>> 
>> Actually you did more thant this see below
>> 
>> 
>> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>> > ---
>> >  drivers/thermal/armada_thermal.c | 30
>> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6
>> > deletions(-)
>> >
>> > diff --git a/drivers/thermal/armada_thermal.c
>> > b/drivers/thermal/armada_thermal.c index 279d01937bb8..f5c911524656
>> > 100644 --- a/drivers/thermal/armada_thermal.c
>> > +++ b/drivers/thermal/armada_thermal.c
>> > @@ -37,7 +37,6 @@
>> >  #define A375_UNIT_CONTROL_MASK		0x7
>> >  #define A375_READOUT_INVERT		BIT(15)
>> >  #define A375_HW_RESETn			BIT(8)
>> > -#define A380_HW_RESET			BIT(8)
>> >  
>> >  /* Legacy bindings */
>> >  #define LEGACY_CONTROL_MEM_LEN		0x4
>> > @@ -52,6 +51,10 @@
>> >  #define CONTROL0_TSEN_RESET		BIT(1)
>> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
>> >  
>> > +/* EXT_TSEN refers to the external temperature sensors, out of the
>> > AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
>> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)  
>> You added or rename these values
>> 
>> > +
>> >  struct armada_thermal_data;
>> >  
>> >  /* Marvell EBU Thermal Sensor Dev Structure */
>> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
>> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
>> >  
>> >  	/* Reset hardware once */
>> > -	if (!(reg & A380_HW_RESET)) {
>> > -		reg |= A380_HW_RESET;
>> > -		writel(reg, priv->control1);
>> > -		msleep(10);
>> > -	}
>> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
>> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
>> > +	writel(reg, priv->control1);  
>> 
>> And here you modified the behavior of this function.
>> Did you checked that it is valid for Armada 38x?
>
> There is nothing about it the documentation and anyway this register
> can be accessed later, so writing it is harmless ayway.
>
>> 
>> Given the comment we had, I thought we should not do anything if
>> CONTROL1_EXT_TSEN_HW_RESETn was not set.
>
> That is the opposite, if it is not set (ie. reset is active), you have
> to set it (reset is then disabled).

Actually I was concerned by the "once" for me it means "only one time",
but maybe it just meant it was useless to reset it again but not
harmful.

Gregory

>
>> 
>> By the way, if the new sequence is valid, this comment should be
>> removed or at least updated.
>
> That's right, I will in v4.
>
> Thanks for reviewing,
> Miqu?l
>
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:37:32 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Miquel,
>  
>  On jeu., déc. 14 2017, Miquel RAYNAL
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > On Thu, 14 Dec 2017 12:11:49 +0100
> > Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >  
> >> Hi Miquel,
> >>  
> >>  On jeu., déc. 14 2017, Miquel Raynal
> >> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >>   
> >> > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> >> >
> >> > The CP110 component is integrated in the Armada 8k and 7k lines
> >> > of processors.
> >> >
> >> > Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> >> > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: renamed the register
> >> > pointers]    
> >> 
> >> Actually you did more thant this see below
> >> 
> >>   
> >> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >> > ---
> >> >  drivers/thermal/armada_thermal.c | 30
> >> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+),
> >> > 6 deletions(-)
> >> >
> >> > diff --git a/drivers/thermal/armada_thermal.c
> >> > b/drivers/thermal/armada_thermal.c index
> >> > 279d01937bb8..f5c911524656 100644 ---
> >> > a/drivers/thermal/armada_thermal.c +++
> >> > b/drivers/thermal/armada_thermal.c @@ -37,7 +37,6 @@
> >> >  #define A375_UNIT_CONTROL_MASK		0x7
> >> >  #define A375_READOUT_INVERT		BIT(15)
> >> >  #define A375_HW_RESETn			BIT(8)
> >> > -#define A380_HW_RESET			BIT(8)
> >> >  
> >> >  /* Legacy bindings */
> >> >  #define LEGACY_CONTROL_MEM_LEN		0x4
> >> > @@ -52,6 +51,10 @@
> >> >  #define CONTROL0_TSEN_RESET		BIT(1)
> >> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
> >> >  
> >> > +/* EXT_TSEN refers to the external temperature sensors, out of
> >> > the AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> >> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)    
> >> You added or rename these values
> >>   
> >> > +
> >> >  struct armada_thermal_data;
> >> >  
> >> >  /* Marvell EBU Thermal Sensor Dev Structure */
> >> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
> >> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
> >> >  
> >> >  	/* Reset hardware once */
> >> > -	if (!(reg & A380_HW_RESET)) {
> >> > -		reg |= A380_HW_RESET;
> >> > -		writel(reg, priv->control1);
> >> > -		msleep(10);
> >> > -	}
> >> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> >> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> >> > +	writel(reg, priv->control1);    
> >> 
> >> And here you modified the behavior of this function.
> >> Did you checked that it is valid for Armada 38x?  
> >
> > There is nothing about it the documentation and anyway this register
> > can be accessed later, so writing it is harmless ayway.
> >  
> >> 
> >> Given the comment we had, I thought we should not do anything if
> >> CONTROL1_EXT_TSEN_HW_RESETn was not set.  
> >
> > That is the opposite, if it is not set (ie. reset is active), you
> > have to set it (reset is then disabled).  
> 
> Actually I was concerned by the "once" for me it means "only one
> time", but maybe it just meant it was useless to reset it again but
> not harmful.

This:

    reg |= CONTROL1_EXT_TSEN_HW_RESETn;

does not reset the IP, instead it cancels the reset, if one is
happening. So no, doing it unconditionally is not harmful.

Miquèl


> 
> Gregory
> 
> >  
> >> 
> >> By the way, if the new sequence is valid, this comment should be
> >> removed or at least updated.  
> >
> > That's right, I will in v4.
> >
> > Thanks for reviewing,
> > Miquèl
> >
> >  
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/11] thermal: armada: Add support for Armada CP110

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:37:32 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., d?c. 14 2017, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> 
> > On Thu, 14 Dec 2017 12:11:49 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >  
> >> Hi Miquel,
> >>  
> >>  On jeu., d?c. 14 2017, Miquel Raynal
> >> <miquel.raynal@free-electrons.com> wrote:
> >>   
> >> > From: Baruch Siach <baruch@tkos.co.il>
> >> >
> >> > The CP110 component is integrated in the Armada 8k and 7k lines
> >> > of processors.
> >> >
> >> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> >> > [<miquel.raynal@free-electrons.com>: renamed the register
> >> > pointers]    
> >> 
> >> Actually you did more thant this see below
> >> 
> >>   
> >> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> >> > ---
> >> >  drivers/thermal/armada_thermal.c | 30
> >> > ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+),
> >> > 6 deletions(-)
> >> >
> >> > diff --git a/drivers/thermal/armada_thermal.c
> >> > b/drivers/thermal/armada_thermal.c index
> >> > 279d01937bb8..f5c911524656 100644 ---
> >> > a/drivers/thermal/armada_thermal.c +++
> >> > b/drivers/thermal/armada_thermal.c @@ -37,7 +37,6 @@
> >> >  #define A375_UNIT_CONTROL_MASK		0x7
> >> >  #define A375_READOUT_INVERT		BIT(15)
> >> >  #define A375_HW_RESETn			BIT(8)
> >> > -#define A380_HW_RESET			BIT(8)
> >> >  
> >> >  /* Legacy bindings */
> >> >  #define LEGACY_CONTROL_MEM_LEN		0x4
> >> > @@ -52,6 +51,10 @@
> >> >  #define CONTROL0_TSEN_RESET		BIT(1)
> >> >  #define CONTROL0_TSEN_ENABLE		BIT(2)
> >> >  
> >> > +/* EXT_TSEN refers to the external temperature sensors, out of
> >> > the AP */ +#define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
> >> > +#define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)    
> >> You added or rename these values
> >>   
> >> > +
> >> >  struct armada_thermal_data;
> >> >  
> >> >  /* Marvell EBU Thermal Sensor Dev Structure */
> >> > @@ -153,11 +156,10 @@ static void armada380_init_sensor(struct
> >> > platform_device *pdev, u32 reg = readl_relaxed(priv->control1);
> >> >  
> >> >  	/* Reset hardware once */
> >> > -	if (!(reg & A380_HW_RESET)) {
> >> > -		reg |= A380_HW_RESET;
> >> > -		writel(reg, priv->control1);
> >> > -		msleep(10);
> >> > -	}
> >> > +	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> >> > +	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> >> > +	writel(reg, priv->control1);    
> >> 
> >> And here you modified the behavior of this function.
> >> Did you checked that it is valid for Armada 38x?  
> >
> > There is nothing about it the documentation and anyway this register
> > can be accessed later, so writing it is harmless ayway.
> >  
> >> 
> >> Given the comment we had, I thought we should not do anything if
> >> CONTROL1_EXT_TSEN_HW_RESETn was not set.  
> >
> > That is the opposite, if it is not set (ie. reset is active), you
> > have to set it (reset is then disabled).  
> 
> Actually I was concerned by the "once" for me it means "only one
> time", but maybe it just meant it was useless to reset it again but
> not harmful.

This:

    reg |= CONTROL1_EXT_TSEN_HW_RESETn;

does not reset the IP, instead it cancels the reset, if one is
happening. So no, doing it unconditionally is not harmful.

Miqu?l


> 
> Gregory
> 
> >  
> >> 
> >> By the way, if the new sequence is valid, this comment should be
> >> removed or at least updated.  
> >
> > That's right, I will in v4.
> >
> > Thanks for reviewing,
> > Miqu?l
> >
> >  
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel Raynal]

Update Armada thermal driver Kconfig entry as well as the driver's
MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
eg. Armada 7K and Armada 8K.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/Kconfig          | 4 ++--
 drivers/thermal/armada_thermal.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 315ae2926e20..44cad046f272 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -301,13 +301,13 @@ config DB8500_THERMAL
 	  thermal zone if trip points reached.
 
 config ARMADA_THERMAL
-	tristate "Armada 370/XP thermal management"
+	tristate "Armada 370/XP/7K/8K thermal management"
 	depends on ARCH_MVEBU || COMPILE_TEST
 	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Enable this option if you want to have support for thermal management
-	  controller present in Armada 370 and Armada XP SoC.
+	  controller present in Armada 370, Armada XP, Armada 7K/8K SoCs.
 
 config DA9062_THERMAL
 	tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f5c911524656..da58a8961a37 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -403,5 +403,5 @@ static struct platform_driver armada_thermal_driver = {
 module_platform_driver(armada_thermal_driver);
 
 MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
-MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_DESCRIPTION("Armada SoCs thermal driver");
 MODULE_LICENSE("GPL v2");
-- 
2.11.0

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel Raynal]

Update Armada thermal driver Kconfig entry as well as the driver's
MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
eg. Armada 7K and Armada 8K.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/Kconfig          | 4 ++--
 drivers/thermal/armada_thermal.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 315ae2926e20..44cad046f272 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -301,13 +301,13 @@ config DB8500_THERMAL
 	  thermal zone if trip points reached.
 
 config ARMADA_THERMAL
-	tristate "Armada 370/XP thermal management"
+	tristate "Armada 370/XP/7K/8K thermal management"
 	depends on ARCH_MVEBU || COMPILE_TEST
 	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Enable this option if you want to have support for thermal management
-	  controller present in Armada 370 and Armada XP SoC.
+	  controller present in Armada 370, Armada XP, Armada 7K/8K SoCs.
 
 config DA9062_THERMAL
 	tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f5c911524656..da58a8961a37 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -403,5 +403,5 @@ static struct platform_driver armada_thermal_driver = {
 module_platform_driver(armada_thermal_driver);
 
 MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
-MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_DESCRIPTION("Armada SoCs thermal driver");
 MODULE_LICENSE("GPL v2");
-- 
2.11.0

Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Update Armada thermal driver Kconfig entry as well as the driver's
> MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> eg. Armada 7K and Armada 8K.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/thermal/Kconfig          | 4 ++--
>  drivers/thermal/armada_thermal.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 315ae2926e20..44cad046f272 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -301,13 +301,13 @@ config DB8500_THERMAL
>  	  thermal zone if trip points reached.
>  
>  config ARMADA_THERMAL
> -	tristate "Armada 370/XP thermal management"
> +	tristate "Armada 370/XP/7K/8K thermal management"
if you want to be exhaustive you should also add Armada 375 and 38x.

>  	depends on ARCH_MVEBU || COMPILE_TEST
>  	depends on HAS_IOMEM
>  	depends on OF
>  	help
>  	  Enable this option if you want to have support for thermal management
> -	  controller present in Armada 370 and Armada XP SoC.
> +	  controller present in Armada 370, Armada XP, Armada 7K/8K
> SoCs.

here as well.

Gregory

>  
>  config DA9062_THERMAL
>  	tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index f5c911524656..da58a8961a37 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -403,5 +403,5 @@ static struct platform_driver armada_thermal_driver = {
>  module_platform_driver(armada_thermal_driver);
>  
>  MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
> -MODULE_DESCRIPTION("Armada 370/XP thermal driver");
> +MODULE_DESCRIPTION("Armada SoCs thermal driver");
>  MODULE_LICENSE("GPL v2");
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> Update Armada thermal driver Kconfig entry as well as the driver's
> MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> eg. Armada 7K and Armada 8K.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/Kconfig          | 4 ++--
>  drivers/thermal/armada_thermal.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 315ae2926e20..44cad046f272 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -301,13 +301,13 @@ config DB8500_THERMAL
>  	  thermal zone if trip points reached.
>  
>  config ARMADA_THERMAL
> -	tristate "Armada 370/XP thermal management"
> +	tristate "Armada 370/XP/7K/8K thermal management"
if you want to be exhaustive you should also add Armada 375 and 38x.

>  	depends on ARCH_MVEBU || COMPILE_TEST
>  	depends on HAS_IOMEM
>  	depends on OF
>  	help
>  	  Enable this option if you want to have support for thermal management
> -	  controller present in Armada 370 and Armada XP SoC.
> +	  controller present in Armada 370, Armada XP, Armada 7K/8K
> SoCs.

here as well.

Gregory

>  
>  config DA9062_THERMAL
>  	tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index f5c911524656..da58a8961a37 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -403,5 +403,5 @@ static struct platform_driver armada_thermal_driver = {
>  module_platform_driver(armada_thermal_driver);
>  
>  MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
> -MODULE_DESCRIPTION("Armada 370/XP thermal driver");
> +MODULE_DESCRIPTION("Armada SoCs thermal driver");
>  MODULE_LICENSE("GPL v2");
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel RAYNAL]

Hi Gregory,

On Thu, 14 Dec 2017 12:13:51 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi Miquel,
>  
>  On jeu., déc. 14 2017, Miquel Raynal
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> 
> > Update Armada thermal driver Kconfig entry as well as the driver's
> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> > eg. Armada 7K and Armada 8K.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> >  drivers/thermal/Kconfig          | 4 ++--
> >  drivers/thermal/armada_thermal.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 315ae2926e20..44cad046f272 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
> >  	  thermal zone if trip points reached.
> >  
> >  config ARMADA_THERMAL
> > -	tristate "Armada 370/XP thermal management"
> > +	tristate "Armada 370/XP/7K/8K thermal management"  
> if you want to be exhaustive you should also add Armada 375 and 38x.

That is right, both are missing from the description, but wouldn't it
be better to just state "Armada SoCs" instead of patching that file
everythime a new SoC reuses this IP?

Thanks,
Miquèl

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel RAYNAL]

Hi Gregory,

On Thu, 14 Dec 2017 12:13:51 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., d?c. 14 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
> 
> > Update Armada thermal driver Kconfig entry as well as the driver's
> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> > eg. Armada 7K and Armada 8K.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  drivers/thermal/Kconfig          | 4 ++--
> >  drivers/thermal/armada_thermal.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 315ae2926e20..44cad046f272 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
> >  	  thermal zone if trip points reached.
> >  
> >  config ARMADA_THERMAL
> > -	tristate "Armada 370/XP thermal management"
> > +	tristate "Armada 370/XP/7K/8K thermal management"  
> if you want to be exhaustive you should also add Armada 375 and 38x.

That is right, both are missing from the description, but wouldn't it
be better to just state "Armada SoCs" instead of patching that file
everythime a new SoC reuses this IP?

Thanks,
Miqu?l

Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> Hi Gregory,
>
> On Thu, 14 Dec 2017 12:13:51 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi Miquel,
>>  
>>  On jeu., déc. 14 2017, Miquel Raynal
>> <miquel.raynal@free-electrons.com> wrote:
>> 
>> > Update Armada thermal driver Kconfig entry as well as the driver's
>> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
>> > eg. Armada 7K and Armada 8K.
>> >
>> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>> > ---
>> >  drivers/thermal/Kconfig          | 4 ++--
>> >  drivers/thermal/armada_thermal.c | 2 +-
>> >  2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index 315ae2926e20..44cad046f272 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
>> >  	  thermal zone if trip points reached.
>> >  
>> >  config ARMADA_THERMAL
>> > -	tristate "Armada 370/XP thermal management"
>> > +	tristate "Armada 370/XP/7K/8K thermal management"  
>> if you want to be exhaustive you should also add Armada 375 and 38x.
>
> That is right, both are missing from the description, but wouldn't it
> be better to just state "Armada SoCs" instead of patching that file
> everythime a new SoC reuses this IP?

Unfortunately Armada SoCs is more that just these SoC!

Have a look on Documentation/arm/Marvell/README to see how the Marvell
marketing guys had been creative :)

Some kirkwood are called Armada 300 and Armada 310.
The Dove is also called Armada 510.
Some PXA are called Armada too such as Armada 168 or Armada 610.
And finally the Berlin also use Aramda as code name: Armada 1000 or
Aramda 1500

Gregory

>
> Thanks,
> Miquèl
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> Hi Gregory,
>
> On Thu, 14 Dec 2017 12:13:51 +0100
> Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi Miquel,
>>  
>>  On jeu., d?c. 14 2017, Miquel Raynal
>> <miquel.raynal@free-electrons.com> wrote:
>> 
>> > Update Armada thermal driver Kconfig entry as well as the driver's
>> > MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
>> > eg. Armada 7K and Armada 8K.
>> >
>> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>> > ---
>> >  drivers/thermal/Kconfig          | 4 ++--
>> >  drivers/thermal/armada_thermal.c | 2 +-
>> >  2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index 315ae2926e20..44cad046f272 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
>> >  	  thermal zone if trip points reached.
>> >  
>> >  config ARMADA_THERMAL
>> > -	tristate "Armada 370/XP thermal management"
>> > +	tristate "Armada 370/XP/7K/8K thermal management"  
>> if you want to be exhaustive you should also add Armada 375 and 38x.
>
> That is right, both are missing from the description, but wouldn't it
> be better to just state "Armada SoCs" instead of patching that file
> everythime a new SoC reuses this IP?

Unfortunately Armada SoCs is more that just these SoC!

Have a look on Documentation/arm/Marvell/README to see how the Marvell
marketing guys had been creative :)

Some kirkwood are called Armada 300 and Armada 310.
The Dove is also called Armada 510.
Some PXA are called Armada too such as Armada 168 or Armada 610.
And finally the Berlin also use Aramda as code name: Armada 1000 or
Aramda 1500

Gregory

>
> Thanks,
> Miqu?l
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel RAYNAL]

Hi Gregory,

On Thu, 14 Dec 2017 12:30:08 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., déc. 14 2017, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> 
> > Hi Gregory,
> >
> > On Thu, 14 Dec 2017 12:13:51 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >  
> >> Hi Miquel,
> >>  
> >>  On jeu., déc. 14 2017, Miquel Raynal
> >> <miquel.raynal@free-electrons.com> wrote:
> >>   
> >> > Update Armada thermal driver Kconfig entry as well as the
> >> > driver's MODULE_DESCRIPTION content, now that 64-bit SoCs are
> >> > also supported, eg. Armada 7K and Armada 8K.
> >> >
> >> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> >> > ---
> >> >  drivers/thermal/Kconfig          | 4 ++--
> >> >  drivers/thermal/armada_thermal.c | 2 +-
> >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> >> > index 315ae2926e20..44cad046f272 100644
> >> > --- a/drivers/thermal/Kconfig
> >> > +++ b/drivers/thermal/Kconfig
> >> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
> >> >  	  thermal zone if trip points reached.
> >> >  
> >> >  config ARMADA_THERMAL
> >> > -	tristate "Armada 370/XP thermal management"
> >> > +	tristate "Armada 370/XP/7K/8K thermal management"    
> >> if you want to be exhaustive you should also add Armada 375 and
> >> 38x.  
> >
> > That is right, both are missing from the description, but wouldn't
> > it be better to just state "Armada SoCs" instead of patching that
> > file everythime a new SoC reuses this IP?  
> 
> Unfortunately Armada SoCs is more that just these SoC!
> 
> Have a look on Documentation/arm/Marvell/README to see how the Marvell
> marketing guys had been creative :)
> 
> Some kirkwood are called Armada 300 and Armada 310.
> The Dove is also called Armada 510.
> Some PXA are called Armada too such as Armada 168 or Armada 610.
> And finally the Berlin also use Aramda as code name: Armada 1000 or
> Aramda 1500

Ehr...

Ok, I'll stick to "Armada 37x/38x/XP/7K/8K SoCs".


Miquèl

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Miquel RAYNAL]

Hi Gregory,

On Thu, 14 Dec 2017 12:30:08 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., d?c. 14 2017, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> 
> > Hi Gregory,
> >
> > On Thu, 14 Dec 2017 12:13:51 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >  
> >> Hi Miquel,
> >>  
> >>  On jeu., d?c. 14 2017, Miquel Raynal
> >> <miquel.raynal@free-electrons.com> wrote:
> >>   
> >> > Update Armada thermal driver Kconfig entry as well as the
> >> > driver's MODULE_DESCRIPTION content, now that 64-bit SoCs are
> >> > also supported, eg. Armada 7K and Armada 8K.
> >> >
> >> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> >> > ---
> >> >  drivers/thermal/Kconfig          | 4 ++--
> >> >  drivers/thermal/armada_thermal.c | 2 +-
> >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> >> > index 315ae2926e20..44cad046f272 100644
> >> > --- a/drivers/thermal/Kconfig
> >> > +++ b/drivers/thermal/Kconfig
> >> > @@ -301,13 +301,13 @@ config DB8500_THERMAL
> >> >  	  thermal zone if trip points reached.
> >> >  
> >> >  config ARMADA_THERMAL
> >> > -	tristate "Armada 370/XP thermal management"
> >> > +	tristate "Armada 370/XP/7K/8K thermal management"    
> >> if you want to be exhaustive you should also add Armada 375 and
> >> 38x.  
> >
> > That is right, both are missing from the description, but wouldn't
> > it be better to just state "Armada SoCs" instead of patching that
> > file everythime a new SoC reuses this IP?  
> 
> Unfortunately Armada SoCs is more that just these SoC!
> 
> Have a look on Documentation/arm/Marvell/README to see how the Marvell
> marketing guys had been creative :)
> 
> Some kirkwood are called Armada 300 and Armada 310.
> The Dove is also called Armada 510.
> Some PXA are called Armada too such as Armada 168 or Armada 610.
> And finally the Berlin also use Aramda as code name: Armada 1000 or
> Aramda 1500

Ehr...

Ok, I'll stick to "Armada 37x/38x/XP/7K/8K SoCs".


Miqu?l

Re: [PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Thomas Petazzoni]

Hello,

On Thu, 14 Dec 2017 12:30:08 +0100, Gregory CLEMENT wrote:

> Unfortunately Armada SoCs is more that just these SoC!
> 
> Have a look on Documentation/arm/Marvell/README to see how the Marvell
> marketing guys had been creative :)
> 
> Some kirkwood are called Armada 300 and Armada 310.
> The Dove is also called Armada 510.
> Some PXA are called Armada too such as Armada 168 or Armada 610.
> And finally the Berlin also use Aramda as code name: Armada 1000 or
> Aramda 1500

However: "Marvell EBU Armada" should be distinctive enough.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v3 07/11] thermal: armada: Update Kconfig and module description

[Thomas Petazzoni]

Hello,

On Thu, 14 Dec 2017 12:30:08 +0100, Gregory CLEMENT wrote:

> Unfortunately Armada SoCs is more that just these SoC!
> 
> Have a look on Documentation/arm/Marvell/README to see how the Marvell
> marketing guys had been creative :)
> 
> Some kirkwood are called Armada 300 and Armada 310.
> The Dove is also called Armada 510.
> Some PXA are called Armada too such as Armada 168 or Armada 610.
> And finally the Berlin also use Aramda as code name: Armada 1000 or
> Aramda 1500

However: "Marvell EBU Armada" should be distinctive enough.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Miquel Raynal]

The thermal core will check for sensors validity right after the
initialization callback has returned. As the initialization routine make
a reset, the sensors are not ready immediately and the core spawns an
error in the dmesg. Avoid this annoying situation by polling on the
validity bit before exiting from these routines. This also avoid the use
of blind sleeps.

Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index be141ca53e83..1c4122f7377c 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -23,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
 #include <linux/thermal.h>
+#include <linux/iopoll.h>
 
 /* Thermal Manager Control and Status Register */
 #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
@@ -59,6 +60,9 @@
 #define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
 #define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
 
+#define STATUS_POLL_PERIOD_US		1000
+#define STATUS_POLL_TIMEOUT_US		100000
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -154,6 +158,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
 	msleep(50);
 }
 
+static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
+{
+	u32 reg;
+
+	readl_relaxed_poll_timeout(priv->status, reg,
+				   reg & priv->data->is_valid_bit,
+				   STATUS_POLL_PERIOD_US,
+				   STATUS_POLL_TIMEOUT_US);
+}
+
 static void armada380_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
@@ -163,7 +177,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
 	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
 	writel(reg, priv->control1);
-	msleep(10);
 
 	/* Set Tsen Tc Trim to correct default value (errata #132698) */
 	if (priv->control0) {
@@ -171,8 +184,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
 		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
 		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
 		writel(reg, priv->control0);
-		msleep(10);
 	}
+
+	/* Wait the sensors to be valid or the core will warn the user */
+	armada_wait_sensor_validity(priv);
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -190,7 +205,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
 	reg &= ~CONTROL0_TSEN_RESET;
 	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
 	writel(reg, priv->control0);
-	msleep(10);
+
+	/* Wait the sensors to be valid or the core will warn the user */
+	armada_wait_sensor_validity(priv);
 }
 
 static bool armada_is_valid(struct armada_thermal_priv *priv)
-- 
2.11.0

[PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Miquel Raynal]

The thermal core will check for sensors validity right after the
initialization callback has returned. As the initialization routine make
a reset, the sensors are not ready immediately and the core spawns an
error in the dmesg. Avoid this annoying situation by polling on the
validity bit before exiting from these routines. This also avoid the use
of blind sleeps.

Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index be141ca53e83..1c4122f7377c 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -23,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/of_device.h>
 #include <linux/thermal.h>
+#include <linux/iopoll.h>
 
 /* Thermal Manager Control and Status Register */
 #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
@@ -59,6 +60,9 @@
 #define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
 #define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
 
+#define STATUS_POLL_PERIOD_US		1000
+#define STATUS_POLL_TIMEOUT_US		100000
+
 struct armada_thermal_data;
 
 /* Marvell EBU Thermal Sensor Dev Structure */
@@ -154,6 +158,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
 	msleep(50);
 }
 
+static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
+{
+	u32 reg;
+
+	readl_relaxed_poll_timeout(priv->status, reg,
+				   reg & priv->data->is_valid_bit,
+				   STATUS_POLL_PERIOD_US,
+				   STATUS_POLL_TIMEOUT_US);
+}
+
 static void armada380_init_sensor(struct platform_device *pdev,
 				  struct armada_thermal_priv *priv)
 {
@@ -163,7 +177,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
 	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
 	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
 	writel(reg, priv->control1);
-	msleep(10);
 
 	/* Set Tsen Tc Trim to correct default value (errata #132698) */
 	if (priv->control0) {
@@ -171,8 +184,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
 		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
 		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
 		writel(reg, priv->control0);
-		msleep(10);
 	}
+
+	/* Wait the sensors to be valid or the core will warn the user */
+	armada_wait_sensor_validity(priv);
 }
 
 static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -190,7 +205,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
 	reg &= ~CONTROL0_TSEN_RESET;
 	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
 	writel(reg, priv->control0);
-	msleep(10);
+
+	/* Wait the sensors to be valid or the core will warn the user */
+	armada_wait_sensor_validity(priv);
 }
 
 static bool armada_is_valid(struct armada_thermal_priv *priv)
-- 
2.11.0

Re: [PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., déc. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> The thermal core will check for sensors validity right after the
> initialization callback has returned. As the initialization routine make
> a reset, the sensors are not ready immediately and the core spawns an
> error in the dmesg. Avoid this annoying situation by polling on the
> validity bit before exiting from these routines. This also avoid the use
> of blind sleeps.

You only modified the armada 380 and ap806 init function. Does it means
that this feature is not supported on the other variant?

Gregory

>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index be141ca53e83..1c4122f7377c 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -23,6 +23,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
> +#include <linux/iopoll.h>
>  
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
> @@ -59,6 +60,9 @@
>  #define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
>  #define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
>  
> +#define STATUS_POLL_PERIOD_US		1000
> +#define STATUS_POLL_TIMEOUT_US		100000
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -154,6 +158,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
>  	msleep(50);
>  }
>  
> +static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	readl_relaxed_poll_timeout(priv->status, reg,
> +				   reg & priv->data->is_valid_bit,
> +				   STATUS_POLL_PERIOD_US,
> +				   STATUS_POLL_TIMEOUT_US);
> +}
> +
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> @@ -163,7 +177,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
>  	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
>  	writel(reg, priv->control1);
> -	msleep(10);
>  
>  	/* Set Tsen Tc Trim to correct default value (errata #132698) */
>  	if (priv->control0) {
> @@ -171,8 +184,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
>  		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
>  		writel(reg, priv->control0);
> -		msleep(10);
>  	}
> +
> +	/* Wait the sensors to be valid or the core will warn the user */
> +	armada_wait_sensor_validity(priv);
>  }
>  
>  static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -190,7 +205,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
>  	reg &= ~CONTROL0_TSEN_RESET;
>  	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
>  	writel(reg, priv->control0);
> -	msleep(10);
> +
> +	/* Wait the sensors to be valid or the core will warn the user */
> +	armada_wait_sensor_validity(priv);
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Gregory CLEMENT]

Hi Miquel,
 
 On jeu., d?c. 14 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:

> The thermal core will check for sensors validity right after the
> initialization callback has returned. As the initialization routine make
> a reset, the sensors are not ready immediately and the core spawns an
> error in the dmesg. Avoid this annoying situation by polling on the
> validity bit before exiting from these routines. This also avoid the use
> of blind sleeps.

You only modified the armada 380 and ap806 init function. Does it means
that this feature is not supported on the other variant?

Gregory

>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
>  drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index be141ca53e83..1c4122f7377c 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -23,6 +23,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
>  #include <linux/thermal.h>
> +#include <linux/iopoll.h>
>  
>  /* Thermal Manager Control and Status Register */
>  #define PMU_TDC0_SW_RST_MASK		(0x1 << 1)
> @@ -59,6 +60,9 @@
>  #define CONTROL1_EXT_TSEN_SW_RESET	BIT(7)
>  #define CONTROL1_EXT_TSEN_HW_RESETn	BIT(8)
>  
> +#define STATUS_POLL_PERIOD_US		1000
> +#define STATUS_POLL_TIMEOUT_US		100000
> +
>  struct armada_thermal_data;
>  
>  /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -154,6 +158,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
>  	msleep(50);
>  }
>  
> +static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
> +{
> +	u32 reg;
> +
> +	readl_relaxed_poll_timeout(priv->status, reg,
> +				   reg & priv->data->is_valid_bit,
> +				   STATUS_POLL_PERIOD_US,
> +				   STATUS_POLL_TIMEOUT_US);
> +}
> +
>  static void armada380_init_sensor(struct platform_device *pdev,
>  				  struct armada_thermal_priv *priv)
>  {
> @@ -163,7 +177,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  	reg |= CONTROL1_EXT_TSEN_HW_RESETn;
>  	reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
>  	writel(reg, priv->control1);
> -	msleep(10);
>  
>  	/* Set Tsen Tc Trim to correct default value (errata #132698) */
>  	if (priv->control0) {
> @@ -171,8 +184,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
>  		reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
>  		reg |= CONTROL0_TSEN_TC_TRIM_VAL;
>  		writel(reg, priv->control0);
> -		msleep(10);
>  	}
> +
> +	/* Wait the sensors to be valid or the core will warn the user */
> +	armada_wait_sensor_validity(priv);
>  }
>  
>  static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -190,7 +205,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
>  	reg &= ~CONTROL0_TSEN_RESET;
>  	reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
>  	writel(reg, priv->control0);
> -	msleep(10);
> +
> +	/* Wait the sensors to be valid or the core will warn the user */
> +	armada_wait_sensor_validity(priv);
>  }
>  
>  static bool armada_is_valid(struct armada_thermal_priv *priv)
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:23:11 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., déc. 14 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
> 
> > The thermal core will check for sensors validity right after the
> > initialization callback has returned. As the initialization routine
> > make a reset, the sensors are not ready immediately and the core
> > spawns an error in the dmesg. Avoid this annoying situation by
> > polling on the validity bit before exiting from these routines.
> > This also avoid the use of blind sleeps.  
> 
> You only modified the armada 380 and ap806 init function. Does it
> means that this feature is not supported on the other variant?

I can't tell for other boards, It does not seem they actually need it
so I did not hacked their init callback. Should I? IMOH, if there is
not problem, there is no fix to add neither.

Miquèl

[PATCH v3 09/11] thermal: armada: Wait sensors validity before exiting the init callback

[Miquel RAYNAL]

On Thu, 14 Dec 2017 12:23:11 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Miquel,
>  
>  On jeu., d?c. 14 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
> 
> > The thermal core will check for sensors validity right after the
> > initialization callback has returned. As the initialization routine
> > make a reset, the sensors are not ready immediately and the core
> > spawns an error in the dmesg. Avoid this annoying situation by
> > polling on the validity bit before exiting from these routines.
> > This also avoid the use of blind sleeps.  
> 
> You only modified the armada 380 and ap806 init function. Does it
> means that this feature is not supported on the other variant?

I can't tell for other boards, It does not seem they actually need it
so I did not hacked their init callback. Should I? IMOH, if there is
not problem, there is no fix to add neither.

Miqu?l

[PATCH v3 10/11] thermal: armada: Give useful names to the thermal zone

[Miquel Raynal]

After registration to the thermal core, sysfs will make one entry
per instance of the driver in /sys/class/thermal_zoneX and
/sys/class/hwmon/hwmonX, X being the index of the instance, all of them
having the type/name "armada_thermal".

Until now there was only one thermal zone per SoC but SoCs like Armada
A7K and Armada A8K have respectively two and three thermal zones (one
per AP and one per CP) and this number is subject to grow in the future.

Because there is no easy way to name them effectively, use the new DT
property "marvell,thermal-zone-name" if it is available.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 1c4122f7377c..b31d03dde44b 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -357,6 +357,8 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
 
 static int armada_thermal_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
+	const char *zone_name = "armada_thermal";
 	void __iomem *control = NULL;
 	struct thermal_zone_device *thermal;
 	const struct of_device_id *match;
@@ -398,8 +400,14 @@ static int armada_thermal_probe(struct platform_device *pdev)
 	priv->data = (struct armada_thermal_data *)match->data;
 	priv->data->init_sensor(pdev, priv);
 
-	thermal = thermal_zone_device_register("armada_thermal", 0, 0,
-					       priv, &ops, NULL, 0, 0);
+	/*
+	 * Some platforms use several instances of this driver without any way
+	 * to identify them. Use a new property to gave the thermal zone name a
+	 * valid meaning (used by hwmon too).
+	 */
+	of_property_read_string(np, "marvell,thermal-zone-name", &zone_name);
+	thermal = thermal_zone_device_register(zone_name, 0, 0, priv, &ops,
+					       NULL, 0, 0);
 	if (IS_ERR(thermal)) {
 		dev_err(&pdev->dev,
 			"Failed to register thermal zone device\n");
-- 
2.11.0

[PATCH v3 10/11] thermal: armada: Give useful names to the thermal zone

[Miquel Raynal]

After registration to the thermal core, sysfs will make one entry
per instance of the driver in /sys/class/thermal_zoneX and
/sys/class/hwmon/hwmonX, X being the index of the instance, all of them
having the type/name "armada_thermal".

Until now there was only one thermal zone per SoC but SoCs like Armada
A7K and Armada A8K have respectively two and three thermal zones (one
per AP and one per CP) and this number is subject to grow in the future.

Because there is no easy way to name them effectively, use the new DT
property "marvell,thermal-zone-name" if it is available.

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 drivers/thermal/armada_thermal.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 1c4122f7377c..b31d03dde44b 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -357,6 +357,8 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
 
 static int armada_thermal_probe(struct platform_device *pdev)
 {
+	struct device_node *np = pdev->dev.of_node;
+	const char *zone_name = "armada_thermal";
 	void __iomem *control = NULL;
 	struct thermal_zone_device *thermal;
 	const struct of_device_id *match;
@@ -398,8 +400,14 @@ static int armada_thermal_probe(struct platform_device *pdev)
 	priv->data = (struct armada_thermal_data *)match->data;
 	priv->data->init_sensor(pdev, priv);
 
-	thermal = thermal_zone_device_register("armada_thermal", 0, 0,
-					       priv, &ops, NULL, 0, 0);
+	/*
+	 * Some platforms use several instances of this driver without any way
+	 * to identify them. Use a new property to gave the thermal zone name a
+	 * valid meaning (used by hwmon too).
+	 */
+	of_property_read_string(np, "marvell,thermal-zone-name", &zone_name);
+	thermal = thermal_zone_device_register(zone_name, 0, 0, priv, &ops,
+					       NULL, 0, 0);
 	if (IS_ERR(thermal)) {
 		dev_err(&pdev->dev,
 			"Failed to register thermal zone device\n");
-- 
2.11.0

[PATCH v3 11/11] ARM64: dts: marvell: Add thermal support for A7K/A8K

[Miquel Raynal]

Add thermal DT nodes in AP806 and CP110 master/slave DTSI files.

Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi        | 7 +++++++
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 7 +++++++
 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi  | 7 +++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 1c4dd8ab9ad5..ceda98a4f8cc 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -285,6 +285,13 @@
 					gpio-ranges = <&ap_pinctrl 0 0 20>;
 				};
 			};
+
+			ap_thermal: thermal@6f808C {
+				compatible = "marvell,armada-ap806-thermal";
+				reg = <0x6f808C 0x4>,
+				      <0x6f8084 0x8>;
+				marvell,thermal-zone-name = "ap_thermal_zone";
+			};
 		};
 	};
 };
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index e3b64d03fbd8..0dc92897fd7c 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -182,6 +182,13 @@
 				interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
+			cpm_thermal: thermal@400078 {
+				compatible = "marvell,armada-cp110-thermal";
+				reg = <0x400078 0x4>,
+				      <0x400070 0x8>;
+				marvell,thermal-zone-name = "cp0_thermal_zone";
+			};
+
 			cpm_syscon0: system-controller@440000 {
 				compatible = "syscon", "simple-mfd";
 				reg = <0x440000 0x2000>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 0d51096c69f8..5a7589a90db1 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -182,6 +182,13 @@
 				interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
+			cps_thermal: thermal@400078 {
+				compatible = "marvell,armada-cp110-thermal";
+				reg = <0x400078 0x4>,
+				      <0x400070 0x8>;
+				marvell,thermal-zone-name = "cp1_thermal_zone";
+			};
+
 			cps_syscon0: system-controller@440000 {
 				compatible = "syscon", "simple-mfd";
 				reg = <0x440000 0x2000>;
-- 
2.11.0

[PATCH v3 11/11] ARM64: dts: marvell: Add thermal support for A7K/A8K

[Miquel Raynal]

Add thermal DT nodes in AP806 and CP110 master/slave DTSI files.

Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi        | 7 +++++++
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 7 +++++++
 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi  | 7 +++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 1c4dd8ab9ad5..ceda98a4f8cc 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -285,6 +285,13 @@
 					gpio-ranges = <&ap_pinctrl 0 0 20>;
 				};
 			};
+
+			ap_thermal: thermal at 6f808C {
+				compatible = "marvell,armada-ap806-thermal";
+				reg = <0x6f808C 0x4>,
+				      <0x6f8084 0x8>;
+				marvell,thermal-zone-name = "ap_thermal_zone";
+			};
 		};
 	};
 };
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index e3b64d03fbd8..0dc92897fd7c 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -182,6 +182,13 @@
 				interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
+			cpm_thermal: thermal at 400078 {
+				compatible = "marvell,armada-cp110-thermal";
+				reg = <0x400078 0x4>,
+				      <0x400070 0x8>;
+				marvell,thermal-zone-name = "cp0_thermal_zone";
+			};
+
 			cpm_syscon0: system-controller at 440000 {
 				compatible = "syscon", "simple-mfd";
 				reg = <0x440000 0x2000>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 0d51096c69f8..5a7589a90db1 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -182,6 +182,13 @@
 				interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
+			cps_thermal: thermal at 400078 {
+				compatible = "marvell,armada-cp110-thermal";
+				reg = <0x400078 0x4>,
+				      <0x400070 0x8>;
+				marvell,thermal-zone-name = "cp1_thermal_zone";
+			};
+
 			cps_syscon0: system-controller at 440000 {
 				compatible = "syscon", "simple-mfd";
 				reg = <0x440000 0x2000>;
-- 
2.11.0