All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Varadarajan, Charulatha" <charu@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 0/4 RFC]OMAP:GPIO: Make GPIO an early init device
Date: Tue, 16 Feb 2010 11:46:18 -0800	[thread overview]
Message-ID: <20100216194618.GR21755@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C3CF809F@dbde02.ent.ti.com>

* Varadarajan, Charulatha <charu@ti.com> [100216 07:03]:
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Monday, February 15, 2010 11:19 PM
> > To: Paul Walmsley
> > Cc: Varadarajan, Charulatha; linux-omap@vger.kernel.org
> > Subject: Re: [PATCH 0/4 RFC]OMAP:GPIO: Make GPIO an early init device
> > 
> > * Paul Walmsley <paul@pwsan.com> [100214 17:38]:
> > > On Fri, 12 Feb 2010, Paul Walmsley wrote:
> > >
> > > > On Fri, 12 Feb 2010, Varadarajan, Charulatha wrote:
> > > >
> > > > >   OMAP: Convert GPIO into a early driver
> > > >
> > > > The above patch appears to be missing.  Could you please re-send?
> > >
> > > This patch was too big for the mailing list, so it's been posted here:
> 
> 
> Thanks Paul.
> 
> > >
> > > http://www.pwsan.com/omap/patches/gpio/0002-OMAP-GPIO-split-omap1-and-
> > omap2.patch
> > 
> > What, make two almost identical copies of the shared code? No way!
> > Instead, please keep the common code under plat-omap:
> > 
> > arch/arm/plat-omap/gpio.c
> > 
> > Then implement the processor specific functions:
> > 
> > arch/arm/mach-omap1/gpio.c
> > arch/arm/mach-omap2/gpio.c
> > arch/arm/mach-omap2/gpio24xx.c
> > arch/arm/mach-omap2/gpio44xx.c
> > 
> > Then have a subsys_initcall in processor specific implementation
> > that sets the function pointers in the common code.
> > 
> Tony,
> 
> The current gpio.c has functions with code similar as mentioned below:
> {
> 	#ifdef CONFIG_ARCH_OMAP1
> 		Get the reg offset for OMAP1
> 	#endif
> 	#ifdef CONFIG_ARCH_OMAP15XX
> 		Get the reg offset for OMAP15XX
> 	#endif
> 	#ifdef CONFIG_ARCH_OMAP16XX
> 		Get the reg offset for OMAP16XX
> 	#endif
> 	#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> 		Get the reg offset for this OMAP
> 	#endif
> 	#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> 		Get the reg offset for OMAP2&3
> 	#endif
> 	#if defined(CONFIG_ARCH_OMAP4)
> 		Get the reg offset for OMAP4
> 	#endif
> 
> 	Read/write the register 
> }
> 
> If function pointers are used in common code (plat-omap/gpio.c), the API's in this file would essentially do nothing but invoke these pointers. IMHO this is simply adding one unnecessary level of indirection. 
> Please correct me if I am missing out something.

For those you can just set the various reg offsets once
during __init based on the omap type and then the function
stays the same.

For example, in arch/arm/mach-omap2/gpio44xx.c you could
have something like the following (completely untested):

static const struct gpio_reg omap4_gpio_reg[] = {
	...
};

static const struct gpio_bank omap4_gpio_bank[] = {
	...
};

static int omap_gpio_suspend(struct sys_device *dev, pm_message_t mesg)
{
	...
}

static int omap_gpio_resume(struct sys_device *dev)
{
	...
}

const struct omap_gpio omap4_gpio = {
	.regs		= omap4_gpio_reg,
	.banks		= omap4_gpio_bank,
	.suspend	= omap4_gpio_suspend,
	.resume		= omap4_gpio_resume,
	...
};

...

static int __init omap_gpio_init(void)
{
	if (!cpu_is_omap44xx())
		return -ENODEV;

	return omap_gpio_init(omap4_gpio);
}
arch_initcall(omap44xx_gpio_init);

For some of them, you want to be able to implement the whole
function depending on the omap type that you boot.

We're already doing it like this in most places, the gpio.c code
just needs to be updated for that.

Regards,

Tony


  reply	other threads:[~2010-02-16 19:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-12 13:37 [PATCH 0/4 RFC]OMAP:GPIO: Make GPIO an early init device Varadarajan, Charulatha
2010-02-12 13:37 ` [PATCH 1/4 RFC]OMAP2: Fix compile errors Varadarajan, Charulatha
     [not found]   ` <1265981851-11970-3-git-send-email-charu@ti.com>
2010-02-12 13:37     ` [PATCH 3/4 RFC]OMAP:Convert GPIO into a early driver Varadarajan, Charulatha
2010-02-12 13:37       ` [PATCH 4/4 RFC]OMAP:GPIO: Convert all printk's to pr_* in gpio Varadarajan, Charulatha
2010-02-16 23:15   ` [PATCH 1/4 RFC]OMAP2: Fix compile errors Kevin Hilman
2010-03-17 15:12     ` compilation error on hwmods branch Varadarajan, Charulatha
2010-03-17 17:03       ` Tony Lindgren
2010-03-17 17:45         ` Kevin Hilman
2010-02-12 22:31 ` [PATCH 0/4 RFC]OMAP:GPIO: Make GPIO an early init device Paul Walmsley
2010-02-15  1:38   ` Paul Walmsley
2010-02-15 17:49     ` Tony Lindgren
2010-02-16 15:06       ` Varadarajan, Charulatha
2010-02-16 19:46         ` Tony Lindgren [this message]
2010-03-17 14:10           ` Varadarajan, Charulatha
2010-03-17 23:19             ` Tony Lindgren

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=20100216194618.GR21755@atomide.com \
    --to=tony@atomide.com \
    --cc=charu@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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.