diff mbox

[2/3] iio: adc: cpcap: Fix die temperature

Message ID 20170519034035.16795-3-tony@atomide.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tony Lindgren May 19, 2017, 3:40 a.m. UTC 
It seems that "MC13783 Power Management and Audio Ciruit User's Guide"
MC1378UG.pdf documents several similar components as in the CPCAP PMIC.

Chapter "9.5.5 Die Temperature and UID" says that the die temperature
value is 282 at 25C with LSB of -1.14C. Converting CPCAP PMIC channel3
values with following seems to produce values that make sense for a
PMIC die:

temperature = 25000 + ((regval - 282) * 114)

As we don't have any other documentation, let's assume the die
temperature is unconfigured in the Motorola mapphone Linux kernel
and the current temperature conversion table should be only used
for the battery thermistor and not for the die temperature.

Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/iio/adc/cpcap-adc.c | 31 ++++++++++++++++++++++++++++---
 1 file changed, 28 insertions(+), 3 deletions(-)

Comments

Jonathan Cameron May 20, 2017, 3:55 p.m. UTC | #1 
On 19/05/17 04:40, Tony Lindgren wrote:
> It seems that "MC13783 Power Management and Audio Ciruit User's Guide"
> MC1378UG.pdf documents several similar components as in the CPCAP PMIC.
> 
> Chapter "9.5.5 Die Temperature and UID" says that the die temperature
> value is 282 at 25C with LSB of -1.14C. Converting CPCAP PMIC channel3
> values with following seems to produce values that make sense for a
> PMIC die:
> 
> temperature = 25000 + ((regval - 282) * 114)
> 
> As we don't have any other documentation, let's assume the die
> temperature is unconfigured in the Motorola mapphone Linux kernel
> and the current temperature conversion table should be only used
> for the battery thermistor and not for the die temperature.
Is there any route we have available to confirm this?  I.e. doe anyone
have one where we can check plausibility?

If not such is life, but thought I'd ask.

Code is fine as far as I can see.

Jonathan
> 
> Cc: Marcel Partap <mpartap@gmx.net>
> Cc: Michael Scott <michael.scott@linaro.org>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>   drivers/iio/adc/cpcap-adc.c | 31 ++++++++++++++++++++++++++++---
>   1 file changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
> --- a/drivers/iio/adc/cpcap-adc.c
> +++ b/drivers/iio/adc/cpcap-adc.c
> @@ -875,6 +875,22 @@ static int cpcap_adc_init_request(struct cpcap_adc_request *req,
>   	return 0;
>   }
>   
> +static int cpcap_adc_read_st_die_temp(struct cpcap_adc *ddata,
> +				      int addr, int *val)
> +{
> +	int error;
> +
> +	error = regmap_read(ddata->reg, addr, val);
> +	if (error)
> +		return error;
> +
> +	*val -= 282;
> +	*val *= 114;
> +	*val += 25000;
> +
> +	return 0;
> +}
> +
>   static int cpcap_adc_read(struct iio_dev *indio_dev,
>   			  struct iio_chan_spec const *chan,
>   			  int *val, int *val2, long mask)
> @@ -906,9 +922,18 @@ static int cpcap_adc_read(struct iio_dev *indio_dev,
>   		error = cpcap_adc_start_bank(ddata, &req);
>   		if (error)
>   			goto err_unlock;
> -		error = cpcap_adc_read_bank_scaled(ddata, &req);
> -		if (error)
> -			goto err_unlock;
> +		if ((ddata->vendor == CPCAP_VENDOR_ST) &&
> +		    (chan->channel == CPCAP_ADC_AD3)) {
> +			error = cpcap_adc_read_st_die_temp(ddata,
> +							   chan->address,
> +							   &req.result);
> +			if (error)
> +				goto err_unlock;
> +		} else {
> +			error = cpcap_adc_read_bank_scaled(ddata, &req);
> +			if (error)
> +				goto err_unlock;
> +		}
>   		error = cpcap_adc_stop_bank(ddata);
>   		if (error)
>   			goto err_unlock;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren May 20, 2017, 4:35 p.m. UTC | #2 
* Jonathan Cameron <jic23@kernel.org> [170520 08:58]:
> On 19/05/17 04:40, Tony Lindgren wrote:
> > It seems that "MC13783 Power Management and Audio Ciruit User's Guide"
> > MC1378UG.pdf documents several similar components as in the CPCAP PMIC.
> > 
> > Chapter "9.5.5 Die Temperature and UID" says that the die temperature
> > value is 282 at 25C with LSB of -1.14C. Converting CPCAP PMIC channel3
> > values with following seems to produce values that make sense for a
> > PMIC die:
> > 
> > temperature = 25000 + ((regval - 282) * 114)
> > 
> > As we don't have any other documentation, let's assume the die
> > temperature is unconfigured in the Motorola mapphone Linux kernel
> > and the current temperature conversion table should be only used
> > for the battery thermistor and not for the die temperature.
> Is there any route we have available to confirm this?  I.e. doe anyone
> have one where we can check plausibility?

Well there is also a tmp105 sensor for SoC temperature on board
that I used for some sanity checks :) For the Motorola kernel, it
seems it's doing all the interesting ADC stuff in user space for
battery estimates. So if ch3 is used, it must be using the raw
values. My guess is that ch3 is only used by the PMIC firmware to
automatically cut off power if it gets too hot.

The temperature values seem to make sense now when compared against
the tmp105 values.. The following output is from an idle device with
charger connected with reasonably full battery:

$ ./test-d4-temperature
tmp105: 37187 bat ch0: 33675 die ch3: 46888
tmp105: 37187 bat ch0: 33820 die ch3: 41074
tmp105: 37187 bat ch0: 33525 die ch3: 40390
tmp105: 37125 bat ch0: 33675 die ch3: 40162
tmp105: 37125 bat ch0: 34410 die ch3: 40048
tmp105: 37125 bat ch0: 34555 die ch3: 40162
tmp105: 37125 bat ch0: 33525 die ch3: 40390
...

Add some load with two instances of dd if=/dev/urandom of=/dev/null:

$ ./test-d4-temperature
tmp105: 44250 bat ch0: 37240 die ch3: 51790
tmp105: 44250 bat ch0: 34705 die ch3: 48940
tmp105: 44250 bat ch0: 34705 die ch3: 48484
tmp105: 44250 bat ch0: 34850 die ch3: 48370
tmp105: 44312 bat ch0: 37585 die ch3: 48142
tmp105: 44312 bat ch0: 36895 die ch3: 48484
tmp105: 44375 bat ch0: 34705 die ch3: 48484
tmp105: 44375 bat ch0: 36895 die ch3: 48484
...

So ch3 for the PMIC die temperature seems to follow the load
numbers and makes sense as it provides power to all the devices.
The first value of ch3 often is all over the map though, probably
no way around that..

The script I'm using is:

#!/bin/sh

while [ 1 ]; do
	echo -n "tmp105: $(cat /sys/class/hwmon/hwmon0/temp1_input) "
	echo -n "bat ch0: $(cat /sys/bus/iio/devices/iio:device0/in_temp0_input) "
	echo "die ch3: $(cat /sys/bus/iio/devices/iio:device0/in_temp3_input)"
	sleep 1
done

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jonathan Cameron May 20, 2017, 4:39 p.m. UTC | #3 
On 20/05/17 17:35, Tony Lindgren wrote:
> * Jonathan Cameron <jic23@kernel.org> [170520 08:58]:
>> On 19/05/17 04:40, Tony Lindgren wrote:
>>> It seems that "MC13783 Power Management and Audio Ciruit User's Guide"
>>> MC1378UG.pdf documents several similar components as in the CPCAP PMIC.
>>>
>>> Chapter "9.5.5 Die Temperature and UID" says that the die temperature
>>> value is 282 at 25C with LSB of -1.14C. Converting CPCAP PMIC channel3
>>> values with following seems to produce values that make sense for a
>>> PMIC die:
>>>
>>> temperature = 25000 + ((regval - 282) * 114)
>>>
>>> As we don't have any other documentation, let's assume the die
>>> temperature is unconfigured in the Motorola mapphone Linux kernel
>>> and the current temperature conversion table should be only used
>>> for the battery thermistor and not for the die temperature.
>> Is there any route we have available to confirm this?  I.e. doe anyone
>> have one where we can check plausibility?
> 
> Well there is also a tmp105 sensor for SoC temperature on board
> that I used for some sanity checks :) For the Motorola kernel, it
> seems it's doing all the interesting ADC stuff in user space for
> battery estimates. So if ch3 is used, it must be using the raw
> values. My guess is that ch3 is only used by the PMIC firmware to
> automatically cut off power if it gets too hot.
> 
> The temperature values seem to make sense now when compared against
> the tmp105 values.. The following output is from an idle device with
> charger connected with reasonably full battery:
> 
> $ ./test-d4-temperature
> tmp105: 37187 bat ch0: 33675 die ch3: 46888
> tmp105: 37187 bat ch0: 33820 die ch3: 41074
> tmp105: 37187 bat ch0: 33525 die ch3: 40390
> tmp105: 37125 bat ch0: 33675 die ch3: 40162
> tmp105: 37125 bat ch0: 34410 die ch3: 40048
> tmp105: 37125 bat ch0: 34555 die ch3: 40162
> tmp105: 37125 bat ch0: 33525 die ch3: 40390
> ...
> 
> Add some load with two instances of dd if=/dev/urandom of=/dev/null:
> 
> $ ./test-d4-temperature
> tmp105: 44250 bat ch0: 37240 die ch3: 51790
> tmp105: 44250 bat ch0: 34705 die ch3: 48940
> tmp105: 44250 bat ch0: 34705 die ch3: 48484
> tmp105: 44250 bat ch0: 34850 die ch3: 48370
> tmp105: 44312 bat ch0: 37585 die ch3: 48142
> tmp105: 44312 bat ch0: 36895 die ch3: 48484
> tmp105: 44375 bat ch0: 34705 die ch3: 48484
> tmp105: 44375 bat ch0: 36895 die ch3: 48484
> ...
> 
> So ch3 for the PMIC die temperature seems to follow the load
> numbers and makes sense as it provides power to all the devices.
> The first value of ch3 often is all over the map though, probably
> no way around that..
> 
> The script I'm using is:
> 
> #!/bin/sh
> 
> while [ 1 ]; do
> 	echo -n "tmp105: $(cat /sys/class/hwmon/hwmon0/temp1_input) "
> 	echo -n "bat ch0: $(cat /sys/bus/iio/devices/iio:device0/in_temp0_input) "
> 	echo "die ch3: $(cat /sys/bus/iio/devices/iio:device0/in_temp3_input)"
> 	sleep 1
> done
> 
> Regards,
> 
> Tony
> 
thanks for the info.

I'm happy with the it looks plausible on real hardware answer.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
--- a/drivers/iio/adc/cpcap-adc.c
+++ b/drivers/iio/adc/cpcap-adc.c
@@ -875,6 +875,22 @@  static int cpcap_adc_init_request(struct cpcap_adc_request *req,
 	return 0;
 }
 
+static int cpcap_adc_read_st_die_temp(struct cpcap_adc *ddata,
+				      int addr, int *val)
+{
+	int error;
+
+	error = regmap_read(ddata->reg, addr, val);
+	if (error)
+		return error;
+
+	*val -= 282;
+	*val *= 114;
+	*val += 25000;
+
+	return 0;
+}
+
 static int cpcap_adc_read(struct iio_dev *indio_dev,
 			  struct iio_chan_spec const *chan,
 			  int *val, int *val2, long mask)
@@ -906,9 +922,18 @@  static int cpcap_adc_read(struct iio_dev *indio_dev,
 		error = cpcap_adc_start_bank(ddata, &req);
 		if (error)
 			goto err_unlock;
-		error = cpcap_adc_read_bank_scaled(ddata, &req);
-		if (error)
-			goto err_unlock;
+		if ((ddata->vendor == CPCAP_VENDOR_ST) &&
+		    (chan->channel == CPCAP_ADC_AD3)) {
+			error = cpcap_adc_read_st_die_temp(ddata,
+							   chan->address,
+							   &req.result);
+			if (error)
+				goto err_unlock;
+		} else {
+			error = cpcap_adc_read_bank_scaled(ddata, &req);
+			if (error)
+				goto err_unlock;
+		}
 		error = cpcap_adc_stop_bank(ddata);
 		if (error)
 			goto err_unlock;