All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Charulatha V <charu@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	tony@atomide.com, khilman@ti.com, paul@pwsan.com
Subject: Re: [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver
Date: Fri, 22 Apr 2011 16:02:39 +0200	[thread overview]
Message-ID: <20110422140239.GG15233@pengutronix.de> (raw)
In-Reply-To: <1303470512-19671-1-git-send-email-charu@ti.com>

Hi,

On Fri, Apr 22, 2011 at 04:38:14PM +0530, Charulatha V wrote:
> 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*.
> 
> Avoid usage of gpio_bank_count and gpio_bank pointer array by
> means of maintaining a list. Removes the bank->method flag from
> the GPIO driver.
> 
> All OMAP1 SoCs has one MPUIO type GPIO bank. OMAP2+ does not have
> any MPUIO type GPIO bank. Since MPUIO type GPIO bank is the same for
> all OMAP1 CPUs, they are handled in plat-omap/ itself as
> there is no common gpio.c file for all cpu types in mach-omap1.
> They are identified by using bank->stride flag as it is '0'
> for other than MPUIO type banks.

The omap gpio code clearly deserves a cleanup, but I think this series
does not go far enough. There are only a handful of possible ways to
implement a gpio hardware, most of them can be abstracted in a similar
way Thomas did for the irq handlers and then we can handle most SoC
specific gpio code in generic code.

Something like the following comes to my mind:

struct gpio_chip_mmio_regs {
	unsigned long output_set_reg;
	unsigned long output_clean_reg;
	unsigned long direction_reg;
	unsigned long status_reg;
};

struct gpio_chip_mmio {
	struct gpio_chip_mmio_regs *regs;
	void __iomem *base;
	void (*direction_output)(struct gpio_chip_mmio *, int);
	void (*direction_input)(struct gpio_chip_mmio *, int);
	struct gpio_chip chip;
};

int gpio_chip_mmio_add(struct gpio_chip_mmio *);

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/18] OMAP: GPIO: cleanup GPIO driver
Date: Fri, 22 Apr 2011 16:02:39 +0200	[thread overview]
Message-ID: <20110422140239.GG15233@pengutronix.de> (raw)
In-Reply-To: <1303470512-19671-1-git-send-email-charu@ti.com>

Hi,

On Fri, Apr 22, 2011 at 04:38:14PM +0530, Charulatha V wrote:
> 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*.
> 
> Avoid usage of gpio_bank_count and gpio_bank pointer array by
> means of maintaining a list. Removes the bank->method flag from
> the GPIO driver.
> 
> All OMAP1 SoCs has one MPUIO type GPIO bank. OMAP2+ does not have
> any MPUIO type GPIO bank. Since MPUIO type GPIO bank is the same for
> all OMAP1 CPUs, they are handled in plat-omap/ itself as
> there is no common gpio.c file for all cpu types in mach-omap1.
> They are identified by using bank->stride flag as it is '0'
> for other than MPUIO type banks.

The omap gpio code clearly deserves a cleanup, but I think this series
does not go far enough. There are only a handful of possible ways to
implement a gpio hardware, most of them can be abstracted in a similar
way Thomas did for the irq handlers and then we can handle most SoC
specific gpio code in generic code.

Something like the following comes to my mind:

struct gpio_chip_mmio_regs {
	unsigned long output_set_reg;
	unsigned long output_clean_reg;
	unsigned long direction_reg;
	unsigned long status_reg;
};

struct gpio_chip_mmio {
	struct gpio_chip_mmio_regs *regs;
	void __iomem *base;
	void (*direction_output)(struct gpio_chip_mmio *, int);
	void (*direction_input)(struct gpio_chip_mmio *, int);
	struct gpio_chip chip;
};

int gpio_chip_mmio_add(struct gpio_chip_mmio *);

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2011-04-22 14:02 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 ` Sascha Hauer [this message]
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-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=20110422140239.GG15233@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=charu@ti.com \
    --cc=khilman@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.