Commit Graph

5 Commits

Author SHA1 Message Date
adrian
d143e961c0 Remove these locks - they aren't strictly needed and cause measurable
performance issues.

* Access to the GPIO bus is already locked by requesting
  and releasing the bus - thus the lock isn't really needed
  for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
  the i2c bus code is already doing this by calling the upper
  layer callback to request/release the bus. This thus locks
  the bus for the entirety of the transaction.

TODO:

* Further verify that everything is correctly requesting/
  releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
  potentially by locking/unlocking the bus at the gpiobus
  layer.
2011-12-20 00:33:56 +00:00
adrian
1af383c5f6 Re-jiggle the GPIO code a little to remove the hard-coded AR71xx GPIO
config and function mask setup.

* "gpiomask" now specifies which GPIO pins to enable, for devices to bind to.
* "function_set" allows bits in the function register to be set at GPIO setup.
* "function_clear" allows bits in the function register to be cleared at
  GPIO setup.

The function_set/function_clear bits allow for individual GPIO pins to either
drive a GPIO line or an alternate function - eg USB, JTAG, etc. This allows
for things like CS1/CS2 be enabled for those boards w/ >1 SPI device connected,
or disabling JTAG for the AR7240 (which is apparently needed ..)

I've verified this on the AR71xx.
2011-12-15 01:03:49 +00:00
adrian
94eb8448ed Fix GPIO_MAXPINS calculation for the AR71xx, AR724x, AR913x SoC.
Submitted by:	Luiz Otavio O Souza <loos.br@gmail.com>
2011-05-06 02:45:02 +00:00
gonzo
0dbb1afbee - Fix values of CS1_EN and CS2_EN flags
- Unbreak kernel build by fixing naming convention of
    GPIO_FUNC flags

Spotted by: Luiz Otavio O Souza, Andrew Thompson
2010-09-29 23:06:41 +00:00
gonzo
59f1565a72 Add AR71XX GPIO bus driver. 2010-09-28 03:31:34 +00:00