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 05/18] OMAP: GPIO: cleanup datain,dataout,set dir funcs
Date: Fri, 22 Apr 2011 08:22:59 -0700 [thread overview]
Message-ID: <8739laz4x8.fsf@ti.com> (raw)
In-Reply-To: <1303470512-19671-6-git-send-email-charu@ti.com> (Charulatha V.'s message of "Fri, 22 Apr 2011 16:38:19 +0530")
Charulatha V <charu@ti.com> writes:
> * Define gpio register offsets in SoC specific GPIO files and use
> these register offsets while doing register read/write
> * Remove the usage of CONFIG_ARCH_* checks and cpu_is* checks from
> the below functions
> _set_gpio_direction
> _set_gpio_dataout
> _get_gpio_dataout
> _get_gpio_datain
> * MPUIO is a common gpio bank->method for OMAP15xx, OMAP16xx and
> OMAP7xx SoCs. Each of these SoCs has one bank with MPUIO type.
> Hence handle MPUIO type GPIO banks in GPIO driver.
>
> Note: After the complete driver is cleaned up, the register offset
> macros defined in OMAP GPIO driver would be removed
>
> Signed-off-by: Charulatha V <charu@ti.com>
IMO, this isn't quite the direction we want to go for this cleanup.
Register offsets should indeed be in SoC specific files, but rather than
the driver calling pdata function pointers for the functions, the
register offsets should instead be passed into the driver so the driver
can have common functions.
Also, MPUIO doesn't need to be treated as a special case. From the
GPIO driver perspective, it's just another GPIO bank. On some SoCs, it
happens to have a different width and stride, but the drive should
handle that.
I've also started on a GPIO cleanup (currently posted to linux-omap
only) and I've taken a different approach.
After I finish reviewing your series, I'll have some more ideas on
how we might combine our efforts here.
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 05/18] OMAP: GPIO: cleanup datain, dataout, set dir funcs
Date: Fri, 22 Apr 2011 08:22:59 -0700 [thread overview]
Message-ID: <8739laz4x8.fsf@ti.com> (raw)
In-Reply-To: <1303470512-19671-6-git-send-email-charu@ti.com> (Charulatha V.'s message of "Fri, 22 Apr 2011 16:38:19 +0530")
Charulatha V <charu@ti.com> writes:
> * Define gpio register offsets in SoC specific GPIO files and use
> these register offsets while doing register read/write
> * Remove the usage of CONFIG_ARCH_* checks and cpu_is* checks from
> the below functions
> _set_gpio_direction
> _set_gpio_dataout
> _get_gpio_dataout
> _get_gpio_datain
> * MPUIO is a common gpio bank->method for OMAP15xx, OMAP16xx and
> OMAP7xx SoCs. Each of these SoCs has one bank with MPUIO type.
> Hence handle MPUIO type GPIO banks in GPIO driver.
>
> Note: After the complete driver is cleaned up, the register offset
> macros defined in OMAP GPIO driver would be removed
>
> Signed-off-by: Charulatha V <charu@ti.com>
IMO, this isn't quite the direction we want to go for this cleanup.
Register offsets should indeed be in SoC specific files, but rather than
the driver calling pdata function pointers for the functions, the
register offsets should instead be passed into the driver so the driver
can have common functions.
Also, MPUIO doesn't need to be treated as a special case. From the
GPIO driver perspective, it's just another GPIO bank. On some SoCs, it
happens to have a different width and stride, but the drive should
handle that.
I've also started on a GPIO cleanup (currently posted to linux-omap
only) and I've taken a different approach.
After I finish reviewing your series, I'll have some more ideas on
how we might combine our efforts here.
Kevin
next prev parent reply other threads:[~2011-04-22 15:23 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 [this message]
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
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=8739laz4x8.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.