lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50AA0431.9060609@metafoo.de>
Date:	Mon, 19 Nov 2012 11:04:33 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Thierry Reding <thierry.reding@...onic-design.de>
CC:	Jonathan Cameron <jic23@....ac.uk>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: adc: Add Texas Instruments ADC081C021/027 support

On 11/19/2012 10:50 AM, Thierry Reding wrote:
> On Mon, Nov 19, 2012 at 10:33:48AM +0100, Lars-Peter Clausen wrote:
>> On 11/19/2012 09:21 AM, Thierry Reding wrote:
>>> Add support for reading conversion results from the ADC and provide them
>>> through a single IIO channel. A proper scaling factor is also exported
>>> based on the reference voltage provided by a regulator.
>>>
>>> Signed-off-by: Thierry Reding <thierry.reding@...onic-design.de>
>>> ---
>> [...]
>>> +static int adc081c_read_raw(struct iio_dev *iio,
>>> +			    struct iio_chan_spec const *channel, int *value,
>>> +			    int *micro, long mask)
>>> +{
>>> +	struct adc081c *adc = iio_priv(iio);
>>> +	int err, scale;
>>> +
>>> +	switch (mask) {
>>> +	case IIO_CHAN_INFO_RAW:
>>> +		err = i2c_smbus_read_word_swapped(adc->i2c, REG_CONV_RES);
>>> +		if (err < 0)
>>> +			return err;
>>> +
>>> +		*value = (err >> 4) & 0xff;
>>> +		return IIO_VAL_INT;
>>> +
>>> +	case IIO_CHAN_INFO_SCALE:
>>> +		err = regulator_get_voltage(adc->ref);
>>> +		if (err < 0)
>>> +			return err;
>>> +
>>> +		scale = err / 255;
>>
>> Shouldn't this be 256?
> 
> Well, the maximum value that the conversion register can contain is 255,
> so if we divide by 256 we'll always be slightly off, right? Or maybe I
> misunderstand what the scale factor is supposed to do. From reading the
> documentation it seems like user-space is supposed to multiply the raw
> value by the scale to obtain the real voltage.

So usually for ADCs the scale is from 0V to VREF - 1 lsb or VREF - 0.5 LSB.
I just had a look at the adc081c927 datasheet and it looks as if it is no
exception.

> 
>>> +
>>> +		*value = scale / 1000000;
>>> +		*micro = scale % 1000000;
>>
>> scale for voltages is in microvolt, so I think it this is off by a factor of
>> 1000.
> 
> If scale is supposed to be in microvolts, then this is off by a factor
> of 1000000 since regulator_get_voltage() returns the voltage in
> microvolts as well.

sorry, I meant millivolts, too early in the morning ;)

> 
>> For ADCs it often makes sense to use IIO_VAL_FRACTIONAL_LOG2 with the val
>> being set to the reference voltage (in mV) and val2 being set to the number
>> of bits.
>>
>> E.g in your case
>>
>> 		*val = err / 1000;
>> 		*val2 = 8;
> 
> I'm confused, IIO_VAL_FRACTIONAL_LOG2 is supposed to return mV, but
> IIO_VAL_INT_PLUS_MICRO will return uV?
> 
> And setting val2 to 8 will cause the scaling factor to be 256, and not
> 255, so the converted value will actually be off (as I mentioned above).
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ