From: Kevin Hilman <khilman@ti.com>
To: Charulatha V <charu@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
tony@atomide.com, paul@pwsan.com
Subject: Re: [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver
Date: Fri, 22 Apr 2011 15:34:29 -0700 [thread overview]
Message-ID: <87oc3xvrt6.fsf@ti.com> (raw)
In-Reply-To: <1303470512-19671-1-git-send-email-charu@ti.com> (Charulatha V.'s message of "Fri, 22 Apr 2011 16:38:14 +0530")
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.
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
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver
Date: Fri, 22 Apr 2011 15:34:29 -0700 [thread overview]
Message-ID: <87oc3xvrt6.fsf@ti.com> (raw)
In-Reply-To: <1303470512-19671-1-git-send-email-charu@ti.com> (Charulatha V.'s message of "Fri, 22 Apr 2011 16:38:14 +0530")
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.
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
next prev parent reply other threads:[~2011-04-22 22:34 UTC|newest]
Thread overview: 52+ 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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 01/18] OMAP1: GPIO: Fix mpuio_init() call Charulatha V
2011-04-22 11:08 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 02/18] OMAP: GPIO: remove get_gpio_bank() Charulatha V
2011-04-22 11:08 ` 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 11:08 ` Charulatha V
2011-04-22 14:59 ` Kevin Hilman
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 11:08 ` Charulatha V
2011-04-22 15:15 ` Kevin Hilman
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 11:08 ` Charulatha V
2011-04-22 15:22 ` Kevin Hilman
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 ` 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 ` 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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 09/18] OMAP: GPIO: cleanup gpio_irq_handler Charulatha V
2011-04-22 11:08 ` 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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 11/18] OMAP: GPIO: Remove dependency on gpio_bank_count Charulatha V
2011-04-22 11:08 ` Charulatha V
2011-04-22 16:04 ` Kevin Hilman
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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 13/18] OMAP: GPIO: cleanup save/restore context Charulatha V
2011-04-22 11:08 ` 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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 15/18] OMAP: GPIO: cleanup gpio_show_rev Charulatha V
2011-04-22 11:08 ` 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 ` 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 ` Charulatha V
2011-04-22 11:08 ` [RFC PATCH 18/18] OMAP: GPIO: Remove usage of bank method Charulatha V
2011-04-22 11:08 ` Charulatha V
2011-04-22 14:02 ` [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver Sascha Hauer
2011-04-22 14:02 ` Sascha Hauer
2011-04-22 22:34 ` Kevin Hilman [this message]
2011-04-22 22:34 ` Kevin Hilman
2011-04-25 14:03 ` Varadarajan, Charulatha
2011-04-25 14:03 ` Varadarajan, Charulatha
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=87oc3xvrt6.fsf@ti.com \
--to=khilman@ti.com \
--cc=charu@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tony@atomide.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.