linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Zoltan Devai <zoss@devai.org>,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>,
	linux-iio@vger.kernel.org,
	Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH 4/9] ARM: SPMP8000: Add ADC driver
Date: Mon, 10 Oct 2011 10:46:56 +0100	[thread overview]
Message-ID: <4E92BF10.9000301@cam.ac.uk> (raw)
In-Reply-To: <4E92BE19.4060907@cam.ac.uk>

On 10/10/11 10:42, Jonathan Cameron wrote:
> On 10/10/11 02:29, Linus Walleij wrote:
>> 2011/10/9 Zoltan Devai <zoss@devai.org>:
>>
>>> Signed-off-by: Zoltan Devai <zoss@devai.org>
>>> ---
>>>  arch/arm/mach-spmp8000/adc.c                      |  465 +++++++++++++++++++++
>>>  arch/arm/mach-spmp8000/include/mach/spmp8000adc.h |   29 ++
>>
>> I think we stopped stuffing misc drivers under arch/arm/*
>>
>> And stuffing them under drivers/misc/* won't be popular either.
>>
>> IIO has some ADCs in drivers/staging/iio/adc
>> these seem all to be intended to be used from userspace.
> Yeah, we've had various discussions about adding support for
> in kernel users. Its always fallen on the fact that no one
> has had the time to write the code to allow it all to be
> linked up.  Right now it's a case of drivers providing their
> own interfaces if they want to allow this.
> Mark Brown has raised this issue before so I've cc'd him.
> 
> For reference of those not following the original thread (based
> on a quick scan of the driver code in question).
> 
> Driver has two callback sets:
> 
> 1) Touch panel reads (I guess going straight to an input driver)
> (1 of these only). This is annoyingly tied up with the more general
> adc registers.
> 2) General purpose adc callbacks. 
> 
> Both are driven off an interrupt, but data ready
> appears to manually driven (so software triggered sampling then data
> ready signal when sampling is done for a single channel).
> 
> So what are these callbacks used for?  Note they all run as
> interrupt top halves...
> 
> Options at current time are:
> 
> mfd supporting input device and either hwmon or iio device.
> 
> A driver that hosts both a hwmon / iio and an input device.
> 
> Be brave (+ have a lot of time) and propose patches adding the relevant
> tying together code to allow iio drivers to be queried in kernel.
> It shouldn't be that bad actually if you solve the how to work
> out which device / channel you want in a consistent way.
> 
> It really depends on what those general adc callbacks get used for.
Ah, just taken a look at your dts file.

Looks like some are used for 'analog-keys'.  So input? If so this
should probably be an entirely input driver for now.

> 
>>
>> There are a few in-kernel ADCs all over the kernel tree
>> for various specific purposes.
>>
>> I don't know where we should go with this kind of stuff,
>> really :-/
>>
>> Yours,
>> Linus Walleij
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2011-10-10  9:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1318178172-7965-1-git-send-email-zoss@devai.org>
     [not found] ` <1318178172-7965-5-git-send-email-zoss@devai.org>
2011-10-10  1:29   ` [PATCH 4/9] ARM: SPMP8000: Add ADC driver Linus Walleij
2011-10-10  9:42     ` Jonathan Cameron
2011-10-10  9:46       ` Jonathan Cameron [this message]
2011-10-10 10:00       ` Mark Brown
2011-10-10 11:42         ` Zoltan Devai
2011-10-10 11:44           ` Mark Brown
2011-10-11 14:17             ` Arnd Bergmann
2011-10-11 14:40               ` Mark Brown
2011-10-11 15:24                 ` Arnd Bergmann
2011-10-11 15:39                   ` Jonathan Cameron
2011-10-12 14:42                   ` Mark Brown
2011-10-12 15:41                     ` Jonathan Cameron
2011-10-13  9:47             ` Russell King - ARM Linux
2011-10-13 11:09               ` Linus Walleij
2011-10-13 11:35                 ` Jonathan Cameron
2011-10-13 11:35               ` Mark Brown
2011-10-13 12:17                 ` Russell King - ARM Linux
2011-10-13 14:19                   ` Arnd Bergmann
2011-10-13 14:27                     ` Mark Brown
2011-10-13 14:38                   ` Mark Brown
2011-10-13 14:56                     ` Arnd Bergmann
2011-10-13 16:25                       ` Mark Brown

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=4E92BF10.9000301@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=zoss@devai.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;
as well as URLs for NNTP newsgroup(s).