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 20:09:55 +08:00
|
|
|
/*
|
|
|
|
* GPIO functions for Au1000, Au1500, Au1100, Au1550, Au1200
|
|
|
|
*
|
|
|
|
* Copyright (c) 2009 Manuel Lauss.
|
|
|
|
*
|
|
|
|
* Licensed under the terms outlined in the file COPYING.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _ALCHEMY_GPIO_AU1000_H_
|
|
|
|
#define _ALCHEMY_GPIO_AU1000_H_
|
|
|
|
|
|
|
|
#include <asm/mach-au1x00/au1000.h>
|
|
|
|
|
|
|
|
/* The default GPIO numberspace as documented in the Alchemy manuals.
|
|
|
|
* GPIO0-31 from GPIO1 block, GPIO200-215 from GPIO2 block.
|
|
|
|
*/
|
|
|
|
#define ALCHEMY_GPIO1_BASE 0
|
|
|
|
#define ALCHEMY_GPIO2_BASE 200
|
|
|
|
|
|
|
|
#define ALCHEMY_GPIO1_NUM 32
|
|
|
|
#define ALCHEMY_GPIO2_NUM 16
|
|
|
|
#define ALCHEMY_GPIO1_MAX (ALCHEMY_GPIO1_BASE + ALCHEMY_GPIO1_NUM - 1)
|
|
|
|
#define ALCHEMY_GPIO2_MAX (ALCHEMY_GPIO2_BASE + ALCHEMY_GPIO2_NUM - 1)
|
|
|
|
|
|
|
|
#define MAKE_IRQ(intc, off) (AU1000_INTC##intc##_INT_BASE + (off))
|
|
|
|
|
2011-05-08 16:42:13 +08:00
|
|
|
struct gpio;
|
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 20:09:55 +08:00
|
|
|
|
|
|
|
static inline int au1000_gpio1_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return MAKE_IRQ(1, gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1000_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1000_irq_to_gpio(int irq)
|
|
|
|
{
|
2009-10-08 02:15:15 +08:00
|
|
|
if ((irq >= AU1000_GPIO0_INT) && (irq <= AU1000_GPIO31_INT))
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1000_GPIO0_INT) + 0;
|
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 20:09:55 +08:00
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1500_gpio1_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO1_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0 ... 15:
|
|
|
|
case 20:
|
|
|
|
case 23 ... 28: return MAKE_IRQ(1, gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1500_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0 ... 3: return MAKE_IRQ(1, 16 + gpio - 0);
|
|
|
|
case 4 ... 5: return MAKE_IRQ(1, 21 + gpio - 4);
|
|
|
|
case 6 ... 7: return MAKE_IRQ(1, 29 + gpio - 6);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1500_irq_to_gpio(int irq)
|
|
|
|
{
|
|
|
|
switch (irq) {
|
2009-10-08 02:15:15 +08:00
|
|
|
case AU1500_GPIO0_INT ... AU1500_GPIO15_INT:
|
|
|
|
case AU1500_GPIO20_INT:
|
|
|
|
case AU1500_GPIO23_INT ... AU1500_GPIO28_INT:
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1500_GPIO0_INT) + 0;
|
|
|
|
case AU1500_GPIO200_INT ... AU1500_GPIO203_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1500_GPIO200_INT) + 0;
|
|
|
|
case AU1500_GPIO204_INT ... AU1500_GPIO205_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1500_GPIO204_INT) + 4;
|
|
|
|
case AU1500_GPIO206_INT ... AU1500_GPIO207_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1500_GPIO206_INT) + 6;
|
|
|
|
case AU1500_GPIO208_215_INT:
|
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 20:09:55 +08:00
|
|
|
return ALCHEMY_GPIO2_BASE + 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1100_gpio1_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return MAKE_IRQ(1, gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1100_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
if ((gpio >= 8) && (gpio <= 15))
|
|
|
|
return MAKE_IRQ(0, 29); /* shared GPIO208_215 */
|
2009-08-17 06:28:24 +08:00
|
|
|
|
|
|
|
return -ENXIO;
|
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 20:09:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1100_irq_to_gpio(int irq)
|
|
|
|
{
|
|
|
|
switch (irq) {
|
2009-10-08 02:15:15 +08:00
|
|
|
case AU1100_GPIO0_INT ... AU1100_GPIO31_INT:
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1100_GPIO0_INT) + 0;
|
|
|
|
case AU1100_GPIO208_215_INT:
|
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 20:09:55 +08:00
|
|
|
return ALCHEMY_GPIO2_BASE + 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1550_gpio1_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO1_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0 ... 15:
|
|
|
|
case 20 ... 28: return MAKE_IRQ(1, gpio);
|
|
|
|
case 16 ... 17: return MAKE_IRQ(1, 18 + gpio - 16);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1550_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0: return MAKE_IRQ(1, 16);
|
|
|
|
case 1 ... 5: return MAKE_IRQ(1, 17); /* shared GPIO201_205 */
|
|
|
|
case 6 ... 7: return MAKE_IRQ(1, 29 + gpio - 6);
|
|
|
|
case 8 ... 15: return MAKE_IRQ(1, 31); /* shared GPIO208_215 */
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1550_irq_to_gpio(int irq)
|
|
|
|
{
|
|
|
|
switch (irq) {
|
2009-10-08 02:15:15 +08:00
|
|
|
case AU1550_GPIO0_INT ... AU1550_GPIO15_INT:
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1550_GPIO0_INT) + 0;
|
|
|
|
case AU1550_GPIO200_INT:
|
|
|
|
case AU1550_GPIO201_205_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1550_GPIO200_INT) + 0;
|
|
|
|
case AU1550_GPIO16_INT ... AU1550_GPIO28_INT:
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1550_GPIO16_INT) + 16;
|
|
|
|
case AU1550_GPIO206_INT ... AU1550_GPIO208_215_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1550_GPIO206_INT) + 6;
|
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 20:09:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1200_gpio1_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return MAKE_IRQ(1, gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1200_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0 ... 2: return MAKE_IRQ(0, 5 + gpio - 0);
|
|
|
|
case 3: return MAKE_IRQ(0, 22);
|
|
|
|
case 4 ... 7: return MAKE_IRQ(0, 24 + gpio - 4);
|
|
|
|
case 8 ... 15: return MAKE_IRQ(0, 28); /* shared GPIO208_215 */
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int au1200_irq_to_gpio(int irq)
|
|
|
|
{
|
|
|
|
switch (irq) {
|
2009-10-08 02:15:15 +08:00
|
|
|
case AU1200_GPIO0_INT ... AU1200_GPIO31_INT:
|
|
|
|
return ALCHEMY_GPIO1_BASE + (irq - AU1200_GPIO0_INT) + 0;
|
|
|
|
case AU1200_GPIO200_INT ... AU1200_GPIO202_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1200_GPIO200_INT) + 0;
|
|
|
|
case AU1200_GPIO203_INT:
|
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 20:09:55 +08:00
|
|
|
return ALCHEMY_GPIO2_BASE + 3;
|
2009-10-08 02:15:15 +08:00
|
|
|
case AU1200_GPIO204_INT ... AU1200_GPIO208_215_INT:
|
|
|
|
return ALCHEMY_GPIO2_BASE + (irq - AU1200_GPIO204_INT) + 4;
|
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 20:09:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GPIO1 block macros for common linux gpio functions.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio1_set_value(int gpio, int v)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
unsigned long r = v ? SYS_OUTPUTSET : SYS_OUTPUTCLR;
|
|
|
|
au_writel(mask, r);
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio1_get_value(int gpio)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
return au_readl(SYS_PINSTATERD) & mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio1_direction_input(int gpio)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO1_BASE);
|
|
|
|
au_writel(mask, SYS_TRIOUTCLR);
|
|
|
|
au_sync();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio1_direction_output(int gpio, int v)
|
|
|
|
{
|
|
|
|
/* hardware switches to "output" mode when one of the two
|
|
|
|
* "set_value" registers is accessed.
|
|
|
|
*/
|
|
|
|
alchemy_gpio1_set_value(gpio, v);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio1_is_valid(int gpio)
|
|
|
|
{
|
|
|
|
return ((gpio >= ALCHEMY_GPIO1_BASE) && (gpio <= ALCHEMY_GPIO1_MAX));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio1_to_irq(int gpio)
|
|
|
|
{
|
2009-11-24 03:40:00 +08:00
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1000:
|
|
|
|
return au1000_gpio1_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1100:
|
|
|
|
return au1100_gpio1_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1500:
|
|
|
|
return au1500_gpio1_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1550:
|
|
|
|
return au1550_gpio1_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1200:
|
|
|
|
return au1200_gpio1_to_irq(gpio);
|
|
|
|
}
|
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 20:09:55 +08:00
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GPIO2 block macros for common linux GPIO functions. The 'gpio'
|
|
|
|
* parameter must be in range of ALCHEMY_GPIO2_BASE..ALCHEMY_GPIO2_MAX.
|
|
|
|
*/
|
|
|
|
static inline void __alchemy_gpio2_mod_dir(int gpio, int to_out)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO2_BASE);
|
|
|
|
unsigned long d = au_readl(GPIO2_DIR);
|
|
|
|
if (to_out)
|
|
|
|
d |= mask;
|
|
|
|
else
|
|
|
|
d &= ~mask;
|
|
|
|
au_writel(d, GPIO2_DIR);
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void alchemy_gpio2_set_value(int gpio, int v)
|
|
|
|
{
|
|
|
|
unsigned long mask;
|
|
|
|
mask = ((v) ? 0x00010001 : 0x00010000) << (gpio - ALCHEMY_GPIO2_BASE);
|
|
|
|
au_writel(mask, GPIO2_OUTPUT);
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio2_get_value(int gpio)
|
|
|
|
{
|
|
|
|
return au_readl(GPIO2_PINSTATE) & (1 << (gpio - ALCHEMY_GPIO2_BASE));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio2_direction_input(int gpio)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
local_irq_save(flags);
|
|
|
|
__alchemy_gpio2_mod_dir(gpio, 0);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio2_direction_output(int gpio, int v)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
alchemy_gpio2_set_value(gpio, v);
|
|
|
|
local_irq_save(flags);
|
|
|
|
__alchemy_gpio2_mod_dir(gpio, 1);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio2_is_valid(int gpio)
|
|
|
|
{
|
|
|
|
return ((gpio >= ALCHEMY_GPIO2_BASE) && (gpio <= ALCHEMY_GPIO2_MAX));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio2_to_irq(int gpio)
|
|
|
|
{
|
2009-11-24 03:40:00 +08:00
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1000:
|
|
|
|
return au1000_gpio2_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1100:
|
|
|
|
return au1100_gpio2_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1500:
|
|
|
|
return au1500_gpio2_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1550:
|
|
|
|
return au1550_gpio2_to_irq(gpio);
|
|
|
|
case ALCHEMY_CPU_AU1200:
|
|
|
|
return au1200_gpio2_to_irq(gpio);
|
|
|
|
}
|
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 20:09:55 +08:00
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************/
|
|
|
|
|
|
|
|
/* On Au1000, Au1500 and Au1100 GPIOs won't work as inputs before
|
|
|
|
* SYS_PININPUTEN is written to at least once. On Au1550/Au1200 this
|
|
|
|
* register enables use of GPIOs as wake source.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio1_input_enable(void)
|
|
|
|
{
|
|
|
|
au_writel(0, SYS_PININPUTEN); /* the write op is key */
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* GPIO2 shared interrupts and control */
|
|
|
|
|
|
|
|
static inline void __alchemy_gpio2_mod_int(int gpio2, int en)
|
|
|
|
{
|
|
|
|
unsigned long r = au_readl(GPIO2_INTENABLE);
|
|
|
|
if (en)
|
|
|
|
r |= 1 << gpio2;
|
|
|
|
else
|
|
|
|
r &= ~(1 << gpio2);
|
|
|
|
au_writel(r, GPIO2_INTENABLE);
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* alchemy_gpio2_enable_int - Enable a GPIO2 pins' shared irq contribution.
|
|
|
|
* @gpio2: The GPIO2 pin to activate (200...215).
|
|
|
|
*
|
|
|
|
* GPIO208-215 have one shared interrupt line to the INTC. They are
|
|
|
|
* and'ed with a per-pin enable bit and finally or'ed together to form
|
|
|
|
* a single irq request (useful for active-high sources).
|
|
|
|
* With this function, a pins' individual contribution to the int request
|
|
|
|
* can be enabled. As with all other GPIO-based interrupts, the INTC
|
|
|
|
* must be programmed to accept the GPIO208_215 interrupt as well.
|
|
|
|
*
|
|
|
|
* NOTE: Calling this macro is only necessary for GPIO208-215; all other
|
|
|
|
* GPIO2-based interrupts have their own request to the INTC. Please
|
|
|
|
* consult your Alchemy databook for more information!
|
|
|
|
*
|
|
|
|
* NOTE: On the Au1550, GPIOs 201-205 also have a shared interrupt request
|
|
|
|
* line to the INTC, GPIO201_205. This function can be used for those
|
|
|
|
* as well.
|
|
|
|
*
|
|
|
|
* NOTE: 'gpio2' parameter must be in range of the GPIO2 numberspace
|
|
|
|
* (200-215 by default). No sanity checks are made,
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_enable_int(int gpio2)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
gpio2 -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
/* Au1100/Au1500 have GPIO208-215 enable bits at 0..7 */
|
2009-11-24 03:40:00 +08:00
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1100:
|
|
|
|
case ALCHEMY_CPU_AU1500:
|
|
|
|
gpio2 -= 8;
|
|
|
|
}
|
|
|
|
|
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 20:09:55 +08:00
|
|
|
local_irq_save(flags);
|
|
|
|
__alchemy_gpio2_mod_int(gpio2, 1);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* alchemy_gpio2_disable_int - Disable a GPIO2 pins' shared irq contribution.
|
|
|
|
* @gpio2: The GPIO2 pin to activate (200...215).
|
|
|
|
*
|
|
|
|
* see function alchemy_gpio2_enable_int() for more information.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_disable_int(int gpio2)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
gpio2 -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
/* Au1100/Au1500 have GPIO208-215 enable bits at 0..7 */
|
2009-11-24 03:40:00 +08:00
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1100:
|
|
|
|
case ALCHEMY_CPU_AU1500:
|
|
|
|
gpio2 -= 8;
|
|
|
|
}
|
|
|
|
|
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 20:09:55 +08:00
|
|
|
local_irq_save(flags);
|
|
|
|
__alchemy_gpio2_mod_int(gpio2, 0);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* alchemy_gpio2_enable - Activate GPIO2 block.
|
|
|
|
*
|
|
|
|
* The GPIO2 block must be enabled excplicitly to work. On systems
|
|
|
|
* where this isn't done by the bootloader, this macro can be used.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_enable(void)
|
|
|
|
{
|
|
|
|
au_writel(3, GPIO2_ENABLE); /* reset, clock enabled */
|
|
|
|
au_sync();
|
|
|
|
au_writel(1, GPIO2_ENABLE); /* clock enabled */
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* alchemy_gpio2_disable - disable GPIO2 block.
|
|
|
|
*
|
|
|
|
* Disable and put GPIO2 block in low-power mode.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_disable(void)
|
|
|
|
{
|
|
|
|
au_writel(2, GPIO2_ENABLE); /* reset, clock disabled */
|
|
|
|
au_sync();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************/
|
|
|
|
|
|
|
|
/* wrappers for on-chip gpios; can be used before gpio chips have been
|
|
|
|
* registered with gpiolib.
|
|
|
|
*/
|
|
|
|
static inline int alchemy_gpio_direction_input(int gpio)
|
|
|
|
{
|
|
|
|
return (gpio >= ALCHEMY_GPIO2_BASE) ?
|
|
|
|
alchemy_gpio2_direction_input(gpio) :
|
|
|
|
alchemy_gpio1_direction_input(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio_direction_output(int gpio, int v)
|
|
|
|
{
|
|
|
|
return (gpio >= ALCHEMY_GPIO2_BASE) ?
|
|
|
|
alchemy_gpio2_direction_output(gpio, v) :
|
|
|
|
alchemy_gpio1_direction_output(gpio, v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio_get_value(int gpio)
|
|
|
|
{
|
|
|
|
return (gpio >= ALCHEMY_GPIO2_BASE) ?
|
|
|
|
alchemy_gpio2_get_value(gpio) :
|
|
|
|
alchemy_gpio1_get_value(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void alchemy_gpio_set_value(int gpio, int v)
|
|
|
|
{
|
|
|
|
if (gpio >= ALCHEMY_GPIO2_BASE)
|
|
|
|
alchemy_gpio2_set_value(gpio, v);
|
|
|
|
else
|
|
|
|
alchemy_gpio1_set_value(gpio, v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio_is_valid(int gpio)
|
|
|
|
{
|
|
|
|
return (gpio >= ALCHEMY_GPIO2_BASE) ?
|
|
|
|
alchemy_gpio2_is_valid(gpio) :
|
|
|
|
alchemy_gpio1_is_valid(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio_cansleep(int gpio)
|
|
|
|
{
|
|
|
|
return 0; /* Alchemy never gets tired */
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_gpio_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return (gpio >= ALCHEMY_GPIO2_BASE) ?
|
|
|
|
alchemy_gpio2_to_irq(gpio) :
|
|
|
|
alchemy_gpio1_to_irq(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int alchemy_irq_to_gpio(int irq)
|
|
|
|
{
|
2009-11-24 03:40:00 +08:00
|
|
|
switch (alchemy_get_cputype()) {
|
|
|
|
case ALCHEMY_CPU_AU1000:
|
|
|
|
return au1000_irq_to_gpio(irq);
|
|
|
|
case ALCHEMY_CPU_AU1100:
|
|
|
|
return au1100_irq_to_gpio(irq);
|
|
|
|
case ALCHEMY_CPU_AU1500:
|
|
|
|
return au1500_irq_to_gpio(irq);
|
|
|
|
case ALCHEMY_CPU_AU1550:
|
|
|
|
return au1550_irq_to_gpio(irq);
|
|
|
|
case ALCHEMY_CPU_AU1200:
|
|
|
|
return au1200_irq_to_gpio(irq);
|
|
|
|
}
|
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 20:09:55 +08:00
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************/
|
|
|
|
|
|
|
|
/* Linux gpio framework integration.
|
|
|
|
*
|
|
|
|
* 4 use cases of Au1000-Au1200 GPIOS:
|
|
|
|
*(1) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=y:
|
|
|
|
* Board must register gpiochips.
|
|
|
|
*(2) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=n:
|
|
|
|
* 2 (1 for Au1000) gpio_chips are 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
|
|
|
|
* Au1000 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 Au1000 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).
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef CONFIG_GPIOLIB
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef CONFIG_ALCHEMY_GPIO_INDIRECT /* case (4) */
|
|
|
|
|
|
|
|
static inline int gpio_direction_input(int gpio)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_direction_input(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_direction_output(int gpio, int v)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_direction_output(gpio, v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_get_value(int gpio)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_get_value(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_set_value(int gpio, int v)
|
|
|
|
{
|
|
|
|
alchemy_gpio_set_value(gpio, v);
|
|
|
|
}
|
|
|
|
|
2011-05-08 16:42:13 +08:00
|
|
|
static inline int gpio_get_value_cansleep(unsigned gpio)
|
|
|
|
{
|
|
|
|
return gpio_get_value(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_set_value_cansleep(unsigned gpio, int value)
|
|
|
|
{
|
|
|
|
gpio_set_value(gpio, value);
|
|
|
|
}
|
|
|
|
|
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 20:09:55 +08:00
|
|
|
static inline int gpio_is_valid(int gpio)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_is_valid(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_cansleep(int gpio)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_cansleep(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
return alchemy_gpio_to_irq(gpio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int irq_to_gpio(int irq)
|
|
|
|
{
|
|
|
|
return alchemy_irq_to_gpio(irq);
|
|
|
|
}
|
|
|
|
|
2009-08-28 17:26:58 +08:00
|
|
|
static inline int gpio_request(unsigned gpio, const char *label)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-05-08 16:42:13 +08:00
|
|
|
static inline int gpio_request_one(unsigned gpio,
|
|
|
|
unsigned long flags, const char *label)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_request_array(struct gpio *array, size_t num)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-08-28 17:26:58 +08:00
|
|
|
static inline void gpio_free(unsigned gpio)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2011-05-08 16:42:13 +08:00
|
|
|
static inline void gpio_free_array(struct gpio *array, size_t num)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_set_debounce(unsigned gpio, unsigned debounce)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_export(unsigned gpio, bool direction_may_change)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_export_link(struct device *dev, const char *name,
|
|
|
|
unsigned gpio)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int gpio_sysfs_set_active_low(unsigned gpio, int value)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gpio_unexport(unsigned gpio)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
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 20:09:55 +08:00
|
|
|
#endif /* !CONFIG_ALCHEMY_GPIO_INDIRECT */
|
|
|
|
|
|
|
|
|
|
|
|
#else /* CONFIG GPIOLIB */
|
|
|
|
|
|
|
|
|
|
|
|
/* 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 alchemy_irq_to_gpio
|
|
|
|
|
|
|
|
#include <asm-generic/gpio.h>
|
|
|
|
|
|
|
|
#endif /* !CONFIG_ALCHEMY_GPIO_INDIRECT */
|
|
|
|
|
|
|
|
|
|
|
|
#endif /* !CONFIG_GPIOLIB */
|
|
|
|
|
|
|
|
#endif /* _ALCHEMY_GPIO_AU1000_H_ */
|