From: Harald Geyer <harald-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
To: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Cc: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 0/3] mxs-lradc: Add support for current sources
Date: Fri, 29 Apr 2016 19:45:18 +0200 [thread overview]
Message-ID: <aadb3f41413d093312c0af3e4c207a8a@ccbib.org> (raw)
In-Reply-To: <572379F5.8000501-eS4NqCHxEME@public.gmane.org>
Hi Stefan!
On 29.04.2016 17:12, Stefan Wahren wrote:
> Hi Harald,
>
> Am 22.04.2016 um 15:52 schrieb Harald Geyer:
>> Patch 1/3 changes the driver and updates the binding documentation
>> (I guess it is still in staging.)
>>
>> Patches 2/3 and 3/3 add the devicetree nodes to imx23 and imx28
>> boards.
>> I'd like to get input whether this is actually desired. On boards
>> where
>> these regulators would never be enabled this costs a few extra bytes
>> of
>> RAM for allocation of the device data, because the nodes can't be
>> easily
>> removed in .dts files which are including the .dtsi files. The
>> alternative
>> is to add the new nodes to many .dts files, which would be a lot
>> code
>> duplication.
>
> if i get it right the real intention of this patch series is to make
> the
> mxs-lradc provide resistance values instead of voltages.
... or even temperature values if a thermistor is connected.
> So how about
> dropping the whole regulator stuff and provide the values as
> IIO_RESISTANCE via iio interface?
Can you elaborate on this?
My thinking is that there should be a thermistor (or whatever else)
driver,
that is a consumer of the regulator and a consumer of the IIO_VOLTAGE
iio channel and provides a new device with an IIO_RESISTANCE or
IIO_TEMP
channel. Maybe there is a simpler solution, that I'm missing?
Actually I'm not 100% happy with the above solution myself, because if
we
start supporting devices that act as an iio-multiplexer (some device
that
is an iio consumer and provides many new iio channels and can control
via gpios which of it child channels is actually routed to the upstream
device) I don't know how to properly manage the regulator device.
However since this is only hypothetical ATM, I think we don't have to
worry about this too much.
> Btw this feature should be only added to dts files where is actually
> used.
Ok, so how do we figure out which boards these are?
I use this on the olinuxino and I guess all evaluation boards support
the
use case too. The others I don't know enough about to be sure and I
guess
it's not a good idea to just wait until somebody speaks up and
complains
that the feature is missing on board X ...
Thanks,
Harald
> Regards
> Stefan
>
>>
>> Harald Geyer (3):
>> iio: mxs-lradc: Add regulators for current sources
>> ARM: dts: imx23: Provide regulators for the current sources of the
>> LRADC
>> ARM: dts: imx28: Provide regulators for the current sources of the
>> LRADC
>>
>> .../bindings/staging/iio/adc/mxs-lradc.txt | 29 ++++
>> arch/arm/boot/dts/imx23.dtsi | 8 ++
>> arch/arm/boot/dts/imx28.dtsi | 8 ++
>> drivers/iio/adc/Kconfig | 1 +
>> drivers/iio/adc/mxs-lradc.c | 152
>> +++++++++++++++++++++
>> 5 files changed, 198 insertions(+)
>>
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
or bitcoin 1FUtd8T9jRN1rFz63vZz7s2fDtB6d6A7aS
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Harald Geyer <harald@ccbib.org>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Jonathan Cameron <jic23@kernel.org>, <devicetree@vger.kernel.org>,
<linux-iio@vger.kernel.org>, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <kernel@pengutronix.de>, Marek Vasut <marex@denx.de>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/3] mxs-lradc: Add support for current sources
Date: Fri, 29 Apr 2016 19:45:18 +0200 [thread overview]
Message-ID: <aadb3f41413d093312c0af3e4c207a8a@ccbib.org> (raw)
In-Reply-To: <572379F5.8000501@i2se.com>
Hi Stefan!
On 29.04.2016 17:12, Stefan Wahren wrote:
> Hi Harald,
>
> Am 22.04.2016 um 15:52 schrieb Harald Geyer:
>> Patch 1/3 changes the driver and updates the binding documentation
>> (I guess it is still in staging.)
>>
>> Patches 2/3 and 3/3 add the devicetree nodes to imx23 and imx28
>> boards.
>> I'd like to get input whether this is actually desired. On boards
>> where
>> these regulators would never be enabled this costs a few extra bytes
>> of
>> RAM for allocation of the device data, because the nodes can't be
>> easily
>> removed in .dts files which are including the .dtsi files. The
>> alternative
>> is to add the new nodes to many .dts files, which would be a lot
>> code
>> duplication.
>
> if i get it right the real intention of this patch series is to make
> the
> mxs-lradc provide resistance values instead of voltages.
... or even temperature values if a thermistor is connected.
> So how about
> dropping the whole regulator stuff and provide the values as
> IIO_RESISTANCE via iio interface?
Can you elaborate on this?
My thinking is that there should be a thermistor (or whatever else)
driver,
that is a consumer of the regulator and a consumer of the IIO_VOLTAGE
iio channel and provides a new device with an IIO_RESISTANCE or
IIO_TEMP
channel. Maybe there is a simpler solution, that I'm missing?
Actually I'm not 100% happy with the above solution myself, because if
we
start supporting devices that act as an iio-multiplexer (some device
that
is an iio consumer and provides many new iio channels and can control
via gpios which of it child channels is actually routed to the upstream
device) I don't know how to properly manage the regulator device.
However since this is only hypothetical ATM, I think we don't have to
worry about this too much.
> Btw this feature should be only added to dts files where is actually
> used.
Ok, so how do we figure out which boards these are?
I use this on the olinuxino and I guess all evaluation boards support
the
use case too. The others I don't know enough about to be sure and I
guess
it's not a good idea to just wait until somebody speaks up and
complains
that the feature is missing on board X ...
Thanks,
Harald
> Regards
> Stefan
>
>>
>> Harald Geyer (3):
>> iio: mxs-lradc: Add regulators for current sources
>> ARM: dts: imx23: Provide regulators for the current sources of the
>> LRADC
>> ARM: dts: imx28: Provide regulators for the current sources of the
>> LRADC
>>
>> .../bindings/staging/iio/adc/mxs-lradc.txt | 29 ++++
>> arch/arm/boot/dts/imx23.dtsi | 8 ++
>> arch/arm/boot/dts/imx28.dtsi | 8 ++
>> drivers/iio/adc/Kconfig | 1 +
>> drivers/iio/adc/mxs-lradc.c | 152
>> +++++++++++++++++++++
>> 5 files changed, 198 insertions(+)
>>
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
or bitcoin 1FUtd8T9jRN1rFz63vZz7s2fDtB6d6A7aS
WARNING: multiple messages have this Message-ID (diff)
From: harald@ccbib.org (Harald Geyer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] mxs-lradc: Add support for current sources
Date: Fri, 29 Apr 2016 19:45:18 +0200 [thread overview]
Message-ID: <aadb3f41413d093312c0af3e4c207a8a@ccbib.org> (raw)
In-Reply-To: <572379F5.8000501@i2se.com>
Hi Stefan!
On 29.04.2016 17:12, Stefan Wahren wrote:
> Hi Harald,
>
> Am 22.04.2016 um 15:52 schrieb Harald Geyer:
>> Patch 1/3 changes the driver and updates the binding documentation
>> (I guess it is still in staging.)
>>
>> Patches 2/3 and 3/3 add the devicetree nodes to imx23 and imx28
>> boards.
>> I'd like to get input whether this is actually desired. On boards
>> where
>> these regulators would never be enabled this costs a few extra bytes
>> of
>> RAM for allocation of the device data, because the nodes can't be
>> easily
>> removed in .dts files which are including the .dtsi files. The
>> alternative
>> is to add the new nodes to many .dts files, which would be a lot
>> code
>> duplication.
>
> if i get it right the real intention of this patch series is to make
> the
> mxs-lradc provide resistance values instead of voltages.
... or even temperature values if a thermistor is connected.
> So how about
> dropping the whole regulator stuff and provide the values as
> IIO_RESISTANCE via iio interface?
Can you elaborate on this?
My thinking is that there should be a thermistor (or whatever else)
driver,
that is a consumer of the regulator and a consumer of the IIO_VOLTAGE
iio channel and provides a new device with an IIO_RESISTANCE or
IIO_TEMP
channel. Maybe there is a simpler solution, that I'm missing?
Actually I'm not 100% happy with the above solution myself, because if
we
start supporting devices that act as an iio-multiplexer (some device
that
is an iio consumer and provides many new iio channels and can control
via gpios which of it child channels is actually routed to the upstream
device) I don't know how to properly manage the regulator device.
However since this is only hypothetical ATM, I think we don't have to
worry about this too much.
> Btw this feature should be only added to dts files where is actually
> used.
Ok, so how do we figure out which boards these are?
I use this on the olinuxino and I guess all evaluation boards support
the
use case too. The others I don't know enough about to be sure and I
guess
it's not a good idea to just wait until somebody speaks up and
complains
that the feature is missing on board X ...
Thanks,
Harald
> Regards
> Stefan
>
>>
>> Harald Geyer (3):
>> iio: mxs-lradc: Add regulators for current sources
>> ARM: dts: imx23: Provide regulators for the current sources of the
>> LRADC
>> ARM: dts: imx28: Provide regulators for the current sources of the
>> LRADC
>>
>> .../bindings/staging/iio/adc/mxs-lradc.txt | 29 ++++
>> arch/arm/boot/dts/imx23.dtsi | 8 ++
>> arch/arm/boot/dts/imx28.dtsi | 8 ++
>> drivers/iio/adc/Kconfig | 1 +
>> drivers/iio/adc/mxs-lradc.c | 152
>> +++++++++++++++++++++
>> 5 files changed, 198 insertions(+)
>>
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
or bitcoin 1FUtd8T9jRN1rFz63vZz7s2fDtB6d6A7aS
next prev parent reply other threads:[~2016-04-29 17:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 13:52 [PATCH 0/3] mxs-lradc: Add support for current sources Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-22 13:52 ` Harald Geyer
[not found] ` <1461333147-11873-1-git-send-email-harald-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
2016-04-22 13:52 ` [PATCH 1/3] iio: mxs-lradc: Add regulators " Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-22 13:52 ` Harald Geyer
[not found] ` <1461333147-11873-2-git-send-email-harald-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
2016-04-22 15:50 ` Marek Vasut
2016-04-22 15:50 ` Marek Vasut
2016-04-22 15:50 ` Marek Vasut
[not found] ` <571A4831.2020604-ynQEQJNshbs@public.gmane.org>
2016-04-22 17:00 ` Ksenija Stanojević
2016-04-22 17:00 ` Ksenija Stanojević
2016-04-22 17:00 ` Ksenija Stanojević
[not found] ` <CAL7P5jKYp0JrF2MHdLkLTBvgYb0KSDwPEMuNPGxcctcxCRnazg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-22 19:23 ` Harald Geyer
2016-04-22 19:23 ` Harald Geyer
2016-04-22 19:23 ` Harald Geyer
[not found] ` <f4c00c5c2242f6a951f1f8d8eca56357-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
2016-04-23 21:08 ` Jonathan Cameron
2016-04-23 21:08 ` Jonathan Cameron
2016-04-23 21:08 ` Jonathan Cameron
2016-04-22 16:11 ` Harald Geyer
2016-04-22 16:11 ` Harald Geyer
2016-04-22 16:11 ` Harald Geyer
2016-05-03 11:07 ` Stefan Wahren
2016-05-03 11:07 ` Stefan Wahren
2016-05-03 11:07 ` Stefan Wahren
[not found] ` <57288674.9050601-eS4NqCHxEME@public.gmane.org>
2016-05-03 11:22 ` Harald Geyer
2016-05-03 11:22 ` Harald Geyer
2016-05-03 11:22 ` Harald Geyer
[not found] ` <6cdd4f858dacf72e192a292f29c12feb-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
2016-05-04 7:15 ` Jonathan Cameron
2016-05-04 7:15 ` Jonathan Cameron
2016-05-04 7:15 ` Jonathan Cameron
[not found] ` <1e7d5f3a-22c1-94d4-9620-7aa112602e39-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-05-04 11:38 ` Harald Geyer
2016-05-04 11:38 ` Harald Geyer
2016-05-04 11:38 ` Harald Geyer
2016-04-22 13:52 ` [PATCH 2/3] ARM: dts: imx23: Provide regulators for the current sources of the LRADC Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-22 13:52 ` [PATCH 3/3] ARM: dts: imx28: " Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-22 13:52 ` Harald Geyer
2016-04-29 15:12 ` [PATCH 0/3] mxs-lradc: Add support for current sources Stefan Wahren
2016-04-29 15:12 ` Stefan Wahren
2016-04-29 15:12 ` Stefan Wahren
[not found] ` <572379F5.8000501-eS4NqCHxEME@public.gmane.org>
2016-04-29 17:45 ` Harald Geyer [this message]
2016-04-29 17:45 ` Harald Geyer
2016-04-29 17:45 ` Harald Geyer
2016-05-01 18:02 ` Jonathan Cameron
2016-05-01 18:02 ` Jonathan Cameron
2016-05-01 18:02 ` Jonathan Cameron
[not found] ` <ac57f3e9-f8f2-a6ef-52fa-0a13d7df5d4f-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-05-02 12:25 ` Harald Geyer
2016-05-02 12:25 ` Harald Geyer
2016-05-02 12:25 ` Harald Geyer
2016-05-02 12:29 ` Stefan Wahren
2016-05-02 12:29 ` Stefan Wahren
2016-05-02 12:29 ` Stefan Wahren
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=aadb3f41413d093312c0af3e4c207a8a@ccbib.org \
--to=harald-95f8dae0brpytjvyw6ydsg@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marex-ynQEQJNshbs@public.gmane.org \
--cc=shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=stefan.wahren-eS4NqCHxEME@public.gmane.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.