XADC

XADC

[Sören Brinkmann]

Hi Lars,

I recently found that you developed a driver for XADC and I thought I
enable it (see patch below). But it seems something is not working
correctly. The values I tested don't seem to be right and also fixed.
I.e. they don't change over time or across boards:

  # cat in_temp0_scale 
  123.040771484
  # cat in_voltage0_vccint_scale 
  0.732421875
  # cat in_voltage0_vccint_raw 
  1384
  # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
  # cat in_voltage1_vccaux_scale 
  0.732421875
  # cat in_voltage3_vccpint_scale 
  0.732421875

Do you have an idea what I'm missing?

	Thanks,
	S?ren

----------------8<-----------------8<-----------------8<--------------8<--------
Date: Tue, 3 Jun 2014 15:11:26 -0700
Subject: [PATCH] ARM: zynq: DT: Add XADC node

Add node for the Xilinx A/D Converter.

Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
---
 arch/arm/boot/dts/zynq-7000.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 760bbc463c5b..c5854286a95a 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -65,6 +65,14 @@
 		interrupt-parent = <&intc>;
 		ranges;
 
+		adc at f8007100 {
+			compatible = "xlnx,zynq-xadc-1.00.a";
+			reg = <0xf8007100 0x20>;
+			interrupts = <0 7 4>;
+			interrupt-parent = <&intc>;
+			clocks = <&clkc 12>;
+		};
+
 		i2c0: i2c at e0004000 {
 			compatible = "cdns,i2c-r1p10";
 			status = "disabled";
-- 
2.0.0

XADC

[Peter Meerwald]

Hello,

> I recently found that you developed a driver for XADC and I thought I
> enable it (see patch below). But it seems something is not working
> correctly. The values I tested don't seem to be right and also fixed.
> I.e. they don't change over time or across boards:
> 
>   # cat in_temp0_scale 
>   123.040771484
>   # cat in_voltage0_vccint_scale 
>   0.732421875
>   # cat in_voltage0_vccint_raw 
>   1384
>   # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
>   # cat in_voltage1_vccaux_scale 
>   0.732421875
>   # cat in_voltage3_vccpint_scale 
>   0.732421875

the _scale values are supposed to be constant; their purpose is to scale a 
measurement so that the result is in a given unit

e.g. in_temp0_scale scales in_temp0_raw so that the result 
(in_temp0_raw * in_temp0_scale) in milli Celsius

in_voltage0_vccint_raw * in_voltage0_vccint_scale is supposed to give 
milli Volts

so in_voltage0_vccint_raw should vary accross time / boards (and voltage 
hopefully :), but not the _scales

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

XADC

[Lars-Peter Clausen]

On 06/04/2014 08:47 AM, Peter Meerwald wrote:
> Hello,
>
>> I recently found that you developed a driver for XADC and I thought I
>> enable it (see patch below). But it seems something is not working
>> correctly. The values I tested don't seem to be right and also fixed.
>> I.e. they don't change over time or across boards:
>>
>>    # cat in_temp0_scale
>>    123.040771484
>>    # cat in_voltage0_vccint_scale
>>    0.732421875
>>    # cat in_voltage0_vccint_raw
>>    1384
>>    # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
>>    # cat in_voltage1_vccaux_scale
>>    0.732421875
>>    # cat in_voltage3_vccpint_scale
>>    0.732421875
>
> the _scale values are supposed to be constant; their purpose is to scale a
> measurement so that the result is in a given unit
>
> e.g. in_temp0_scale scales in_temp0_raw so that the result
> (in_temp0_raw * in_temp0_scale) in milli Celsius
>
> in_voltage0_vccint_raw * in_voltage0_vccint_scale is supposed to give
> milli Volts
>
> so in_voltage0_vccint_raw should vary accross time / boards (and voltage
> hopefully :), but not the _scales

Yep, as Peter said scale and offset will be constant, raw should change 
though, e.g. both voltage and temperature should a slight jitter if you 
repeatedly read them. If not something is broken. We had the driver in our 
images for Zynq board for a while now and so far it worked fine. I think 
Mrinal and Radhey from Xilinx also tested the driver.

- Lars

XADC

[Sören Brinkmann]

Hi Lars, Peter,

On Wed, 2014-06-04 at 09:27AM +0200, Lars-Peter Clausen wrote:
> On 06/04/2014 08:47 AM, Peter Meerwald wrote:
> >Hello,
> >
> >>I recently found that you developed a driver for XADC and I thought I
> >>enable it (see patch below). But it seems something is not working
> >>correctly. The values I tested don't seem to be right and also fixed.
> >>I.e. they don't change over time or across boards:
> >>
> >>   # cat in_temp0_scale
> >>   123.040771484
> >>   # cat in_voltage0_vccint_scale
> >>   0.732421875
> >>   # cat in_voltage0_vccint_raw
> >>   1384
> >>   # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
> >>   # cat in_voltage1_vccaux_scale
> >>   0.732421875
> >>   # cat in_voltage3_vccpint_scale
> >>   0.732421875
> >
> >the _scale values are supposed to be constant; their purpose is to scale a
> >measurement so that the result is in a given unit
> >
> >e.g. in_temp0_scale scales in_temp0_raw so that the result
> >(in_temp0_raw * in_temp0_scale) in milli Celsius
> >
> >in_voltage0_vccint_raw * in_voltage0_vccint_scale is supposed to give
> >milli Volts
> >
> >so in_voltage0_vccint_raw should vary accross time / boards (and voltage
> >hopefully :), but not the _scales
> 
> Yep, as Peter said scale and offset will be constant, raw should
> change though, e.g. both voltage and temperature should a slight
> jitter if you repeatedly read them. If not something is broken. We
> had the driver in our images for Zynq board for a while now and so
> far it worked fine. I think Mrinal and Radhey from Xilinx also
> tested the driver.

Okay, thanks for the answers. Since the _scale value was the only one
close to a Celsius or Fahrenheit value I thought that would be the
final temperature. Anyway, the raw values do show some jitter. So far,
so good, but the math doesn't add up I think:

 # cat in_temp0_raw in_temp0_scale 
 2559
 123.040771484

multiplying those values gives
2559 * 123.040771484 = 304156.787108

Even if that is mC, that would mean my chip is at 304 degrees C. I'm pretty
sure my chip's not on fire :)
(I have the feeling I just did another beginner's mistake here though).
A 10x error might be in there somewhere. 30 degrees sounds realistic.

I didn't test all voltages, but those look better.

Also, is there a way to directly obtain a reading in a reasonable scale?
This approach needs to read two sysfs files, one of those even giving a
float.

	S?ren

XADC

[Lars-Peter Clausen]

On 06/04/2014 04:27 PM, S?ren Brinkmann wrote:
> Hi Lars, Peter,
>
> On Wed, 2014-06-04 at 09:27AM +0200, Lars-Peter Clausen wrote:
>> On 06/04/2014 08:47 AM, Peter Meerwald wrote:
>>> Hello,
>>>
>>>> I recently found that you developed a driver for XADC and I thought I
>>>> enable it (see patch below). But it seems something is not working
>>>> correctly. The values I tested don't seem to be right and also fixed.
>>>> I.e. they don't change over time or across boards:
>>>>
>>>>    # cat in_temp0_scale
>>>>    123.040771484
>>>>    # cat in_voltage0_vccint_scale
>>>>    0.732421875
>>>>    # cat in_voltage0_vccint_raw
>>>>    1384
>>>>    # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
>>>>    # cat in_voltage1_vccaux_scale
>>>>    0.732421875
>>>>    # cat in_voltage3_vccpint_scale
>>>>    0.732421875
>>>
>>> the _scale values are supposed to be constant; their purpose is to scale a
>>> measurement so that the result is in a given unit
>>>
>>> e.g. in_temp0_scale scales in_temp0_raw so that the result
>>> (in_temp0_raw * in_temp0_scale) in milli Celsius
>>>
>>> in_voltage0_vccint_raw * in_voltage0_vccint_scale is supposed to give
>>> milli Volts
>>>
>>> so in_voltage0_vccint_raw should vary accross time / boards (and voltage
>>> hopefully :), but not the _scales
>>
>> Yep, as Peter said scale and offset will be constant, raw should
>> change though, e.g. both voltage and temperature should a slight
>> jitter if you repeatedly read them. If not something is broken. We
>> had the driver in our images for Zynq board for a while now and so
>> far it worked fine. I think Mrinal and Radhey from Xilinx also
>> tested the driver.
>
> Okay, thanks for the answers. Since the _scale value was the only one
> close to a Celsius or Fahrenheit value I thought that would be the
> final temperature. Anyway, the raw values do show some jitter. So far,
> so good, but the math doesn't add up I think:
>
>   # cat in_temp0_raw in_temp0_scale
>   2559
>   123.040771484
>
> multiplying those values gives
> 2559 * 123.040771484 = 304156.787108
>
> Even if that is mC, that would mean my chip is at 304 degrees C. I'm pretty
> sure my chip's not on fire :)
> (I have the feeling I just did another beginner's mistake here though).
> A 10x error might be in there somewhere. 30 degrees sounds realistic.

There is also a in_temp0_offset attribute which needs to be added to 
in_temp0_raw

temperature = (in_temp0_raw + in_temp0_offset) * in_temp0_scale.

In your case that is: (2559 - 2219) * 123.040771484 = 41833.86

>
> I didn't test all voltages, but those look better.
>
> Also, is there a way to directly obtain a reading in a reasonable scale?
> This approach needs to read two sysfs files, one of those even giving a
> float.

No.

- Lars

XADC

[Sören Brinkmann]

On Thu, 2014-06-05 at 10:26AM +0200, Lars-Peter Clausen wrote:
> On 06/04/2014 04:27 PM, S?ren Brinkmann wrote:
> >Hi Lars, Peter,
> >
> >On Wed, 2014-06-04 at 09:27AM +0200, Lars-Peter Clausen wrote:
> >>On 06/04/2014 08:47 AM, Peter Meerwald wrote:
> >>>Hello,
> >>>
> >>>>I recently found that you developed a driver for XADC and I thought I
> >>>>enable it (see patch below). But it seems something is not working
> >>>>correctly. The values I tested don't seem to be right and also fixed.
> >>>>I.e. they don't change over time or across boards:
> >>>>
> >>>>   # cat in_temp0_scale
> >>>>   123.040771484
> >>>>   # cat in_voltage0_vccint_scale
> >>>>   0.732421875
> >>>>   # cat in_voltage0_vccint_raw
> >>>>   1384
> >>>>   # cat in_voltage1_vccaux_s[ 1203.660637] random: nonblocking pool is initialized
> >>>>   # cat in_voltage1_vccaux_scale
> >>>>   0.732421875
> >>>>   # cat in_voltage3_vccpint_scale
> >>>>   0.732421875
> >>>
> >>>the _scale values are supposed to be constant; their purpose is to scale a
> >>>measurement so that the result is in a given unit
> >>>
> >>>e.g. in_temp0_scale scales in_temp0_raw so that the result
> >>>(in_temp0_raw * in_temp0_scale) in milli Celsius
> >>>
> >>>in_voltage0_vccint_raw * in_voltage0_vccint_scale is supposed to give
> >>>milli Volts
> >>>
> >>>so in_voltage0_vccint_raw should vary accross time / boards (and voltage
> >>>hopefully :), but not the _scales
> >>
> >>Yep, as Peter said scale and offset will be constant, raw should
> >>change though, e.g. both voltage and temperature should a slight
> >>jitter if you repeatedly read them. If not something is broken. We
> >>had the driver in our images for Zynq board for a while now and so
> >>far it worked fine. I think Mrinal and Radhey from Xilinx also
> >>tested the driver.
> >
> >Okay, thanks for the answers. Since the _scale value was the only one
> >close to a Celsius or Fahrenheit value I thought that would be the
> >final temperature. Anyway, the raw values do show some jitter. So far,
> >so good, but the math doesn't add up I think:
> >
> >  # cat in_temp0_raw in_temp0_scale
> >  2559
> >  123.040771484
> >
> >multiplying those values gives
> >2559 * 123.040771484 = 304156.787108
> >
> >Even if that is mC, that would mean my chip is at 304 degrees C. I'm pretty
> >sure my chip's not on fire :)
> >(I have the feeling I just did another beginner's mistake here though).
> >A 10x error might be in there somewhere. 30 degrees sounds realistic.
> 
> There is also a in_temp0_offset attribute which needs to be added to
> in_temp0_raw
> 
> temperature = (in_temp0_raw + in_temp0_offset) * in_temp0_scale.
> 
> In your case that is: (2559 - 2219) * 123.040771484 = 41833.86
> 
> >
> >I didn't test all voltages, but those look better.
> >
> >Also, is there a way to directly obtain a reading in a reasonable scale?
> >This approach needs to read two sysfs files, one of those even giving a
> >float.
> 
> No.

That explains things. Thanks a lot. 

	S?ren