From: Jonathan Cameron <jic23@cam.ac.uk>
To: Andrew Chew <AChew@nvidia.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
'Alan Cox' <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH 1/1] iio: ak8975: Add Ak8975 magnetometer sensor
Date: Sat, 04 Sep 2010 17:07:03 +0100 [thread overview]
Message-ID: <4C826EA7.3090808@cam.ac.uk> (raw)
In-Reply-To: <643E69AA4436674C8F39DCC2C05F763816B85AD09E@HQMAIL03.nvidia.com>
On 09/03/10 21:03, Andrew Chew wrote:
>> if I understand your comment correctly userspace needs to know that
>> number to convert from the magn_raw values to standard units.
>> Hence it must be exported. My point is that the calib attributes
>> are used for devices that do their calibration offsets and scales
>> internally. If it is a value userspace needs to apply then the
>> correct parameters are scale and offset. In the majority of devices
>> see so far these are fixed for all instances of the same part. That
>> isn't true here.
>>>
>>> And if we were to emit non-raw values (or provide the scale
>>> attributes), what's theexact name of the attributes? And
>> what units are we expecting? Gauss? Tesla? I don't see
>> that documented anywhere.
>> That is documented. Gauss is the chosen standard for
>> magnetometers. I'll assume the
>> conversion factors are channel dependent in which case you need
>>
>> magn_x_raw, magn_x_scale, magn_x_offset
>>
>> note again, we have documented everything for some device types.
>> At the time, repeating for all of them was considered redundant, but
>> perhaps we do need to do this for the added clarity.
>>
>> The value in Gauss = (magn_x_raw + magn_x_offset)*magn_x_scale
>
> The conversion formula doesn't have an offset, actually, so the order
> in which the offset and scale are applied don't really matter to me.
Cool. I misread your comment (lots of brackets and I was clearly half
asleep ;)
>
> In any case, I think I got it now. I'm going to report the raw sensor
> value, and the scale factor for each axis to convert to gauss.
>
> I assume when you say magn_x_scale, you really mean magn_x_gain?
> Because I don't see magn_x_scale defined in magnet.h. Or should I
> call the attribute magn_x_scale anyway, and not use the IIO_DEV_ATTR
> macro for gain?
Gah. Take the documentation first.
Looks like the magnetometer macros slipped through the net - mainly
because no one was using them so they shouldn't have been there
in the first place.
Please can you add suitable macros for _scale? You can also kill the _gain
ones if you like, or I can add that to the next set of clean up patches.
Killing the gain ones should be in a separate patch but it'll obviously cause
merge issues hence it is easier for you to do both.
The only provider of such an attribute is imu/adis16400_core.c and that
one is constant and shared across the axes so it uses
IIO_CONST_ATTR(magn_scale,...)
Thanks for pointing this out.
Jonathan
-----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
>
next prev parent reply other threads:[~2010-09-04 16:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-02 21:35 [PATCH 1/1] iio: ak8975: Add Ak8975 magnetometer sensor achew
2010-09-02 22:19 ` Alan Cox
2010-09-02 22:16 ` Andrew Chew
2010-09-02 22:41 ` Alan Cox
2010-09-02 23:15 ` Jonathan Cameron
2010-09-02 23:57 ` Andrew Chew
2010-09-03 7:19 ` Jonathan Cameron
2010-09-03 20:03 ` Andrew Chew
2010-09-04 16:07 ` Jonathan Cameron [this message]
2010-09-03 5:18 ` samu.p.onkalo
2010-09-03 7:23 ` Jonathan Cameron
2010-09-03 7:20 ` samu.p.onkalo
-- strict thread matches above, loose matches on Subject: below --
2010-09-02 23:40 achew
2010-09-03 23:16 ` Andrew Morton
2010-09-04 16:38 ` Jonathan Cameron
2010-09-06 8:17 ` Datta, Shubhrajyoti
2010-09-07 23:07 ` Andrew Chew
2010-09-08 10:05 ` Datta, Shubhrajyoti
2010-09-08 15:34 ` Murphy, Dan
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=4C826EA7.3090808@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=AChew@nvidia.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ldewangan@nvidia.com \
--cc=linux-iio@vger.kernel.org \
/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