public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Varadarajan, Charulatha" <charu@ti.com>
Cc: "felipe.balbi@nokia.com" <felipe.balbi@nokia.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Nayak, Rajendra" <rnayak@ti.com>,
	"paul@pwsan.com" <paul@pwsan.com>
Subject: Re: [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific header
Date: Thu, 1 Apr 2010 02:41:17 -0700	[thread overview]
Message-ID: <20100401094116.GJ31200@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C4B8F28D@dbde02.ent.ti.com>

* Varadarajan, Charulatha <charu@ti.com> [100401 01:48]:
> > 
> > Add prefixes to these defines and remove the ifdefs.
> > This breaks multi-omap builds.
> 
> AFAIK multi-omap build not applicable for OMAP1

Wrong. Multi-omap for omap1 has been mostly working for
about 5 years. In general, we don't want to apply patches
that obviously break things like that.

If you take a look at arch/arm/mach-omap1/Kconfig, there's
no "choice" there between omap1 socs.
 
> > 
> > >-struct gpio_bank {
> > >-       unsigned long pbase;
> > >-       void __iomem *base;
> > >-       u16 irq;
> > >-       u16 virtual_irq_start;
> > >-       int method;
> > >-#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
> > >-       u32 suspend_wakeup;
> > >-       u32 saved_wakeup;
> > >-#endif
> > >-#ifdef CONFIG_ARCH_OMAP2PLUS
> > >-       u32 non_wakeup_gpios;
> > >-       u32 enabled_non_wakeup_gpios;
> > >-
> > >-       u32 saved_datain;
> > >-       u32 saved_fallingdetect;
> > >-       u32 saved_risingdetect;
> > >-#endif
> > >-       u32 level_mask;
> > >-       u32 toggle_mask;
> > >-       spinlock_t lock;
> > >-       struct gpio_chip chip;
> > >-       struct clk *dbck;
> > >-       u32 mod_usage;
> > >-};
> > 
> > defines are fine, but this structure belongs to this driver. Nobody else
> > should need to poke on it. Keep it here.
> 
> This would get used in mach-omap layers in the later patches.
> Hence moving it to gpio.h

Why would the hwmod code need to know about the register layout?
That's totally gpio specific.
 
> > >@@ -625,10 +421,12 @@ void omap_set_gpio_debounce(int gpio, int enable)
> > >        bank = get_gpio_bank(gpio);
> > >        reg = bank->base;
> > >
> > >+#ifdef CONFIG_ARCH_OMAP2PLUS
> > >        if (cpu_is_omap44xx())
> > >                reg += OMAP4_GPIO_DEBOUNCENABLE;
> > >        else
> > >                reg += OMAP24XX_GPIO_DEBOUNCE_EN;
> > >+#endif
> > 
> > you should try to remove ifdefs not add more.
> 
> As mentioned in the beginning of this patch, these are
> only temporary and all possible #ifdefs are removed at
> the end of this patch series when plat-omap/gpio.c handles
> only common APIs.

You need to first implement just initializing things using the
platform data. Only then start messing with the functions.

Tony

  parent reply	other threads:[~2010-04-01  9:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 12:23 [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS Charulatha V
2010-03-31 12:23 ` [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific header Charulatha V
2010-03-31 12:23   ` [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device Charulatha V
2010-03-31 12:23     ` [PATCH 3/8] OMAP2:GPIO:Add " Charulatha V
2010-03-31 12:23       ` [PATCH 4/8] OMAP4:GPIO:Add " Charulatha V
2010-03-31 12:23         ` [PATCH 5/8] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support Charulatha V
2010-03-31 12:23           ` [PATCH 6/8] OMAP1:GPIO:Support for OMAP1 specific gpio Charulatha V
2010-03-31 12:23             ` [PATCH 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw Charulatha V
2010-03-31 12:23               ` [PATCH 8/8] OMAP:GPIO:Common platform code for all OMAPs Charulatha V
2010-04-01  9:34                 ` Tony Lindgren
2010-04-01  9:32               ` [PATCH 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw Tony Lindgren
2010-04-01 10:50                 ` Varadarajan, Charulatha
2010-04-06 22:13               ` Kevin Hilman
2010-04-01  9:30           ` [PATCH 5/8] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support Tony Lindgren
2010-04-06 22:08             ` Kevin Hilman
2010-04-01  7:26       ` [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device Felipe Balbi
2010-04-01  8:53         ` Varadarajan, Charulatha
2010-04-01  8:58           ` Felipe Balbi
2010-04-01  9:16             ` Varadarajan, Charulatha
2010-04-01  7:23     ` [PATCH 2/8] OMAP3:GPIO:Add " Felipe Balbi
2010-04-01  8:58       ` Varadarajan, Charulatha
2010-04-01  9:12         ` Tony Lindgren
2010-04-01  9:19           ` Varadarajan, Charulatha
2010-04-01  9:13     ` Tony Lindgren
2010-04-01 10:49       ` Varadarajan, Charulatha
2010-04-01  9:31     ` Tony Lindgren
2010-04-01 10:50       ` Varadarajan, Charulatha
2010-04-01  7:17   ` [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific header Felipe Balbi
2010-04-01  8:52     ` Varadarajan, Charulatha
2010-04-01  9:00       ` Felipe Balbi
2010-04-01  9:41       ` Tony Lindgren [this message]
2010-04-01 10:50         ` Varadarajan, Charulatha
2010-04-06 22:31 ` [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS Kevin Hilman
2010-04-12 12:16   ` Varadarajan, Charulatha
2010-04-19 14:31     ` Kevin Hilman

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=20100401094116.GJ31200@atomide.com \
    --to=tony@atomide.com \
    --cc=charu@ti.com \
    --cc=felipe.balbi@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox