From: Lars-Peter Clausen <lars@metafoo.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Jonathan Cameron" <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org, kernel@pengutronix.de,
Thorsten Scherer <t.scherer@eckelmann.de>
Subject: Re: ti-ads7950: selecting the adc input range
Date: Fri, 8 Jul 2022 11:28:35 +0200 [thread overview]
Message-ID: <441bfa83-4014-fed9-3527-7db34df7da3a@metafoo.de> (raw)
In-Reply-To: <20220708080257.y6wn7pztylujepyr@pengutronix.de>
On 7/8/22 10:02, Uwe Kleine-König wrote:
> Hello,
>
> the ADS7950 has a register bit (called TI_ADS7950_CR_RANGE_5V in the
> driver) that selects the input range. Depending on that bit the input
> range is either [0 .. V_{REF}] or [0 .. 2 * V_{REF}].
>
> The driver currently defaults to setting that bit, so the range is the
> big one.
>
> On a machine here however I know the input is in the smaller range and
> I'd like to benefit from the higher resolution of the small range. I
> wonder how to make this tunable. Should that be done using a firmware
> property? ("single-input-range" vs. "double-input-range"? Or input-range
> = <1> vs. input-range = <2> which better matches the data sheet that
> calls the two modes "Range 1 (0 to V_{REF})" and "Range 2 (0 to
> 2xV_{REF})") Or should this be made tunable via sysfs? (E.g. by writing
> to the scale property? Or a separate property?)
Hi,
Its a bit of a tricky one. You can find arguments for and against
either. Like "devicetree is for hardware description and not application
specific configuration data", or "I know which setting I want to use,
having the kernel apply it makes it a lot easier".
What we've done in the past in the IIO framework is to make the scale
property writable for such devices. Together with a scale_available
property to list valid options. This is the most flexible option as it
allows to change the setting at runtime for applications where it is
required.
Maybe the right solution is a mix of both, have the property writable by
default, but allow firmware to restrict the available options based on
what the system designer though makes sense. E.g. on some boards having
the ability to switch at runtime makes sense, on others it does not.
- Lars
next prev parent reply other threads:[~2022-07-08 9:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 8:02 ti-ads7950: selecting the adc input range Uwe Kleine-König
2022-07-08 9:28 ` Lars-Peter Clausen [this message]
2022-07-08 10:35 ` Nuno Sá
2022-07-16 17:57 ` Jonathan Cameron
2022-07-09 17:10 ` Uwe Kleine-König
2022-07-09 18:17 ` Lars-Peter Clausen
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=441bfa83-4014-fed9-3527-7db34df7da3a@metafoo.de \
--to=lars@metafoo.de \
--cc=jic23@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-iio@vger.kernel.org \
--cc=t.scherer@eckelmann.de \
--cc=u.kleine-koenig@pengutronix.de \
/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