Linux IIO development
 help / color / mirror / Atom feed
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


  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