From: jic23@cam.ac.uk (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mx28: added LRADC and touchscreen support
Date: Sun, 27 Nov 2011 11:26:06 +0000 [thread overview]
Message-ID: <4ED21E4E.5090004@cam.ac.uk> (raw)
In-Reply-To: <201111251602.35227.arnd@arndb.de>
...
>> diff --git a/arch/arm/mach-mxs/include/mach/lradc.h b/arch/arm/mach-mxs/include/mach/lradc.h
>> new file mode 100644
>> index 0000000..c2c0a7d
>
>> +
>> +int hw_lradc_use_channel(int);
>> +int hw_lradc_unuse_channel(int);
>> +extern u32 hw_lradc_vddio(void);
>> +void hw_lradc_set_delay_trigger_kick(int trigger, int value);
>> +void hw_lradc_configure_channel(int channel, int enable_div2,
>> + int enable_acc, int samples);
>> +int hw_lradc_present(int channel);
>> +int hw_lradc_init_ladder(int channel, int trigger, unsigned sampling);
>> +int hw_lradc_stop_ladder(int channel, int trigger);
>> +void hw_lradc_set_delay_trigger(int trigger, u32 trigger_lradc,
>> + u32 delay_triggers, u32 loops, u32 delays);
>> +void hw_lradc_clear_delay_trigger(int trigger, u32 trigger_lradc,
>> + u32 delay_triggers);
>
> As indicated by Shawn, adding a new driver specific kernel-level ADC
> interface is not a good idea. IIRC, the result of the last discussion
> was that all ADC drivers should be part of IIO and you should use
> the IIO in-kernel interfaces. Not sure what the state of that code
> is, but if it's not in mainline yet, you should work with Jonathan
> to make sure it gets there. Having more users for that code can
> only speed up the process, and I'm going to refuse another ADC driver
> in drivers/misc or arch/arm/mach-*/.
Quick summary of IIO status. Nothing is in mainline yet. Intent is to
get the first set of core code (including in kernel pull interfaces)
into linux-next fairly shortly (these have had enough postive feedback
now I think). Doing push interfaces (as I think we would need here) is
possible with existing patches on top of the stuff in the iio staging
tree but there are some 'interesting' cases where both push and pull
interfaces exist that still need addressing.
Also, note the push interface stuff (e.g. interrupt driven) requires a
lot more of the IIO infrastructure to be in place (buffered support and
the demux unit) so may still be some time. Personally my time is
currently very restricted so all the help anyone can offer is most welcome!
Jonathan
next prev parent reply other threads:[~2011-11-27 11:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-24 11:49 [PATCH] mx28: added LRADC and touchscreen support Peter Rusko
2011-11-24 12:59 ` Shawn Guo
2011-11-24 15:45 ` Peter Rusko
2011-11-24 22:59 ` Shawn Guo
2011-11-24 13:56 ` Lothar Waßmann
2011-11-24 14:44 ` Fabio Estevam
2011-11-24 15:01 ` Fabio Estevam
2011-11-24 21:10 ` Russell King - ARM Linux
2011-11-24 21:11 ` Russell King - ARM Linux
2011-11-25 16:02 ` Arnd Bergmann
2011-11-27 11:26 ` Jonathan Cameron [this message]
2011-11-29 19:09 ` Arnd Bergmann
2011-11-30 15:05 ` Peter Rusko
2012-01-23 18:28 ` Marek Vasut
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=4ED21E4E.5090004@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=linux-arm-kernel@lists.infradead.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.