From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Luca Weiss" <luca.weiss@fairphone.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Daniel Lezcano" <daniel.lezcano@linaro.org>,
"Zhang Rui" <rui.zhang@intel.com>,
"Lukasz Luba" <lukasz.luba@arm.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Laxman Dewangan" <ldewangan@nvidia.com>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konradybcio@kernel.org>,
"Hans de Goede" <hansg@kernel.org>,
"Jens Reidel" <adrian@mainlining.org>,
"Casey Connolly" <casey.connolly@linaro.org>
Cc: ~postmarketos/upstreaming@lists.sr.ht,
phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms
Date: Fri, 10 Oct 2025 15:40:36 +0100 [thread overview]
Message-ID: <61b5a5f43d97f700ec7fc52110a1784ef699eeaa.camel@gmail.com> (raw)
In-Reply-To: <20251010-bat-temp-adc-v1-0-d51ec895dac6@fairphone.com>
On Fri, 2025-10-10 at 13:21 +0200, Luca Weiss wrote:
> This is an RFC which implements a potential solution to get battery
> temperature readings working on for example smartphones with Qualcomm
> SoCs.
>
> The solution chosen in downstream Qualcomm kernels is exposing
> ADC_BAT_THERM_PU* in the ADC driver as temperature channels with the
> lookup table ("struct vadc_map_pt") for the specific NTC found in a
> device's battery patched to adjust the lookup table.
>
> The high level solution proposed here:
> * ADC driver provides temperature channel in (milli)volt as IIO channel
> * generic-adc-thermal driver converts voltage to temperature based on
> provided lookup table from DT (driver has one IIO channel input, one
> IIO channel output)
> * The fuel gauge driver can use that temperature IIO channel to expose
> battery temperature via the power supply device
>
> Variants/alternatives considered:
>
> 1. Do not implement IIO device in generic-adc-thermal
>
> Without an IIO channel and using thermal zone directly it becomes more
> difficult. You cannot get thermal zone by reference (e.g.
> thermal-sensors = <&foo>;). The function thermal_zone_get_zone_by_name()
> exists but lookup by name is kinda clunky. Adding by-phandle support
> might be possible but is lots of work. It also doesn't really look like
> thermal-sensor is really meant to be used by other drivers. E.g.
> there's also no "thermal-sensor-names" property to designate passing
> multiple thermal sensors. So I believe IIO is a better fitting API for
> this.
The only thing that I dislike is that using IIO just feels like hacking around
the lack of an inkernel interface (as you pointed out and which IIO provides)
for thermal devices. My main question is, what makes this device an IIO device
despite the fact that we (you) want to use the IIO inkernel API (IIUC)? AFAIU,
the sensor is already being implemented as the ADC driver and this is just
convenience.
Anyways, that said, there's precedent (at least in 2 places) about registering
IIO devices outside of the subsystem.
Maybe we need the concept of an IIO proxy for the IIO inkernel interface. Like
consumers of IIO devices that can use some the measurements (channels), do
something with them and then be IIO providers. I guess I'm already rambling :)
>
> 2. Expose IIO channel as temperature in ADC driver
>
> This would require passing in the temperature lookup table somehow to
> the ADC driver via DT. I think this passes too many details about the
> hardware that's connected into the ADC driver. While possible, at least
> for Qcom ADC there's no precedent yet.
Not really familiar with the HW setup but (just for my understanding) why it
would not make sense to pass that info to the IIO driver? I guess that table is
just not part of the ADC?
>
> 3. Add temperature-lookup-table as property to simple-battery
>
> Since the NTC is a part of the battery pack, adding a
> temperature-lookup-table property to simple-battery would make sense
> instead of having this lookup table be standalone in the
> generic-adc-thermal node. However being able to re-use the existing code
> in generic-adc-thermal lead me to the current proposal.
What about turning it into a small lib module? No idea where to put it though.
But while I was thinking about this, your option 3 looks the one that makes more
sense to me.
My 2 cents!
- Nuno Sá
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Luca Weiss (6):
> iio: adc: qcom-spmi-adc5: Add battery thermal channels
> dt-bindings: thermal: generic-adc: Document #io-channel-cells
> thermal/drivers/generic-adc: Register as IIO device
> thermal/drivers/generic-adc: Allow probe without TZ registration
> arm64: dts: qcom: pm7250b: Define battery temperature ADC channels
> arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node
>
> .../bindings/thermal/generic-adc-thermal.yaml | 4 ++
> arch/arm64/boot/dts/qcom/pm7250b.dtsi | 24 +++++++
> arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 83
> ++++++++++++++++++++++
> drivers/iio/adc/qcom-spmi-adc5.c | 6 ++
> drivers/iio/adc/qcom-vadc-common.c | 16 +++++
> drivers/thermal/thermal-generic-adc.c | 68 ++++++++++++++++--
> include/linux/iio/adc/qcom-vadc-common.h | 3 +
> 7 files changed, 198 insertions(+), 6 deletions(-)
> ---
> base-commit: 6063257da111c7639d020c5f15bfb37fb839d8b6
> change-id: 20251010-bat-temp-adc-8539bf0b85bc
>
> Best regards,
next prev parent reply other threads:[~2025-10-10 14:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-10 11:21 [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms Luca Weiss
2025-10-10 11:21 ` [PATCH RFC 1/6] iio: adc: qcom-spmi-adc5: Add battery thermal channels Luca Weiss
2025-10-10 11:22 ` [PATCH RFC 2/6] dt-bindings: thermal: generic-adc: Document #io-channel-cells Luca Weiss
2025-10-10 11:22 ` [PATCH RFC 3/6] thermal/drivers/generic-adc: Register as IIO device Luca Weiss
2025-10-12 18:41 ` Jonathan Cameron
2025-10-10 11:22 ` [PATCH RFC 4/6] thermal/drivers/generic-adc: Allow probe without TZ registration Luca Weiss
2025-10-10 11:22 ` [PATCH RFC 5/6] arm64: dts: qcom: pm7250b: Define battery temperature ADC channels Luca Weiss
2025-10-10 11:22 ` [PATCH RFC 6/6] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node Luca Weiss
2025-10-10 14:40 ` Nuno Sá [this message]
2025-10-10 20:56 ` [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms David Lechner
2025-10-11 9:52 ` Hans de Goede
2025-10-12 18:24 ` Jonathan Cameron
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=61b5a5f43d97f700ec7fc52110a1784ef699eeaa.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=adrian@mainlining.org \
--cc=andersson@kernel.org \
--cc=andy@kernel.org \
--cc=casey.connolly@linaro.org \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=hansg@kernel.org \
--cc=jic23@kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=ldewangan@nvidia.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca.weiss@fairphone.com \
--cc=lukasz.luba@arm.com \
--cc=nuno.sa@analog.com \
--cc=phone-devel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rui.zhang@intel.com \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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).