From: Jonathan Cameron <jic23@kernel.org>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 07/15] staging:iio:hmc5843: Use CALIBSCALE instead of magn_range
Date: Fri, 20 Sep 2013 22:54:55 +0100 [thread overview]
Message-ID: <523CC42F.7010403@kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.01.1309202147420.5504@pmeerw.net>
On 09/20/13 21:12, Peter Meerwald wrote:
> Hi,
>
>> I'm afraid I don't follow why you don't just make scale writeable
>> rather than introducing a second element to control the same thing.
>> Calibscale is intended for the case where the hardware can change
>> the scale without it being apparent from the raw readings. Sometimes
>> it also gets used to handling amplifiers in cases where the conversion
>> function is 'interesting' and we have no choice but to do it in kernel
>> in order to have data provided to userspace in a comprehensible form
>> but that doesn't apply here.
>
> I guess this is reminiscent of the staging code which had magn_range and
> scale; magn_range being the nice, human-readable measurement range (such
> as +- 1.9 Gauss)
True enough, but unfortunately we then have to have two controls for
the same things which leads to a messy inconsistent interface.
The best I can offer at the moment is the much stated plan to have an
extending 'available' type attribute for every element of the info mask.
Then combining the available scale with the available values that _raw
can take will give you the range of values that the part can take.
In the vast majority of cases this would provide userspace with all the
numbers to present this however is desired. The only nasty case would
be where the available raw values are stricted for some of the scales
but that would be rather unusual.
Note that such a generic _available (or other equivalent named) attribute
would need to cover both the discrete case and the data range cases. Things
like
0.1111111 0.222222 0.3333333 0.444444
vs
0.111111..0.111111..0.444444
to specify the same thing.
An RFC on this has been my 'next thing to do' for the last couple of weeks
but I've been rather swamped with reviews to do so it hasn't happened yet!
>
> setting the expected measurement range sounds like calibration to me...
Not really. Things like a trim resistor value in an amplifier circuit
would be calibration. Ways of fixing inaccuracies in the hardware.
The use in the various light sensors is sort of equivalent to this as
there is no direct output.
>
> I think this is one of the biggest issues of iio: that there is no
> guideline when to use what
True enough. We are kind of working by precedence which is fine if it
is easy to find an equivalent case. Perhaps adding more stuff to
the dummy driver to cover the uses of some of this stuff would help?
>
> regards, p.
>
next prev parent reply other threads:[~2013-09-20 20:54 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 19:35 [PATCH v2 00/15] staging:iio:hmc5843 cleanup Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 01/15] staging:iio:hmc5843: Add pointer to i2c client to data struct Peter Meerwald
2013-09-21 10:46 ` Jonathan Cameron
2013-10-01 9:40 ` Jonathan Cameron
2013-10-01 8:44 ` Peter Meerwald
2013-10-01 10:10 ` Jonathan Cameron
2013-09-19 19:35 ` [PATCH v2 02/15] staging:iio:hmc5843: Rewrite init function Peter Meerwald
2013-10-01 9:41 ` Jonathan Cameron
2013-09-19 19:35 ` [PATCH v2 03/15] staging:iio:hmc5843: Use INFO_SAMP_FREQ Peter Meerwald
2013-10-01 9:44 ` Jonathan Cameron
2013-09-19 19:35 ` [PATCH v2 04/15] staging:iio:hmc5843: Remove unused LSB register #defines Peter Meerwald
2013-10-01 9:55 ` Jonathan Cameron
2013-09-19 19:35 ` [PATCH v2 05/15] staging:iio:hmc5843: Tighten comments Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 06/15] staging:iio:hmc5843: Introduce helper functions to show/check list of int pairs Peter Meerwald
2013-10-01 9:55 ` Jonathan Cameron
2013-10-01 9:58 ` Jonathan Cameron
2013-09-19 19:35 ` [PATCH v2 07/15] staging:iio:hmc5843: Use CALIBSCALE instead of magn_range Peter Meerwald
2013-09-20 19:57 ` Jonathan Cameron
2013-09-20 20:12 ` Peter Meerwald
2013-09-20 21:54 ` Jonathan Cameron [this message]
2013-09-19 19:35 ` [PATCH v2 08/15] staging:iio:hmc5843: Always read all channels values otherwise no updates Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 09/15] staging:iio:hmc5843: Add trigger handling Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 10/15] staging:iio:hmc5843: Remove ability to change operating mode Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 11/15] staging:iio:hmc5843: Rename _configure() to _set_mode() Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 12/15] staging:iio:hmc5843: Reorganize _set_meas_conf() Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 13/15] staging:iio:hmc5843: Rename _set_rate() to _set_samp_freq() Peter Meerwald
2013-09-19 19:35 ` [PATCH v2 14/15] staging:iio:hmc5843: Introduce _set_range_gain() Peter Meerwald
2013-09-19 19:36 ` [PATCH v2 15/15] staging:iio:hmc5843: Check initialization and chip identifier Peter Meerwald
2013-09-20 20:05 ` [PATCH v2 00/15] staging:iio:hmc5843 cleanup Jonathan Cameron
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=523CC42F.7010403@kernel.org \
--to=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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;
as well as URLs for NNTP newsgroup(s).