From: Lars-Peter Clausen <lars@metafoo.de>
To: Fabrice Gasnier <fabrice.gasnier@st.com>,
Jonathan Cameron <jic23@kernel.org>,
linux@armlinux.org.uk, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: linux-iio@vger.kernel.org, mark.rutland@arm.com,
mcoquelin.stm32@gmail.com, alexandre.torgue@st.com,
knaack.h@gmx.de, pmeerw@pmeerw.net
Subject: Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution
Date: Tue, 28 Feb 2017 09:34:41 +0100 [thread overview]
Message-ID: <f486bd08-b562-5101-01ba-c8e36ac0d83b@metafoo.de> (raw)
In-Reply-To: <79e01c5c-d27c-89ea-4d8f-9e66a6c091e6@st.com>
On 02/28/2017 09:21 AM, Fabrice Gasnier wrote:
> On 02/25/2017 04:11 PM, Jonathan Cameron wrote:
>> On 24/02/17 16:04, Fabrice Gasnier wrote:
>>> On 02/19/2017 01:09 PM, Jonathan Cameron wrote:
>>>> On 15/02/17 16:55, Fabrice Gasnier wrote:
>>>>> Add documentation for 'st,adc-res' dt optional property.
>>>>>
>>>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>>>> I'm happy with this, but would like to leave time for a device tree review.
>>>>
>>>> Ultimately we may well want to make this a generic property and call it
>>>> something
>>>> like adc-resolution but perhaps we need to wait until we have a few more
>>>> devices
>>>> supporting setting it via device tree to figure out what the best
>>>> interface is.
>>>> It would exactly be a problem to support this as a deprecated binding at
>>>> that
>>>> point.
>>>
>>> Hi Jonathan,
>>>
>>> I agree with you on this... It may be better to have generic property
>>> for this, especially if you see that it will come in the near future.
>>> May I suggest this prop to be less restrictive, e.g. like
>>> resolution-bits as is may also be worth for other device types, e.g.
>>> DAC as an example ?>
>> Sure, why not - no loss of meaning here. We may never use it for anything
>> else but that doesn't matter.
>
> Hi Jonathan,
>
> Following Rob's comment, how you see such a common property can be
> integrated. Currently I don't see much devices are doing this.
> Do you have ideas or preferences on this ?
>
> - Do you think replacing 'st,adc-res' by 'resolution-bits' in current
> patchset is enough for now ?
That name would be a bit confusing. Considering that the devicetree
describes th capabilities of the hardware this name would suggest that this
is the resolution supported by the device.
If we want to allow selecting runtime configuration parameters for IIO
devices from the devicetree we should probably follow the precedence set by
the clock framework and use properties with the 'assigned-' prefix.
But to be honest I'm not convinced yet that the whole approach of allowing
runtime configuration parameters to be configured via the devicetree is the
right approach. Converters and sensors often have a lot of runtime
configurable parameters, typically we expose them to the application layer
to allow maximum flexibility. Why is the resolution special in this case and
should be pre-configured via the devicetree instead?
- Lars
next prev parent reply other threads:[~2017-02-28 9:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 16:55 [PATCH 0/2] iio: allow to set STM32 ADC resolution Fabrice Gasnier
2017-02-15 16:55 ` [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution Fabrice Gasnier
2017-02-19 12:09 ` Jonathan Cameron
2017-02-24 16:04 ` Fabrice Gasnier
2017-02-25 15:11 ` Jonathan Cameron
2017-02-28 8:21 ` Fabrice Gasnier
2017-02-28 8:34 ` Lars-Peter Clausen [this message]
2017-02-28 10:14 ` Fabrice Gasnier
2017-03-05 11:14 ` Jonathan Cameron
2017-02-27 14:29 ` Rob Herring
2017-02-15 16:55 ` [PATCH 2/2] iio: adc: stm32: add dt " Fabrice Gasnier
2017-02-19 12:09 ` 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=f486bd08-b562-5101-01ba-c8e36ac0d83b@metafoo.de \
--to=lars@metafoo.de \
--cc=alexandre.torgue@st.com \
--cc=devicetree@vger.kernel.org \
--cc=fabrice.gasnier@st.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@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
all inboxes | Powered by JetHome®