Re: [PATCH 2/3] staging:iio sync drivers with current ABI

[Jonathan Cameron <jic23@cam.ac.uk>]

On 08/30/10 17:28, Manuel Stahl wrote:
> Am 30.08.2010 18:07, schrieb Jonathan Cameron:
>> On 08/30/10 16:48, Manuel Stahl wrote:
>>> Am 30.08.2010 17:42, schrieb Jonathan Cameron:
>>>> On 08/30/10 16:00, Manuel Stahl wrote:
>>>>> Am 30.08.2010 16:44, schrieb Jonathan Cameron:
>>>>>> On 08/30/10 15:03, Manuel Stahl wrote:
>>>>>>>     static IIO_DEV_ATTR_INCLI_X(adis16300_read_13bit_signed,
>>>>>>>             ADIS16300_XINCLI_OUT);
>>>>>>>     static IIO_DEV_ATTR_INCLI_Y(adis16300_read_13bit_signed,
>>>>>>>             ADIS16300_YINCLI_OUT);
>>>>>>> -static IIO_CONST_ATTR(incli_scale, "0.044 d");
>>>>>>> +static IIO_CONST_ATTR_INCLI_SCALE("0.044 deg");
>>>>>>>
>>>>>>>     static IIO_DEV_ATTR_TEMP_RAW(adis16300_read_12bit_unsigned)=
;
>>>>>>> -static IIO_CONST_ATTR(temp_offset, "198.16 K");
>>>>>>> -static IIO_CONST_ATTR(temp_scale, "0.14 K");
>>>>>>> +static IIO_CONST_ATTR_TEMP_OFFSET("198.16 K");
>>>>>>> +static IIO_CONST_ATTR_TEMP_SCALE("0.14 K");
>>>>>> These need to be suitable for conversion to milli degrees C to m=
atch
>>>>>> hwmon.
>>>>> I think scientific devices should stick to SI units.
>>>> I'd normally agree, but hwmon beat us in defining the interface an=
d I
>>>> agree with Greg and Andrew Morton that the kernel is gaining too m=
any
>>>> incompatible interfaces.  Hence for temp we follow them.  Same oug=
ht
>>>> to be true for in[m] and current measurements.  Guess I'll do an a=
udit
>>>> of this sometime soon and make sure they are all the same.
>>>
>>> We already have a major difference here, that is we allow floating
>>> point values as output. Also we have no _input postfix, which, I
>>> agree, should be compatible if it was there. Hwmon is tuned to fixe=
d
>>> point values, but that it too limited for the range of devices we
>>> want to address with IIO. They simply don't care if they loose some
>>> bit of precision.
>> We do allow _input.  Only one user at the moment though.  illuminanc=
e0_input
>> in the tsl2563 driver.  The intent was always to extend their interf=
ace
>> but not to break comparability if we can easily avoid it.  I should =
probably
>> document the fact we allow this. It's useful for slow devices with n=
on linear
>> mappings between their raw values and the measurement. (very common =
in light
>> sensors).  Things will get more 'interesting' when we have a fast de=
vice
>> with a non linear mapping.  We'll figure that out what to do about t=
hat
>> if / when some has such a device.
>>
>> I agree that fixed point is overly limiting for our purposes. Howeve=
r, by
>> simply allowing ours to use floating point userspace can accommodate=
 either.
>> Afterall in most cases a floating point read of an integer string wi=
ll give
>> the right (or very close to it) result.
>>
>> Basically my intent (supported by others in the abi discussions) is =
to match and extend
>> hwmon wherever possible.  I'm actively advocating this approach else=
where in the
>> kernel as well.
>=20
> As I said, I have no doubt that *_input files must be compatible (mV,
> m=B0C), but the combination of _raw, _offset and _scale can result in
> SI units as you have to do floating point math anyway.
I still think matching their multiplier (e.g. milli volts etc) is going=
 to
be a better idea on the long run.  Other than being marginally annoying=
 in
that we aren't going to do this for other unit types, I don't think it =
matters
to us...  I've seen a few people agitating on lm-sensors for a higher a=
ccuracy
option there.  If they need it then I'd argue for our raw and multiplie=
r approach.
To be cynical, along with it being a good idea in my view, the reason f=
or
matching units is to avoid conflict with those we need to eventually co=
nvince
in order to move out of staging.  It's just good politics.

> While doing
> the cleanup here, I found that we have rad/s for gyros and deg for
> inclinometeres. Should be unified somehow

Agreed.  Which one shall we go for?
Having googled to confirm. Radians are accepted as closest derived SI u=
nit...
http://physics.nist.gov/cuu/Units/units.html
Got to love a m/m argument...

So I think rad/s.

Jonathan