[PATCH v2 0/2] arm64: dts: r8a779[56]: update register size for thermal

[PATCH v2 0/2] arm64: dts: r8a779[56]: update register size for thermal

[Niklas Söderlund]

Hi,

This series updates the register size for the thermal hardware. In later
versions of the datasheet one additional register is documented. This
register is needed to be able to determine if calibration data should be
read from register or if static values from the driver should be used.

There is already a posted RFC patch which make use of this additional
register (THSCP) if the register size described in DT covers it.
Currently no hardware where the calibration value is fused have been
found so that patch is not tested and therefore kept back until such a
system is found. In the mean time there is no harm in getting the
correct register size described in DT now that it's documented in the
datasheet (Rev 0.80).

* Changes since v1
- Increase size from just covering the new register in TSC1 to
  increasing the size of all TSC's to 0x100 which is the smallest
  granularity of the address decoder circuitry. Suggested by Geert.

Niklas Söderlund (2):
  arm64: dts: r8a7795: update register size for thermal
  arm64: dts: r8a7796: update register size for thermal

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.15.1

--
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 v2 1/2] arm64: dts: r8a7795: update register size for thermal

[Niklas Söderlund]

To be able to read fused calibration values from hardware the size of
the register resource of TSC1 needs to be incremented to cover one more
register which holds the information if the calibration values have been
fused or not.

Instead of increasing TSC1 size to the value from the datasheet update
all TSC's size to the smallest granularity of the address decoder
circuitry

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 19b7de57704c67e8..ce85704976f0d3ef 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2385,9 +2385,9 @@
 
 		tsc: thermal@e6198000 {
 			compatible = "renesas,r8a7795-thermal";
-			reg = <0 0xe6198000 0 0x68>,
-			      <0 0xe61a0000 0 0x5c>,
-			      <0 0xe61a8000 0 0x5c>;
+			reg = <0 0xe6198000 0 0x100>,
+			      <0 0xe61a0000 0 0x100>,
+			      <0 0xe61a8000 0 0x100>;
 			interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.15.1

[PATCH v2 2/2] arm64: dts: r8a7796: update register size for thermal

[Niklas Söderlund]

To be able to read fused calibration values from hardware the size of
the register resource of TSC1 needs to be incremented to cover one more
register which holds the information if the calibration values have been
fused or not.

Instead of increasing TSC1 size to the value from the datasheet update
all TSC's size to the smallest granularity of the address decoder
circuitry.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index ef10fb548681d36a..f8e9313f9405b938 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1625,9 +1625,9 @@
 
 		tsc: thermal@e6198000 {
 			compatible = "renesas,r8a7796-thermal";
-			reg = <0 0xe6198000 0 0x68>,
-			      <0 0xe61a0000 0 0x5c>,
-			      <0 0xe61a8000 0 0x5c>;
+			reg = <0 0xe6198000 0 0x100>,
+			      <0 0xe61a0000 0 0x100>,
+			      <0 0xe61a8000 0 0x100>;
 			interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.15.1

Re: [PATCH v2 0/2] arm64: dts: r8a779[56]: update register size for thermal

[Simon Horman]

On Fri, Jan 05, 2018 at 04:54:45PM +0100, Niklas Söderlund wrote:
> Hi,
> 
> This series updates the register size for the thermal hardware. In later
> versions of the datasheet one additional register is documented. This
> register is needed to be able to determine if calibration data should be
> read from register or if static values from the driver should be used.
> 
> There is already a posted RFC patch which make use of this additional
> register (THSCP) if the register size described in DT covers it.
> Currently no hardware where the calibration value is fused have been
> found so that patch is not tested and therefore kept back until such a
> system is found. In the mean time there is no harm in getting the
> correct register size described in DT now that it's documented in the
> datasheet (Rev 0.80).
> 
> * Changes since v1
> - Increase size from just covering the new register in TSC1 to
>   increasing the size of all TSC's to 0x100 which is the smallest
>   granularity of the address decoder circuitry. Suggested by Geert.
> 
> Niklas Söderlund (2):
>   arm64: dts: r8a7795: update register size for thermal
>   arm64: dts: r8a7796: update register size for thermal

Applied, but this seems to go in the opposite direction of:

846106d9d973 ("ARM: dts: r8a7793: Reduce size of thermal registers")
1af62038f499 ("ARM: dts: r8a7791: Reduce size of thermal registers")
d0191d85a237 ("ARM: dts: r8a7790: Reduce size of thermal registers")

Should those patches be dropped and the register areas grown to 0x100
instead?

Re: [PATCH v2 0/2] arm64: dts: r8a779[56]: update register size for thermal

[Geert Uytterhoeven]

Hi Simon,

On Mon, Jan 8, 2018 at 7:59 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Fri, Jan 05, 2018 at 04:54:45PM +0100, Niklas Söderlund wrote:
>> This series updates the register size for the thermal hardware. In later
>> versions of the datasheet one additional register is documented. This
>> register is needed to be able to determine if calibration data should be
>> read from register or if static values from the driver should be used.
>>
>> There is already a posted RFC patch which make use of this additional
>> register (THSCP) if the register size described in DT covers it.
>> Currently no hardware where the calibration value is fused have been
>> found so that patch is not tested and therefore kept back until such a
>> system is found. In the mean time there is no harm in getting the
>> correct register size described in DT now that it's documented in the
>> datasheet (Rev 0.80).
>>
>> * Changes since v1
>> - Increase size from just covering the new register in TSC1 to
>>   increasing the size of all TSC's to 0x100 which is the smallest
>>   granularity of the address decoder circuitry. Suggested by Geert.
>>
>> Niklas Söderlund (2):
>>   arm64: dts: r8a7795: update register size for thermal
>>   arm64: dts: r8a7796: update register size for thermal
>
> Applied, but this seems to go in the opposite direction of:
>
> 846106d9d973 ("ARM: dts: r8a7793: Reduce size of thermal registers")
> 1af62038f499 ("ARM: dts: r8a7791: Reduce size of thermal registers")
> d0191d85a237 ("ARM: dts: r8a7790: Reduce size of thermal registers")
>
> Should those patches be dropped and the register areas grown to 0x100
> instead?

There are two "policies" to specify register block lengths:
  1. Cover all registers documented in the datasheet, and nothing more (at the
   low/high end),
  2. Use a power-of-two that covers all registers, which is most probably
    what matches the actual address decoder in the hardware.

Of course, we all know datasheets are volatile, and registers may appear or
disappear any time ;-)

In reality, ioremap() granularity is PAGE_SIZE, which is also a power-of-two.

So personally, I'm more leaning towards policy #2.

The 3 commits you refer to use policy #1, but covered a register not
documented in the datasheet.

Note that some drivers (SD?) use the register block lengths to check if a
feature is available or not. Ideally they should use the compatible value
instead.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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