From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Mon, 02 May 2016 14:25:00 +0200 From: Harald Geyer To: Jonathan Cameron Cc: Stefan Wahren , , , Shawn Guo , Sascha Hauer , Marek Vasut , Subject: Re: [PATCH 0/3] mxs-lradc: Add support for current sources In-Reply-To: References: <1461333147-11873-1-git-send-email-harald@ccbib.org> <572379F5.8000501@i2se.com> Message-ID: List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: harald@ccbib.org (Harald Geyer) Date: Mon, 02 May 2016 14:25:00 +0200 Subject: [PATCH 0/3] mxs-lradc: Add support for current sources In-Reply-To: References: <1461333147-11873-1-git-send-email-harald@ccbib.org> <572379F5.8000501@i2se.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harald Geyer Subject: Re: [PATCH 0/3] mxs-lradc: Add support for current sources Date: Mon, 02 May 2016 14:25:00 +0200 Message-ID: References: <1461333147-11873-1-git-send-email-harald@ccbib.org> <572379F5.8000501@i2se.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jonathan Cameron Cc: Stefan Wahren , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo , Sascha Hauer , Marek Vasut , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.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