2011-08-02 17:51:03 +00:00
|
|
|
/*
|
|
|
|
* Alchemy GPIO support.
|
|
|
|
*
|
|
|
|
* With CONFIG_GPIOLIB=y different types of on-chip GPIO can be supported within
|
|
|
|
* the same kernel image.
|
|
|
|
* With CONFIG_GPIOLIB=n, your board must select ALCHEMY_GPIOINT_AU1XXX for the
|
|
|
|
* appropriate CPU type (AU1000 currently).
|
|
|
|
*/
|
|
|
|
|
MIPS: Alchemy: Rewrite GPIO support.
The current in-kernel Alchemy GPIO support is far too inflexible for
all my use cases. To address this, the following changes are made:
* create generic functions which deal with manipulating the on-chip
GPIO1/2 blocks. Such functions are universally useful.
* Macros for GPIO2 shared interrupt management and block control.
* support for both built-in CONFIG_GPIOLIB and fast, inlined GPIO macros.
If CONFIG_GPIOLIB is not enabled, provide linux gpio framework
compatibility by directly inlining the GPIO1/2 functions. GPIO access
is limited to on-chip ones and they can be accessed as documented in
the datasheets (GPIO0-31 and 200-215).
If CONFIG_GPIOLIB is selected, two (2) gpio_chip-s, one for GPIO1 and
one for GPIO2, are registered. GPIOs can still be accessed by using
the numberspace established in the databooks.
However this is not yet flexible enough for my uses: My Alchemy
systems have a documented "external" gpio interface (fixed, different
numberspace) and can support a variety of baseboards, some of which
are equipped with I2C gpio expanders. I want to be able to provide
the default 16 GPIOs of the CPU board numbered as 0..15 and also
support gpio expanders, if present, starting as gpio16.
To achieve this, a new Kconfig symbol for Alchemy is introduced,
CONFIG_ALCHEMY_GPIO_INDIRECT, which boards can enable to signal
that they don't want the Alchemy numberspace exposed to the outside
world, but instead want to provide their own. Boards are now respon-
sible for providing the linux gpio interface glue code (either in a
custom gpio.h header (in board include directory) or with gpio_chips).
To make the board-specific inlined gpio functions work, the MIPS
Makefile must be changed so that the mach-au1x00/gpio.h header is
included _after_ the board headers, by moving the inclusion of
the mach-au1x00/ to the end of the header list.
See arch/mips/include/asm/mach-au1x00/gpio.h for more info.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-06-06 12:09:55 +00:00
|
|
|
#ifndef _ALCHEMY_GPIO_H_
|
|
|
|
#define _ALCHEMY_GPIO_H_
|
2007-05-22 19:44:42 +00:00
|
|
|
|
2011-08-02 17:51:03 +00:00
|
|
|
#include <asm/mach-au1x00/au1000.h>
|
MIPS: Alchemy: Rewrite GPIO support.
The current in-kernel Alchemy GPIO support is far too inflexible for
all my use cases. To address this, the following changes are made:
* create generic functions which deal with manipulating the on-chip
GPIO1/2 blocks. Such functions are universally useful.
* Macros for GPIO2 shared interrupt management and block control.
* support for both built-in CONFIG_GPIOLIB and fast, inlined GPIO macros.
If CONFIG_GPIOLIB is not enabled, provide linux gpio framework
compatibility by directly inlining the GPIO1/2 functions. GPIO access
is limited to on-chip ones and they can be accessed as documented in
the datasheets (GPIO0-31 and 200-215).
If CONFIG_GPIOLIB is selected, two (2) gpio_chip-s, one for GPIO1 and
one for GPIO2, are registered. GPIOs can still be accessed by using
the numberspace established in the databooks.
However this is not yet flexible enough for my uses: My Alchemy
systems have a documented "external" gpio interface (fixed, different
numberspace) and can support a variety of baseboards, some of which
are equipped with I2C gpio expanders. I want to be able to provide
the default 16 GPIOs of the CPU board numbered as 0..15 and also
support gpio expanders, if present, starting as gpio16.
To achieve this, a new Kconfig symbol for Alchemy is introduced,
CONFIG_ALCHEMY_GPIO_INDIRECT, which boards can enable to signal
that they don't want the Alchemy numberspace exposed to the outside
world, but instead want to provide their own. Boards are now respon-
sible for providing the linux gpio interface glue code (either in a
custom gpio.h header (in board include directory) or with gpio_chips).
To make the board-specific inlined gpio functions work, the MIPS
Makefile must be changed so that the mach-au1x00/gpio.h header is
included _after_ the board headers, by moving the inclusion of
the mach-au1x00/ to the end of the header list.
See arch/mips/include/asm/mach-au1x00/gpio.h for more info.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-06-06 12:09:55 +00:00
|
|
|
#include <asm/mach-au1x00/gpio-au1000.h>
|
2011-11-01 19:03:30 +00:00
|
|
|
#include <asm/mach-au1x00/gpio-au1300.h>
|
2007-05-22 19:44:42 +00:00
|
|
|
|
2011-08-02 17:51:03 +00:00
|
|
|
/* On Au1000, Au1500 and Au1100 GPIOs won't work as inputs before
|
|
|
|
* SYS_PININPUTEN is written to at least once. On Au1550/Au1200/Au1300 this
|
|
|
|
* register enables use of GPIOs as wake source.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio1_input_enable(void)
|
|
|
|
{
|
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1000_SYS_PHYS_ADDR);
|
|
|
|
__raw_writel(0, base + 0x110); /* the write op is key */
|
|
|
|
wmb();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Linux gpio framework integration.
|
|
|
|
*
|
|
|
|
* 4 use cases of Alchemy GPIOS:
|
|
|
|
*(1) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=y:
|
|
|
|
* Board must register gpiochips.
|
|
|
|
*(2) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=n:
|
|
|
|
* A gpiochip for the 75 GPIOs is registered.
|
|
|
|
*
|
|
|
|
*(3) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=y:
|
|
|
|
* the boards' gpio.h must provide the linux gpio wrapper functions,
|
|
|
|
*
|
|
|
|
*(4) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=n:
|
|
|
|
* inlinable gpio functions are provided which enable access to the
|
|
|
|
* Au1300 gpios only by using the numbers straight out of the data-
|
|
|
|
* sheets.
|
|
|
|
|
|
|
|
* Cases 1 and 3 are intended for boards which want to provide their own
|
|
|
|
* GPIO namespace and -operations (i.e. for example you have 8 GPIOs
|
|
|
|
* which are in part provided by spare Au1300 GPIO pins and in part by
|
|
|
|
* an external FPGA but you still want them to be accssible in linux
|
|
|
|
* as gpio0-7. The board can of course use the alchemy_gpioX_* functions
|
|
|
|
* as required).
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef CONFIG_GPIOLIB
|
|
|
|
|
|
|
|
/* wraps the cpu-dependent irq_to_gpio functions */
|
|
|
|
/* FIXME: gpiolib needs an irq_to_gpio hook */
|
|
|
|
static inline int __au_irq_to_gpio(unsigned int irq)
|
|
|
|
{
|
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1000...ALCHEMY_CPU_AU1200:
|
|
|
|
return alchemy_irq_to_gpio(irq);
|
2011-11-01 19:03:30 +00:00
|
|
|
case ALCHEMY_CPU_AU1300:
|
|
|
|
return au1300_irq_to_gpio(irq);
|
2011-08-02 17:51:03 +00:00
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* using gpiolib to provide up to 2 gpio_chips for on-chip gpios */
|
|
|
|
#ifndef CONFIG_ALCHEMY_GPIO_INDIRECT /* case (2) */
|
|
|
|
|
|
|
|
/* get everything through gpiolib */
|
|
|
|
#define gpio_to_irq __gpio_to_irq
|
|
|
|
#define gpio_get_value __gpio_get_value
|
|
|
|
#define gpio_set_value __gpio_set_value
|
|
|
|
#define gpio_cansleep __gpio_cansleep
|
|
|
|
#define irq_to_gpio __au_irq_to_gpio
|
|
|
|
|
|
|
|
#include <asm-generic/gpio.h>
|
|
|
|
|
|
|
|
#endif /* !CONFIG_ALCHEMY_GPIO_INDIRECT */
|
|
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_GPIOLIB */
|
2007-05-22 19:44:42 +00:00
|
|
|
|
MIPS: Alchemy: Rewrite GPIO support.
The current in-kernel Alchemy GPIO support is far too inflexible for
all my use cases. To address this, the following changes are made:
* create generic functions which deal with manipulating the on-chip
GPIO1/2 blocks. Such functions are universally useful.
* Macros for GPIO2 shared interrupt management and block control.
* support for both built-in CONFIG_GPIOLIB and fast, inlined GPIO macros.
If CONFIG_GPIOLIB is not enabled, provide linux gpio framework
compatibility by directly inlining the GPIO1/2 functions. GPIO access
is limited to on-chip ones and they can be accessed as documented in
the datasheets (GPIO0-31 and 200-215).
If CONFIG_GPIOLIB is selected, two (2) gpio_chip-s, one for GPIO1 and
one for GPIO2, are registered. GPIOs can still be accessed by using
the numberspace established in the databooks.
However this is not yet flexible enough for my uses: My Alchemy
systems have a documented "external" gpio interface (fixed, different
numberspace) and can support a variety of baseboards, some of which
are equipped with I2C gpio expanders. I want to be able to provide
the default 16 GPIOs of the CPU board numbered as 0..15 and also
support gpio expanders, if present, starting as gpio16.
To achieve this, a new Kconfig symbol for Alchemy is introduced,
CONFIG_ALCHEMY_GPIO_INDIRECT, which boards can enable to signal
that they don't want the Alchemy numberspace exposed to the outside
world, but instead want to provide their own. Boards are now respon-
sible for providing the linux gpio interface glue code (either in a
custom gpio.h header (in board include directory) or with gpio_chips).
To make the board-specific inlined gpio functions work, the MIPS
Makefile must be changed so that the mach-au1x00/gpio.h header is
included _after_ the board headers, by moving the inclusion of
the mach-au1x00/ to the end of the header list.
See arch/mips/include/asm/mach-au1x00/gpio.h for more info.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-06-06 12:09:55 +00:00
|
|
|
#endif /* _ALCHEMY_GPIO_H_ */
|