From: charu@ti.com (Varadarajan, Charulatha)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver
Date: Mon, 25 Apr 2011 19:33:51 +0530 [thread overview]
Message-ID: <BANLkTikUyA-TrFTqKEuxJ2rEcCK5H7w_Uw@mail.gmail.com> (raw)
In-Reply-To: <87oc3xvrt6.fsf@ti.com>
Kevin,
Thanks for your comments.
On Sat, Apr 23, 2011 at 04:04, Kevin Hilman <khilman@ti.com> wrote:
> Hi Charu,
>
> Charulatha V <charu@ti.com> writes:
>
>> Modifies the OMAP GPIO driver to avoid usage of cpu_is* checks
>> for different OMAP architectures. This is done by moving some
>> architecture specific code to mach-omap* and call them from
>> plat-omap* using function pointers. Also remove the register offset
>> macros from OMAP GPIO driver and handle the same in mach-omap*.
>
> Thanks for working on this cleanup, this driver really needs a cleanup.
>
> You've hit on all the main areas for cleanup, but unfortunately, it's
> not really going in the direction I was hoping. ?Rather than moving code
> into the SoC specific parts, I was hoping to generalize the driver such
> that SoC-specific code would just pass in register offsets/options into
> the common driver. ?Your current approach isn't really reducing code,
> it's just moving it around.
>
> I had started on a similar cleanup as well, and will post that series
> shortly to demonstrate the direction I think the cleanups should be
> going. ?I've tackled most of the same functions/areas that you have
> (except the IRQ triggering stuff), but have a rather different approach.
> I'll get to the IRQ triggering stuff next (after going on vacation for a
> week), but feel free to build on top of my series if you like.
Sure. I will wait for your series.
-V Charulatha
>
> The direction I'd like to go is towards having a generalized driver that
> can not only work across all OMAP SoCs, but also hopefully towards
> something that can be shared with other SoCs as well. ?Of course, the
> first step is cleaning up the OMAP driver, but the next step will be
> looking for other areas of consolidation. ?Towards that end, I'm also
> working towards converting the GPIO IRQs in this driver to use the new
> generic IRQ chip infrastructure posted by Thomas Gleixner. ?In my
> series, you'll see that I started that for the MPUIO IRQs, but the GPIO
> IRQs will come next.
>
> Kevin
>
prev parent reply other threads:[~2011-04-25 14:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 11:08 [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver Charulatha V
2011-04-22 11:08 ` [RFC PATCH 01/18] OMAP1: GPIO: Fix mpuio_init() call Charulatha V
2011-04-22 11:08 ` [RFC PATCH 02/18] OMAP: GPIO: remove get_gpio_bank() Charulatha V
2011-04-22 11:08 ` [RFC PATCH 03/18] OMAP: GPIO: Move gpio_get_index() to mach-omap Charulatha V
2011-04-22 14:59 ` Kevin Hilman
2011-04-22 11:08 ` [RFC PATCH 04/18] OMAP: GPIO: Move gpio_valid() to SoC specific files Charulatha V
2011-04-22 15:15 ` Kevin Hilman
2011-04-22 11:08 ` [RFC PATCH 05/18] OMAP: GPIO: cleanup datain,dataout,set dir funcs Charulatha V
2011-04-22 15:22 ` [RFC PATCH 05/18] OMAP: GPIO: cleanup datain, dataout, set " Kevin Hilman
2011-04-22 11:08 ` [RFC PATCH 06/18] OMAP: GPIO: cleanup set trigger func Charulatha V
2011-04-22 11:08 ` [RFC PATCH 07/18] OMAP: GPIO: cleanup set/get IRQ, clr irqstatus funcs Charulatha V
2011-04-22 11:08 ` [RFC PATCH 08/18] OMAP: GPIO: req/free: Remove reg offset macros usage Charulatha V
2011-04-22 11:08 ` [RFC PATCH 09/18] OMAP: GPIO: cleanup gpio_irq_handler Charulatha V
2011-04-22 11:08 ` [RFC PATCH 10/18] OMAP: GPIO: cleanup set wakeup/suspend/resume funcs Charulatha V
2011-04-22 11:08 ` [RFC PATCH 11/18] OMAP: GPIO: Remove dependency on gpio_bank_count Charulatha V
2011-04-22 16:04 ` Kevin Hilman
2011-04-22 11:08 ` [RFC PATCH 12/18] OMAP: GPIO: cleanup set_debounce, idle/resume_after_idle Charulatha V
2011-04-22 11:08 ` [RFC PATCH 13/18] OMAP: GPIO: cleanup save/restore context Charulatha V
2011-04-22 11:08 ` [RFC PATCH 14/18] OMAP: GPIO: Remove CONFIG_ARCH_OMAP16XX/OMAP2+ defines Charulatha V
2011-04-22 11:08 ` [RFC PATCH 15/18] OMAP: GPIO: cleanup gpio_show_rev Charulatha V
2011-04-22 11:08 ` [RFC PATCH 16/18] OMAP: GPIO: move omap_gpio_mod_init to mach-omap Charulatha V
2011-04-22 11:08 ` [RFC PATCH 17/18] OMAP: GPIO: use dev_err* instead of printk Charulatha V
2011-04-22 11:08 ` [RFC PATCH 18/18] OMAP: GPIO: Remove usage of bank method Charulatha V
2011-04-22 14:02 ` [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver Sascha Hauer
2011-04-22 22:34 ` Kevin Hilman
2011-04-25 14:03 ` Varadarajan, Charulatha [this message]
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=BANLkTikUyA-TrFTqKEuxJ2rEcCK5H7w_Uw@mail.gmail.com \
--to=charu@ti.com \
--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 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).