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: Wed, 17 Mar 2010 16:19:27 -0700	[thread overview]
Message-ID: <20100317231927.GL2900@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C489C445@dbde02.ent.ti.com>

* Varadarajan, Charulatha <charu@ti.com> [100317 07:07]:
> Tony, 
> 
> > > > >
> > > > > 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.
> 
> Thanks. Can you please specify some example code & location in the 
> current code base, so that I can align exactly before sending my
> next version of patches? 

See mach-omap2/clock.c for example for struct clk_functions.

Please do the changes in a set where each change patch can be
easily reviewed and tested. Maybe something like the following
patches:

1. Add support for passing platform_data to omap_gpio_init()
2. Add support for implementing SoC specific omap_gpio_AAA()
3. Add support for implementing SoC specific omap_gpio_BBB()
4. Add support for implementing SoC specific omap_gpio_CCC()
...


Regards,

Tony

      reply	other threads:[~2010-03-17 23:17 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
2010-03-17 14:10           ` Varadarajan, Charulatha
2010-03-17 23:19             ` Tony Lindgren [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=20100317231927.GL2900@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.