All of lore.kernel.org
 help / color / mirror / Atom feed
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.
> -----------------------------------------------------------------------------------
> 


  reply	other threads:[~2010-09-04 16:02 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-02 21:35 [PATCH 1/1] iio: ak8975: Add Ak8975 magnetometer sensor achew-DDmLM1+adcrQT0dZR+AlfA
2010-09-02 21:35 ` achew
     [not found] ` <1283463351-15816-1-git-send-email-achew-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2010-09-02 22:19   ` Alan Cox
2010-09-02 22:19     ` Alan Cox
     [not found]     ` <20100902231942.21375cc0-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2010-09-02 22:16       ` Andrew Chew
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-xNZwKgViW5gAvxtiuMwx3w
2010-09-03  5:18         ` samu.p.onkalo
     [not found]         ` <62697B07E9803846BC582181BD6FB6B82B9C057FFC-xJW1crHCIS+8kqYwC468Frtp2NbXvJi8gfoxzgwHRXE@public.gmane.org>
2010-09-03  7:23           ` Jonathan Cameron
2010-09-03  7:23             ` Jonathan Cameron
     [not found]             ` <4C80A26F.6020408-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
2010-09-03  7:20               ` samu.p.onkalo-xNZwKgViW5gAvxtiuMwx3w
2010-09-03  7:20                 ` samu.p.onkalo
2010-09-03  7:20                 ` samu.p.onkalo
  -- strict thread matches above, loose matches on Subject: below --
2010-09-02 23:40 achew-DDmLM1+adcrQT0dZR+AlfA
2010-09-02 23:40 ` achew
     [not found] ` <1283470837-18210-1-git-send-email-achew-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2010-09-03 23:16   ` Andrew Morton
2010-09-03 23:16     ` Andrew Morton
2010-09-04 16:38   ` Jonathan Cameron
2010-09-04 16:38     ` Jonathan Cameron
2010-09-06  8:17   ` Datta, Shubhrajyoti
2010-09-06  8:17     ` Datta, Shubhrajyoti
     [not found]     ` <0680EC522D0CC943BC586913CF3768C003C2018464-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-09-07 23:07       ` Andrew Chew
2010-09-07 23:07         ` Andrew Chew
     [not found]         ` <643E69AA4436674C8F39DCC2C05F763816B85AD0A9-lR+7xdUAJVNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2010-09-08 10:05           ` Datta, Shubhrajyoti
2010-09-08 10:05             ` Datta, Shubhrajyoti
     [not found]             ` <0680EC522D0CC943BC586913CF3768C003C2018BD4-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-09-08 15:34               ` Murphy, Dan
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.