From: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
To: linux-pm@vger.kernel.org,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Khiem Nguyen <khiem.nguyen.xt@renesas.com>,
Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>
Cc: linux-renesas-soc@vger.kernel.org,
"Zhang Rui" <rui.zhang@intel.com>,
"Eduardo Valentin" <edubezval@gmail.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Subject: [PATCHv6 0/4] thermal: add driver for R-Car Gen3
Date: Thu, 22 Dec 2016 11:38:19 +0100 [thread overview]
Message-ID: <20161222103823.8300-1-niklas.soderlund+renesas@ragnatech.se> (raw)
Hi all,
The series adds thermal support to Renesas R-Car Gen3 SoCs. It's tested
on Salvator-X H3 and M3-W SoC.
Wolfram asked me to have a look at the comments for v4 and to try and
rework the temperature formulas to work with only ints and if it worked
out resend the series. I have reworked code in 2/4 but kept Wolfram as
the author and added my SoB, hope this is OK.
Reworking the formulas involved moving from s64 to int as the data type
used to store coefficients used in binary scaled fixed point
calculations. By examining the largest values which could be produced in
these calculations a shift of 7 is the maximum scaling which is
possible and still fit inside an int, previously with s64 the decimal scaling
was 1000.
Changing the decimal scaling also reduces the accuracy of the
calculations. In my tests this was hardly noticeable as the granularity
of the reported temperature to user-space is 0.5C, comparing the value
reported in the s64 vs int implementation only differ very slightly when
it rounded the value to the next 0.5C level.
However the formulas used to calculate the coefficients are not
documented and none obvious (at lest not to me) so given different
initial values to calculate the coefficients the error might become
larger. Therefore I would like to ask Morimoto-san and/or Khiem to
provide or proxy testing of this less accurate formula and feedback if
it's OK, let me know if there is anything I can do to help out.
Changes since v5
- Switch fixpoint scaling from decimal with a factor 100 to binary with
a shift of 7 bits to increase accuracy. In v5 decimal scaling was used
since it closest resembled the v4 implementation of a decimal scaling
with 1000 as a factor. The big change in v5 was to fit all
calculations inside a int instead of s64.
After discussions with Geert and Wolfram it became apparent that
disregarding what scaling method used the change in scaling to fit
inside a int needs to be reverified by Morimoto-san or Khiem so we
might as well have as much accuracy as possible.
- Dropped macro for fixed point multiplication. All uses where between a
scaled variable and a none scaled constant so upscaling the constant
just to then downscale the product where unneeded and the product
could overflow before it was downscaled.
- Change calculation of one constant (tj_2) to not be upscaled before
it's divided. This is how it's done in the BSP and it could overflow
if done with upscaled numbers. As a good side effect the final
temperature value more closely match the BSP value. This should never
have been changed to work with upscaled variables in v5.
- Rename fixed point calculation macros prefix from SCALE_ to FIXPT_
- Use DIV_ROUND_CLOSEST in FIXPT_DIV macro. In theory when PTAT and
THCODE values are read from hardware (not available yet)
DIV_ROUND_CLOSEST could be called with a negative divisor which
currently is not supported by DIV_ROUND_CLOSEST. I have submitted a
patch to fix DIV_ROUND_CLOSEST to support this '[RFC/PATCH]
linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative'. If that
patch is rejected something similar needs to be added as local code
here before PTAT and THCODE values can be read from registers.
- Add spaces between all operands in FIXPT_ macros
- Squashed patch 5/5 into 2/5.
Changes since v4:
- Use only 32 bit ints to convert from register value to temperature.
- Merge and simplify temp calculation functions.
- Document what I known about the temprature conversion formulas.
- Add new patch 5/5 which fixes a waring printout caused by trying to get
temp before hardware is ready on r8a7795.
- Fixed a few checkpatch warnings.
Wolfram Sang (4):
thermal: rcar_gen3_thermal: Document the R-Car Gen3
thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
arm64: dts: r8a7795: Add R-Car Gen3 thermal support
arm64: dts: r8a7796: Add R-Car Gen3 thermal support
.../bindings/thermal/rcar-gen3-thermal.txt | 56 ++++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 58 ++++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 58 ++++
drivers/thermal/Kconfig | 9 +
drivers/thermal/Makefile | 1 +
drivers/thermal/rcar_gen3_thermal.c | 335 +++++++++++++++++++++
6 files changed, 517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
create mode 100644 drivers/thermal/rcar_gen3_thermal.c
--
2.11.0
next reply other threads:[~2016-12-22 10:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 10:38 Niklas Söderlund [this message]
2016-12-22 10:38 ` [PATCHv6 1/4] thermal: rcar_gen3_thermal: Document the R-Car Gen3 Niklas Söderlund
2016-12-22 10:38 ` [PATCHv6 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver Niklas Söderlund
2016-12-22 10:38 ` [PATCHv6 3/4] arm64: dts: r8a7795: Add R-Car Gen3 thermal support Niklas Söderlund
2016-12-22 10:38 ` [PATCHv6 4/4] arm64: dts: r8a7796: " Niklas Söderlund
2016-12-23 11:02 ` [PATCHv6 0/4] thermal: add driver for R-Car Gen3 Wolfram Sang
2017-01-04 23:41 ` Wolfram Sang
2017-01-19 12:19 ` Wolfram Sang
2017-01-20 4:31 ` Eduardo Valentin
2017-01-20 7:13 ` Niklas Söderlund
2017-01-20 11:20 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161222103823.8300-1-niklas.soderlund+renesas@ragnatech.se \
--to=niklas.soderlund+renesas@ragnatech.se \
--cc=edubezval@gmail.com \
--cc=geert@linux-m68k.org \
--cc=khiem.nguyen.xt@renesas.com \
--cc=kuninori.morimoto.gx@gmail.com \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).