summaryrefslogtreecommitdiffstats
path: root/arch/avr32/mach-at32ap/pio.c
Commit message (Collapse)AuthorAgeFilesLines
* avr32: Allow reserving multiple pins at onceAlex Raimondi2009-01-051-6/+13
| | | | | | | | | | | at32_reserve_pin now takes an u32 bitmask rather than a single pin. This allows to reserve multiple pins at once. Remove (undocumented) SDCS (pin PE26) from reservation in board setup code. Signed-off-by: Alex Raimondi <raimondi@miromico.ch> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* avr32: Allow selecting multiple pins at onceJulien May2008-10-121-14/+27
| | | | | | | | at32_select_periph() now takes an u32 bitmask rather than a single pin. This allows to set multiple pins at once. Signed-off-by: Alex Raimondi <mailinglist@miromico.ch> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* avr32: Use platform_driver_probe for pio platform driverUwe Kleine-König2008-09-221-2/+1
| | | | | | | | | | | The probe function of the pio platform driver lives in the init section and so a pio device that is created after the init section is discarded probably results in an oops. Even if this cannot happen, using platform_driver_probe is cleaner. (If this can happen and should be supported the probe function must live in the devinit section instead.) Signed-off-by: Uwe Kleine-König <ukleinek@strlen.de> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* avr32: Provide a way to deselect pins in the portmuxHaavard Skinnemoen2008-09-221-0/+19
| | | | | | | | | | | | Currently, setting up the portmux is completely one-shot: Once a pin is muxed, the portmux driver will complain loudly and refuse to do anything if you try to set up the same pin again. Sometimes, it may be necessary to change the configuration of a pin after it has been set up initially. This patch adds a way to undo the previous configuration, allowing the pin to be reconfigured. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* avr32: Use <mach/foo.h> instead of <asm/arch/foo.h>Haavard Skinnemoen2008-08-051-1/+1
| | | | | | | Update all avr32-specific files to use the new platform-specific header locations. Drivers shared with ARM are left alone for now. Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* gpio: sysfs interfaceDavid Brownell2008-07-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a simple sysfs interface for GPIOs. /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace /unexport ... to return a GPIO to the kernel /gpioN ... for each exported GPIO #N /value ... always readable, writes fail for input GPIOs /direction ... r/w as: in, out (default low); write high, low /gpiochipN ... for each gpiochip; #N is its first GPIO /base ... (r/o) same as N /label ... (r/o) descriptive, not necessarily unique /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1) GPIOs claimed by kernel code may be exported by its owner using a new gpio_export() call, which should be most useful for driver debugging. Such exports may optionally be done without a "direction" attribute. Userspace may ask to take over a GPIO by writing to a sysfs control file, helping to cope with incomplete board support or other "one-off" requirements that don't merit full kernel support: echo 23 > /sys/class/gpio/export ... will gpio_request(23, "sysfs") and gpio_export(23); use /sys/class/gpio/gpio-23/direction to (re)configure it, when that GPIO can be used as both input and output. echo 23 > /sys/class/gpio/unexport ... will gpio_free(23), when it was exported as above The extra D-space footprint is a few hundred bytes, except for the sysfs resources associated with each exported GPIO. The additional I-space footprint is about two thirds of the current size of gpiolib (!). Since no /dev node creation is involved, no "udev" support is needed. Related changes: * This adds a device pointer to "struct gpio_chip". When GPIO providers initialize that, sysfs gpio class devices become children of that device instead of being "virtual" devices. * The (few) gpio_chip providers which have such a device node have been updated. * Some gpio_chip drivers also needed to update their module "owner" field ... for which missing kerneldoc was added. * Some gpio_chips don't support input GPIOs. Those GPIOs are now flagged appropriately when the chip is registered. Based on previous patches, and discussion both on and off LKML. A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this merges to mainline. [akpm@linux-foundation.org: a few maintenance build fixes] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* avr32: minor GPIO handling updatesDavid Brownell2008-06-271-0/+2
| | | | | | | | | On the odd chance some code uses a pin as a GPIO IRQ without calling gpio_request() or gpio_direction_input(), the debug dump should still show its pin status. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* gpiolib: avr32 at32ap platform supportDavid Brownell2008-02-051-80/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that signals on external chips (like GPIO expanders) can easily be used. This mostly reorganizes some existing logic, with two minor changes in behavior: - The PSR registers are used instead of the previous "gpio_mask" values, matching AT91 behavior and removing some duplication between that role and that of "pinmux_mask". - NR_IRQs grew to acommodate a bank of external GPIOs. Eventually this number should probably become a board-specific config option. There's a debugfs dump of status for the built-in GPIOs, showing which pins have deglitching, pullups, or open drain drive enabled, as well as the ID string used when requesting each IRQ. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Jean Delvare <khali@linux-fr.org> Cc: Eric Miao <eric.miao@marvell.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ben Gardner <bgardner@wabtec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [AVR32] add multidrive support for pio driverMatteo Vit2007-10-111-0/+4
| | | | | | | This patch add multidrive support for pio driver Signed-off-by: Matteo Vit - Dave S.r.l. <matteo.vit@dave.eu> Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
* [PATCH] gpio_direction_output() needs an initial valueDavid Brownell2007-03-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | It's been pointed out that output GPIOs should have an initial value, to avoid signal glitching ... among other things, it can be some time before a driver is ready. This patch corrects that oversight, fixing - documentation - platforms supporting the GPIO interface - users of that call (just one for now, others are pending) There's only one user of this call for now since most platforms are still using non-generic GPIO setup code, which in most cases already couples the initial value with its "set output mode" request. Note that most platforms are clear about the hardware letting the output value be set before the pin direction is changed, but the s3c241x docs are vague on that topic ... so those chips might not avoid the glitches. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Andrew Victor <andrew@sanpeople.com> Acked-by: Milan Svoboda <msvoboda@ra.rockwell.com> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [AVR32] Introduce at32_reserve_pin()Haavard Skinnemoen2007-02-091-1/+22
| | | | | | | | at32_reserve_pin() can be used for reserving portmux pins without altering their configuration. Useful for e.g. SDRAM pins where we really don't want to change the bootloader-provided configuration. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
* [AVR32] Don't reset PIO state at bootupHaavard Skinnemoen2007-02-091-3/+0
| | | | | | | Leave the PIO lines as the bootloader left them. This allows us to use PIOE without disturbing the SDRAM muxing. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
* [AVR32] GPIO API implementationHaavard Skinnemoen2007-02-091-14/+219
| | | | | | | Arch-neutral GPIO calls for AVR32. GPIO IRQ support written by David Brownell. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
* [AVR32] Portmux API updateHaavard Skinnemoen2006-12-081-7/+78
| | | | | | | Rename portmux_set_func to at32_select_periph, add at32_select_gpio and add flags parameter to specify the initial state of the pins. Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
* [PATCH] avr32 architectureHaavard Skinnemoen2006-09-261-0/+118
This adds support for the Atmel AVR32 architecture as well as the AT32AP7000 CPU and the AT32STK1000 development board. AVR32 is a new high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular emphasis on low power consumption and high code density. The AVR32 architecture is not binary compatible with earlier 8-bit AVR architectures. The AVR32 architecture, including the instruction set, is described by the AVR32 Architecture Manual, available from http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf The Atmel AT32AP7000 is the first CPU implementing the AVR32 architecture. It features a 7-stage pipeline, 16KB instruction and data caches and a full Memory Management Unit. It also comes with a large set of integrated peripherals, many of which are shared with the AT91 ARM-based controllers from Atmel. Full data sheet is available from http://www.atmel.com/dyn/resources/prod_documents/doc32003.pdf while the CPU core implementation including caches and MMU is documented by the AVR32 AP Technical Reference, available from http://www.atmel.com/dyn/resources/prod_documents/doc32001.pdf Information about the AT32STK1000 development board can be found at http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918 including a BSP CD image with an earlier version of this patch, development tools (binaries and source/patches) and a root filesystem image suitable for booting from SD card. Alternatively, there's a preliminary "getting started" guide available at http://avr32linux.org/twiki/bin/view/Main/GettingStarted which provides links to the sources and patches you will need in order to set up a cross-compiling environment for avr32-linux. This patch, as well as the other patches included with the BSP and the toolchain patches, is actively supported by Atmel Corporation. [dmccr@us.ibm.com: Fix more pxx_page macro locations] [bunk@stusta.de: fix `make defconfig'] Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave McCracken <dmccr@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
OpenPOWER on IntegriCloud