Date:	Thu, 30 Nov 2006 14:24:49 -0800
From:	David Brownell <david-b@...bell.net>
To:	"pHilipp Zabel" <philipp.zabel@...il.com>
Cc:	"Bill Gatliff" <bgat@...lgatliff.com>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Andrew Victor" <andrew@...people.com>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>, jamey.hicks@...com,
	"Kevin Hilman" <khilman@...sta.com>,
	"Nicolas Pitre" <nico@....org>,
	"Russell King" <rmk@....linux.org.uk>,
	"Tony Lindgren" <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Wednesday 29 November 2006 10:57 pm, pHilipp Zabel wrote:
> >
> > Effectively, yes.  I counted quite a few implementations in the current
> > tree which can trivially (#defines) map to that API.
> 
> I tried to do that for pxa, the patch is attached.

At a quick glance, that looked correct.  However:

> +#define gpio_get_value(gpio)   (GPLR(gpio) & GPIO_bit(gpio))
> +#define gpio_set_value(gpio,value) \
> +       ((value)? (GPSR(gpio) = GPIO_bit(gpio)):(GPCR(gpio) = GPIO_bit(gpio)))

Given how much code those macros expand to, I'd consider making those calls
become inlines which check whether "gpio" is a constant or not.

  if gpio (and value to set?) is a constant
	then use that inline.
  ilse
	procedure call to out-of-line code

That's just in terms of avoiding object code bloat ... a pair of
instructions in-lined for a constant gpio will cost as much space
as the procedure call, but that logic hiding behind the GPLR(),
GPSR(), and GPCR() macros is another thing altogether.


> So what is the state of this discussion, now that 2.6.19 is here?

My understanding is that nobody objected to the GPIO calls, and several
folk see active goodness in having them.  Notably Haavard, wanting to
have a driver that works on both AVR32 and AT91 (different SOC arch,
same controller IP), you (different ARM platforms), Bill Gatliff (for
ISTR some code shared between ARM and PPC platforms), and a few others.

The pushback has been entirely related to pin muxing, and I think it's
accepted now that muxing is platform-specific and orthogonal ... doesn't
need to hold up a common API here.


> I just submitted an input driver for GPIO buttons to linux-input that
> we use in the handhelds.org kernel for sa1100, pxa and s3c2410 archs.
> It needs some ugly
> #ifdefs currently, but with common GPIO calls they all could go away.

Onless there are better suggestions, I think what I'll do is submit
a pair of patches:

 - The documentation, with <asm-arm/gpio.h>
 - OMAP-specific implementation

Then I'll send an FYI to the ARM list (since so many ARMs could use this!)
and ask Andrew to merge that, first to MM then into 2.6.20 before RC1.

Then I'll ask you to submit an updated PXA patch, plus preferably
sa1100 and s3c2410 versions, ditto.  (If you can get other folk to
help, more power to you!)

And Haavard to submit an AVR32 patch, and corresponding AT91 patch
(ISTR he promised both), ditto.

When those patches are in the MM tree I'd see no particular reason
to hold back on the upstream merge.  The folk on the CC list are
involved in maintaining platforms that would be affected, and there
have been no nay-sayers, so I believe nobody is objecting.

Once they're upstream, it's business as usual:  drivers can start
using these calls wherever they make sense, platforms can start to
support them, and so on.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists