From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
Linus Walleij <linus.walleij@linaro.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
dg77.kim@samsung.com, linux-samsung-soc@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
myungjoo.ham@gmail.com, Changhwan Youn <chaos.youn@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 2/3] Samsung SoC: ready to use NTC value inside kernel
Date: Fri, 1 Jul 2011 19:23:13 +0200 [thread overview]
Message-ID: <201107011923.13324.arnd@arndb.de> (raw)
In-Reply-To: <20110701155941.GA23784@opensource.wolfsonmicro.com>
On Friday 01 July 2011, Mark Brown wrote:
> On Fri, Jul 01, 2011 at 05:15:05PM +0200, Linus Walleij wrote:
>
> > There is no clean nice ADC subsystem though, and that feels
> > like a big problem to drivers like this (and no I don't like the AB8500
> > GPADC living in MFD either) so if you'd like to create a ADC
> > subsystem just go ahead, there is something in drivers/staging/iio/adc
> > but that had another problem last time I looked: it was only intended
> > for userspace control, not in-kernel use.
Agreed.
> The other issue is that it's designed for high volume data and these
> AUXADCs tend to be relatively slow. That said I've had some discussions
> with Jonathan about supporting these devices via IIO and he seems to be
> coming round to the idea that we could integrate support. Not sure how
> fast IIO is progressing to mainline, though.
I think IIO is progressing well and I would rather base products on that
while it's in staging than having a random out-of-tree driver. It seems
to fit the purpose of this driver, though not the in-kernel uses that
Linus mentioned above.
We have a bunch of things that seem to me like they should live together:
gpio, pinmux, pwm and adc. There are ongoing discussions about pinmux
and pwm subsystems right now, so it might be the right time to discuss
where we are going with these in general.
With regard to IIO, that could live on a higher level and just provide
a user interface on top of the generic in-kernel abstraction for adc.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] Samsung SoC: ready to use NTC value inside kernel
Date: Fri, 1 Jul 2011 19:23:13 +0200 [thread overview]
Message-ID: <201107011923.13324.arnd@arndb.de> (raw)
In-Reply-To: <20110701155941.GA23784@opensource.wolfsonmicro.com>
On Friday 01 July 2011, Mark Brown wrote:
> On Fri, Jul 01, 2011 at 05:15:05PM +0200, Linus Walleij wrote:
>
> > There is no clean nice ADC subsystem though, and that feels
> > like a big problem to drivers like this (and no I don't like the AB8500
> > GPADC living in MFD either) so if you'd like to create a ADC
> > subsystem just go ahead, there is something in drivers/staging/iio/adc
> > but that had another problem last time I looked: it was only intended
> > for userspace control, not in-kernel use.
Agreed.
> The other issue is that it's designed for high volume data and these
> AUXADCs tend to be relatively slow. That said I've had some discussions
> with Jonathan about supporting these devices via IIO and he seems to be
> coming round to the idea that we could integrate support. Not sure how
> fast IIO is progressing to mainline, though.
I think IIO is progressing well and I would rather base products on that
while it's in staging than having a random out-of-tree driver. It seems
to fit the purpose of this driver, though not the in-kernel uses that
Linus mentioned above.
We have a bunch of things that seem to me like they should live together:
gpio, pinmux, pwm and adc. There are ongoing discussions about pinmux
and pwm subsystems right now, so it might be the right time to discuss
where we are going with these in general.
With regard to IIO, that could live on a higher level and just provide
a user interface on top of the generic in-kernel abstraction for adc.
Arnd
next prev parent reply other threads:[~2011-07-01 17:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 8:26 [PATCH 0/3] ARM: EXYNOS4: NURI Support NTC MyungJoo Ham
2011-06-30 8:26 ` MyungJoo Ham
2011-06-30 8:26 ` [PATCH 1/3] Samsung SoC: NTC Thermistor attached to S3C-ADC MyungJoo Ham
2011-06-30 8:26 ` MyungJoo Ham
2011-06-30 8:26 ` [PATCH 2/3] Samsung SoC: ready to use NTC value inside kernel MyungJoo Ham
2011-06-30 8:26 ` MyungJoo Ham
2011-06-30 9:00 ` Russell King - ARM Linux
2011-06-30 9:00 ` Russell King - ARM Linux
2011-07-01 0:28 ` MyungJoo Ham
2011-07-01 0:28 ` MyungJoo Ham
2011-07-01 15:15 ` Linus Walleij
2011-07-01 15:15 ` Linus Walleij
2011-07-01 15:59 ` Mark Brown
2011-07-01 15:59 ` Mark Brown
2011-07-01 17:23 ` Arnd Bergmann [this message]
2011-07-01 17:23 ` Arnd Bergmann
2011-07-01 20:10 ` Mark Brown
2011-07-01 20:10 ` Mark Brown
2011-06-30 8:26 ` [PATCH 3/3] Exynos4 NURI: support for NTC thermistor MyungJoo Ham
2011-06-30 8:26 ` MyungJoo Ham
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=201107011923.13324.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=chaos.youn@samsung.com \
--cc=dg77.kim@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=myungjoo.ham@gmail.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.