All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Andrew Victor <andrew@sanpeople.com>,
	Bill Gatliff <bgat@billgatliff.com>,
	jamey.hicks@hp.com, Kevin Hilman <khilman@mvista.com>,
	Nicolas Pitre <nico@cam.org>, Russell King <rmk@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation [take 2]
Date: Thu, 30 Nov 2006 11:05:00 -0800	[thread overview]
Message-ID: <200611301105.01108.david-b@pacbell.net> (raw)
In-Reply-To: <20061128133618.0e6932fc@dhcp-252-105.norway.atmel.com>

On Tuesday 28 November 2006 4:36 am, Haavard Skinnemoen wrote:
> Here's another go at an implementation of the arch-neutral GPIO API for
> AVR32. I've also thrown in the pin configuration stuff so that you can
> see how all the pieces fit together.

That looks good, but it was probably better in a "portmux.h" header.
(Although the at32_* prefixes help a lot!)  You don't use the flags
AT32_GPIO_PULLUP etc, either.

Other than that pinmux confusion, this looks pretty much OK to me.
The GPIO stuff matches the proposal.


> Even though it is possible to tell from the hardware whether a pin is
> set up for GPIO, I decided to use two allocation bitmasks per pio
> controller to keep track of what the pins are used for: pinmux_mask and
> gpio_mask.
> 
> pinmux_mask indicates which pins have been configured for usage either
> by a peripheral or GPIO. If the corresponding bit is set when trying to
> configure a pin, a warning will be printed along with a stack dump (no
> BUG anymore.)

That is, pins without that set are still configured how the bootloader
left them ... possibly as they were left by system reset.  On some systems
it might be desirable to warn when the mode Linux wants isn't what the
bootloader left, so that all the muxing code can be left out of Linux.
(Not that it can save much on AT91 or AVR32, but the bootloader was probably
writing those registers anyway, and saving codespace and boot time tends
to be a Good Thing.)  Or so that Linux can't, oh, change the state of
the GPIO that keeps the saw switched off.  ;)

I notice you didn't have a way to return pins to an "unclaimed" state
though, which would probably be disadvantageous in some cases.  I don't
agree with the arguments made by Paul Mundt that such usage would be a
common thing ... but on the other hand, I bet you'd get complaints from
various folk if you make re-muxing excessively painful.


> gpio_mask indicates which pins are available for GPIO. It starts out as
> all ones, and whenever a pin is configured for GPIO, the corresponding
> bit is cleared. gpio_request() test_and_set()s a bit in the mask
> corresponding to the pin being requested, and if it's already set
> (either because it hasn't been configured or because it's been
> requested by a different driver), gpio_request() returns an error value.

Sounds OK.  You are thus _requiring_ the pin muxing to have been
done before the gpio pin is requested ... sort of complicates the
"Linux uses bootloader's pin muxing" model.


> The pin configuration API is AVR32-specific for now.
> 
> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
> ---
>  arch/avr32/mach-at32ap/at32ap7000.c        |  144 ++++++++++-----------
>  arch/avr32/mach-at32ap/pio.c               |  186 ++++++++++++++++++++++++++--
>  include/asm-avr32/arch-at32ap/at32ap7000.h |   26 ++++
>  include/asm-avr32/arch-at32ap/gpio.h       |   39 ++++++
>  include/asm-avr32/arch-at32ap/irq.h        |   11 ++
>  include/asm-avr32/arch-at32ap/portmux.h    |   16 ---
>  include/asm-avr32/gpio.h                   |    6 +
>  include/asm-avr32/irq.h                    |    8 +-
>  8 files changed, 333 insertions(+), 103 deletions(-)
> 

> @@ -569,26 +561,26 @@ DEV_CLK(usart, atmel_usart3, pba, 6);
>  
>  static inline void configure_usart0_pins(void)
>  {
> -	portmux_set_func(PIOA,  8, FUNC_B);	/* RXD	*/
> -	portmux_set_func(PIOA,  9, FUNC_B);	/* TXD	*/
> +	select_peripheral(PA(8), PERIPH_B, 0);	/* RXD	*/
> +	select_peripheral(PA(9), PERIPH_B, 0);	/* TXD	*/

A constant like PULLUP_OFF would be clearer in these cases.


> +void __init at32_select_periph(unsigned int pin, unsigned int periph,
> +			       int use_pullup)

Declared as "flags" elsewhere, not "use_pullup"...


> +void __init at32_select_gpio(unsigned int pin, int enable_output,
> +			     int use_pullup)


> +/*
> + * Set up pin multiplexing, called from board init only.
> + *
> + * The following flags determine the initial state of the pin.
> + */
> +#define AT32_GPIOF_PULLUP	0x00000001	/* Enable pull-up */
> +#define AT32_GPIOF_OUTPUT	0x00000002	/* Enable output driver */
> +#define AT32_GPIOF_HIGH		0x00000004	/* Set output high */
> +
> +void at32_select_periph(unsigned int pin, unsigned int periph,
> +			unsigned long flags);
> +void at32_select_gpio(unsigned int pin, unsigned long flags);

  reply	other threads:[~2006-11-30 19:14 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-11 23:41 [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls David Brownell
2006-11-12  1:27 ` H. Peter Anvin
2006-11-12  3:04   ` David Brownell
2006-11-12  3:15     ` H. Peter Anvin
2006-11-13  3:30 ` Bill Gatliff
2006-11-13 17:38 ` Paul Mundt
2006-11-13 17:56   ` Thiago Galesi
2006-11-13 19:25     ` David Brownell
2006-11-13 19:50       ` Bill Gatliff
2006-11-13 18:19   ` Bill Gatliff
2006-11-13 18:38     ` Paul Mundt
2006-11-13 19:29       ` Bill Gatliff
2006-11-13 20:15         ` Paul Mundt
2006-11-20 21:49           ` David Brownell
2006-11-21  3:44             ` Bill Gatliff
2006-11-21  4:45               ` David Brownell
2006-11-21  5:09                 ` Bill Gatliff
2006-11-21  5:35                   ` David Brownell
2006-11-21  6:09                     ` Paul Mundt
2006-11-21 18:13                       ` David Brownell
2006-11-22  3:36                         ` Bill Gatliff
2006-11-22  3:55                           ` Paul Mundt
2006-11-22  4:45                           ` [Bulk] " David Brownell
2006-11-22  4:47                             ` Bill Gatliff
2006-11-21 15:57                     ` Bill Gatliff
2006-11-23  0:40                       ` David Brownell
2006-11-30  6:57                         ` pHilipp Zabel
2006-11-30  7:29                           ` pHilipp Zabel
2006-11-30 22:24                           ` David Brownell
2006-11-20 22:15           ` David Brownell
2006-11-21  2:56             ` Bill Gatliff
2006-11-13 20:00       ` David Brownell
2006-11-13 21:30         ` Paul Mundt
2006-11-14  3:21           ` David Brownell
2006-11-13 19:21   ` David Brownell
2006-11-13 19:43     ` Bill Gatliff
2006-11-13 20:15       ` David Brownell
2006-11-13 20:26         ` Bill Gatliff
2006-11-13 20:53           ` David Brownell
2006-11-13 20:58             ` Bill Gatliff
2006-11-13 20:29         ` Bill Gatliff
2006-11-16 14:54 ` [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation Haavard Skinnemoen
2006-11-20 21:47   ` David Brownell
2006-11-21  3:11     ` Bill Gatliff
2006-11-21  5:06       ` David Brownell
2006-11-21  5:51         ` Bill Gatliff
2006-11-21 18:19           ` David Brownell
2006-11-21  9:11     ` Haavard Skinnemoen
2006-11-21 19:03       ` David Brownell
2006-11-28 12:36         ` [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation [take 2] Haavard Skinnemoen
2006-11-30 19:05           ` David Brownell [this message]
2006-12-01  9:51             ` Haavard Skinnemoen
2006-12-20 21:04 ` [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls David Brownell
2006-12-20 21:08   ` [patch 2.6.20-rc1 1/6] GPIO core David Brownell
2006-12-27 17:49     ` Pavel Machek
2006-12-28 22:05       ` David Brownell
2006-12-29  0:27         ` Pavel Machek
2006-12-30  1:18           ` David Brownell
2007-01-01 20:55             ` Pavel Machek
2007-01-01 21:27               ` David Brownell
2007-01-02 14:18                 ` Pavel Machek
2006-12-20 21:09   ` [patch 2.6.20-rc1 2/6] OMAP GPIO wrappers David Brownell
2006-12-20 21:11   ` [patch 2.6.20-rc1 3/6] AT91 " David Brownell
2006-12-21  6:10     ` Andrew Morton
2006-12-21  6:45       ` David Brownell
2006-12-20 21:12   ` [patch 2.6.20-rc1 4/6] PXA " David Brownell
2006-12-21  6:12     ` Andrew Morton
2006-12-21  6:44       ` David Brownell
2006-12-21 14:27         ` Nicolas Pitre
2006-12-21 15:03           ` pHilipp Zabel
2006-12-21 17:25             ` Nicolas Pitre
2006-12-21 19:32               ` pHilipp Zabel
2006-12-21 20:10                 ` Nicolas Pitre
2006-12-21 20:32                   ` Bill Gatliff
2006-12-22  6:53                   ` pHilipp Zabel
2006-12-28 20:47                     ` David Brownell
2006-12-30  2:15                       ` Nicolas Pitre
2006-12-30  2:38                         ` David Brownell
2007-01-01 19:43                         ` David Brownell
2006-12-30  1:13                     ` David Brownell
2006-12-21 19:25             ` David Brownell
2006-12-27 17:53     ` Pavel Machek
2006-12-28 20:48       ` David Brownell
2006-12-28 20:50         ` Pavel Machek
2006-12-28 20:53           ` Pavel Machek
2006-12-20 21:13   ` [patch 2.6.20-rc1 5/6] SA1100 " David Brownell
2006-12-21  6:13     ` Andrew Morton
2006-12-22  7:16       ` pHilipp Zabel
2006-12-22 15:05         ` Nicolas Pitre
2006-12-30  2:21         ` David Brownell
2006-12-30  3:15           ` Nicolas Pitre
2006-12-30  6:01             ` David Brownell
2006-12-30 13:59               ` pHilipp Zabel
2006-12-30 15:08                 ` Russell King
2006-12-23 11:37     ` Russell King
2006-12-23 20:39       ` David Brownell
2006-12-27 18:24     ` Pavel Machek
2006-12-20 21:14   ` [patch 2.6.20-rc1 6/6] S3C2410 " David Brownell
2006-12-21 10:33     ` Arnaud Patard
2006-12-21 15:29       ` pHilipp Zabel
2006-12-23 11:40       ` Russell King
2006-12-20 23:30   ` [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls Håvard Skinnemoen
2006-12-20 23:46     ` David Brownell

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=200611301105.01108.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@osdl.org \
    --cc=andrew@sanpeople.com \
    --cc=bgat@billgatliff.com \
    --cc=hskinnemoen@atmel.com \
    --cc=jamey.hicks@hp.com \
    --cc=khilman@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@cam.org \
    --cc=rmk@arm.linux.org.uk \
    --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.