From: Harald Geyer <harald@ccbib.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
<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: Mon, 02 May 2016 14:25:00 +0200 [thread overview]
Message-ID: <a0d59747ffca9d900feecece4cfcae82@ccbib.org> (raw)
In-Reply-To: <ac57f3e9-f8f2-a6ef-52fa-0a13d7df5d4f@kernel.org>
On 01.05.2016 20:02, Jonathan Cameron wrote:
> On 29/04/16 18:45, Harald Geyer wrote:
>> 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?
> I agree with that approach - need a way to describe the upstream
> hardware - so
> will need a thermistor driver
>>
>> 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.
> Hmm. Are you talking about muxing the regulator as well? That will
> get
> complex indeed. Might be possible to cheat and imply the regulators
> are
> always connected to all inputs... or do you want to dynamically
> change
> the regulator output? That gets messy fast - though in theory might
> be
> possible...
Yes, that's a good summary of what I'm thinking. As there is no
iio-multiplexer yet, this is sort of an academic question. But it's
kind of an obvious thing to want, so we shouldn't be surprised when
somebody actually starts working on that.
Thanks,
Harald
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: Mon, 02 May 2016 14:25:00 +0200 [thread overview]
Message-ID: <a0d59747ffca9d900feecece4cfcae82@ccbib.org> (raw)
In-Reply-To: <ac57f3e9-f8f2-a6ef-52fa-0a13d7df5d4f@kernel.org>
On 01.05.2016 20:02, Jonathan Cameron wrote:
> On 29/04/16 18:45, Harald Geyer wrote:
>> 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?
> I agree with that approach - need a way to describe the upstream
> hardware - so
> will need a thermistor driver
>>
>> 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.
> Hmm. Are you talking about muxing the regulator as well? That will
> get
> complex indeed. Might be possible to cheat and imply the regulators
> are
> always connected to all inputs... or do you want to dynamically
> change
> the regulator output? That gets messy fast - though in theory might
> be
> possible...
Yes, that's a good summary of what I'm thinking. As there is no
iio-multiplexer yet, this is sort of an academic question. But it's
kind of an obvious thing to want, so we shouldn't be surprised when
somebody actually starts working on that.
Thanks,
Harald
WARNING: multiple messages have this Message-ID (diff)
From: Harald Geyer <harald-95f8Dae0BrPYtjvyW6yDsg@public.gmane.org>
To: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Stefan Wahren <stefan.wahren-eS4NqCHxEME@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: Mon, 02 May 2016 14:25:00 +0200 [thread overview]
Message-ID: <a0d59747ffca9d900feecece4cfcae82@ccbib.org> (raw)
In-Reply-To: <ac57f3e9-f8f2-a6ef-52fa-0a13d7df5d4f-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 01.05.2016 20:02, Jonathan Cameron wrote:
> On 29/04/16 18:45, Harald Geyer wrote:
>> 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?
> I agree with that approach - need a way to describe the upstream
> hardware - so
> will need a thermistor driver
>>
>> 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.
> Hmm. Are you talking about muxing the regulator as well? That will
> get
> complex indeed. Might be possible to cheat and imply the regulators
> are
> always connected to all inputs... or do you want to dynamically
> change
> the regulator output? That gets messy fast - though in theory might
> be
> possible...
Yes, that's a good summary of what I'm thinking. As there is no
iio-multiplexer yet, this is sort of an academic question. But it's
kind of an obvious thing to want, so we shouldn't be surprised when
somebody actually starts working on that.
Thanks,
Harald
next prev parent reply other threads:[~2016-05-02 12:25 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
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
2016-04-22 15:50 ` Marek Vasut
2016-04-22 15:50 ` Marek Vasut
2016-04-22 15:50 ` Marek Vasut
2016-04-22 17:00 ` Ksenija Stanojević
2016-04-22 17:00 ` Ksenija Stanojević
2016-04-22 17:00 ` Ksenija Stanojević
2016-04-22 19:23 ` Harald Geyer
2016-04-22 19:23 ` Harald Geyer
2016-04-22 19:23 ` Harald Geyer
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
2016-05-03 11:22 ` Harald Geyer
2016-05-03 11:22 ` Harald Geyer
2016-05-03 11:22 ` Harald Geyer
2016-05-04 7:15 ` Jonathan Cameron
2016-05-04 7:15 ` Jonathan Cameron
2016-05-04 7:15 ` Jonathan Cameron
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
2016-04-29 17:45 ` Harald Geyer
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
2016-05-02 12:25 ` Harald Geyer [this message]
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=a0d59747ffca9d900feecece4cfcae82@ccbib.org \
--to=harald@ccbib.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=shawnguo@kernel.org \
--cc=stefan.wahren@i2se.com \
/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.