Overo GPIO

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

See the kernel docs gpio.txt for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the OMAP35X Technical Reference Manual Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO. For OVERO DM3730 see the Technical Reference Manual Section 13.6.3.2 PADCONFS Register Description.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. See the remuxing example below.

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.
Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this thread on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

root@overo:~# ls /sys/class/gpio
export	gpio164  gpio65       gpiochip160  gpiochip64
gpio15	gpio168  gpiochip0    gpiochip192  gpiochip96
gpio16	gpio176  gpiochip128  gpiochip32   unexport

#define OVERO_GPIO_BT_XGATE     15
#define OVERO_GPIO_W2W_NRESET   16
#define OVERO_GPIO_PENDOWN      114
#define OVERO_GPIO_BT_NRESET    164
#define OVERO_GPIO_USBH_CPEN    168
#define OVERO_GPIO_USBH_NRESET  183
...
#define OVERO_SMSC911X_GPIO    176
#define OVERO_SMSC911X2_GPIO   65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Pin 4 - gpio114	It's the pendown signal on the touchscreen controller but it's available if you aren't using a expansion board with touchscreen support. This pin can not be configured as output, it is input only (see OMAP35X Technical Reference Manual p. 3389). Pulled-low, reads 0 with no input, reads 1 with an input applied
Pin 19 - gpio170	The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module. User exportable Output only - configured this way in the u-boot muxing
Pin 27 - gpio146 Pin 29 - gpio147	User exportable Direction can be changed Floating state
Pin 28 - gpio145 Pin 30 - gpio144	Used with LCD, but available if not using an LCD. Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel. Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing.

LED D2 - gpio21 LED D3 - gpio22	Userspace exportable, set the direction as out echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off
Switch - gpio14 Switch - gpio23	Userspace exportable, leave direction as in With the switch open (not pushed) will register a value of 1 Push the switch and the value will be 0

If you aren't using the first SPI bus, then there are 5 pins on the 40-pin expansion header that you could repurpose for GPIO.

Pin 3 - gpio171(spi1_clk)
Pin 5 - gpio172 (spi1_mosi)
Pin 6 - gpio174 (spi1_cs0)
Pin 7 - gpio173 (spi1_miso)
Pin 8 - gpio175 (spi1_cs1)

The first step is to find the appropriate PADCONF register address for each gpio from Table 7.5 of the TRM. Pay attention to whether it is the low or high order 16 bits for each gpio. You should come up with these values.

gpio171 : 0x4800 21C8
gpio172 : 0x4800 21CA
gpio173 : 0x4800 21CC
gpio174 : 0x4800 21CE
gpio175 : 0x4800 21D0

Using devmem2, here is how you could read the current PADCONF value for what could be gpio171

root@overo# devmem2 0x480021c8 h
...
Value at address 0x480021C8 (0x400201c8): 0x100

Which corresponds to a mux value of (IEN | PTD | DIS | M0) using the U-Boot mux.h definitions. Mux mode 0 for this pin is the spi1_clk configuration found by looking in Table 7.5 of the TRM.

To reconfigure pin 3 to be gpio171, as input or output with inputs pulled low, write 0x010C to the controlling PADCONF register. This would correspond to (IEN | PTD | EN | M4). The bit fields are defined in the TRM Section 7.6.3.

root@overo# devmem2 0x480021c8 h 0x10c

Now you can export and configure gpio171 from userspace like the example with gpio146 at the beginning. To make it visible in sysfs:

echo 172 > /sys/class/gpio/export

If you want this multiplexing to be permanent, then you would modify the U-Boot file board/overo/overo.h and rebuild U-Boot. If you are using OE, then you'll want to generate a patch file to be used in the u-boot-omap3 recipe.

There are additional pins on the header that can be reconfigured this way.

To reconfigure pins from within a kernel module the following code can be used:

void *addr = ioremap(spi1_clk, 4);
if (!addr)
{
 printk("Cannot ioremap 0x%lx\n", spi1_clk);
} else {
 printk("ioremap OK:  0x%lx\n", spi1_clk);
 iowrite32( 0x010C | (0x010C << 16), addr);
 iounmap(addr);
}

This will make both gpio171 and gpio172 input or output with inputs pulled low.

Here is an example on setting up an interrupt on GPIO pin 23 from within a kernel module:

irqreturn_t gpio_irq_handler(int irq, void *dev_id) {
 static int cnt=0;
 printk("gpio_irq_handler %i\n", cnt++);
 return IRQ_HANDLED;
}

int gpio_irq= gpio_to_irq(23);
int ret = request_irq(gpio_irq, gpio_irq_handler, IRQF_TRIGGER_FALLING, "gpio irq handler", gpio_irq_handler);
if (ret)
 printk("gpio interrupt request failed\n");
else
 printk("gpio interrupt request succeeded\n");

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.
GPIO Event Driver allows multiple GPIO lines to be monitored from user-space.
User GPIO Driver is a reflection of the kernel's gpiolib API into user space.

If proc-gpio is a module, add it to /etc/modules or do a modprobe proc-gpio.

A number of files exist under /proc/gpio, one for each GPIO on the PXA processor.

If you cat one of these files, you get, eg:

# cat /proc/gpio/GPIO12
12 GPIO in set

That tells you — GPIO number, function (either GPIO, AF 1, AF 2, or AF 3), in|out, set|clear.

You can change any of those values, by writing to the file, eg:

# echo "AF1 out" > /proc/gpio/GPIO12

This sets GPIO12 to AF1, out mode. (In the case of GPIO12, the PXA defines this function as putting out the 32kHz clock signal.) this is currently case-sensitive

If you have the GPIO set to an output, and GPIO mode, you can set or clear the signal:

# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12

The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.