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.
|
2013-01-22 19:59:30 +08:00
|
|
|
* GPIO0-31 from GPIO1 block, GPIO200-215 from GPIO2 block.
|
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
|
|
|
*/
|
|
|
|
#define ALCHEMY_GPIO1_BASE 0
|
|
|
|
#define ALCHEMY_GPIO2_BASE 200
|
|
|
|
|
|
|
|
#define ALCHEMY_GPIO1_NUM 32
|
|
|
|
#define ALCHEMY_GPIO2_NUM 16
|
2013-01-22 19:59:30 +08:00
|
|
|
#define ALCHEMY_GPIO1_MAX (ALCHEMY_GPIO1_BASE + ALCHEMY_GPIO1_NUM - 1)
|
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
|
|
|
#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:20 +08:00
|
|
|
/* GPIO1 registers within SYS_ area */
|
2014-07-23 22:36:24 +08:00
|
|
|
#define AU1000_SYS_TRIOUTRD 0x100
|
|
|
|
#define AU1000_SYS_TRIOUTCLR 0x100
|
|
|
|
#define AU1000_SYS_OUTPUTRD 0x108
|
|
|
|
#define AU1000_SYS_OUTPUTSET 0x108
|
|
|
|
#define AU1000_SYS_OUTPUTCLR 0x10C
|
|
|
|
#define AU1000_SYS_PINSTATERD 0x110
|
|
|
|
#define AU1000_SYS_PININPUTEN 0x110
|
2011-05-08 16:42:20 +08:00
|
|
|
|
|
|
|
/* register offsets within GPIO2 block */
|
2014-07-23 22:36:24 +08:00
|
|
|
#define AU1000_GPIO2_DIR 0x00
|
|
|
|
#define AU1000_GPIO2_OUTPUT 0x08
|
|
|
|
#define AU1000_GPIO2_PINSTATE 0x0C
|
|
|
|
#define AU1000_GPIO2_INTENABLE 0x10
|
|
|
|
#define AU1000_GPIO2_ENABLE 0x14
|
2011-05-08 16:42:20 +08:00
|
|
|
|
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:
|
2013-01-22 19:59:30 +08:00
|
|
|
case 23 ... 28: return MAKE_IRQ(1, 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
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:
|
2013-01-22 19:59:30 +08:00
|
|
|
case 20 ... 28: return MAKE_IRQ(1, gpio);
|
|
|
|
case 16 ... 17: return MAKE_IRQ(1, 18 + gpio - 16);
|
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 au1550_gpio2_to_irq(int gpio)
|
|
|
|
{
|
|
|
|
gpio -= ALCHEMY_GPIO2_BASE;
|
|
|
|
|
|
|
|
switch (gpio) {
|
|
|
|
case 0: return MAKE_IRQ(1, 16);
|
2013-01-22 19:59:30 +08:00
|
|
|
case 1 ... 5: return MAKE_IRQ(1, 17); /* shared GPIO201_205 */
|
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
|
|
|
case 6 ... 7: return MAKE_IRQ(1, 29 + gpio - 6);
|
2013-01-22 19:59:30 +08:00
|
|
|
case 8 ... 15: return MAKE_IRQ(1, 31); /* shared GPIO208_215 */
|
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 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);
|
2013-01-22 19:59:30 +08:00
|
|
|
case 8 ... 15: return MAKE_IRQ(0, 28); /* shared GPIO208_215 */
|
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_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);
|
2014-07-23 22:36:24 +08:00
|
|
|
unsigned long r = v ? AU1000_SYS_OUTPUTSET : AU1000_SYS_OUTPUTCLR;
|
|
|
|
alchemy_wrsys(mask, r);
|
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 alchemy_gpio1_get_value(int gpio)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO1_BASE);
|
2014-07-23 22:36:24 +08:00
|
|
|
return alchemy_rdsys(AU1000_SYS_PINSTATERD) & mask;
|
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 alchemy_gpio1_direction_input(int gpio)
|
|
|
|
{
|
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO1_BASE);
|
2014-07-23 22:36:24 +08:00
|
|
|
alchemy_wrsys(mask, AU1000_SYS_TRIOUTCLR);
|
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 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;
|
|
|
|
}
|
|
|
|
|
2015-08-03 00:30:11 +08: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();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
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
|
|
|
unsigned long mask = 1 << (gpio - ALCHEMY_GPIO2_BASE);
|
2014-07-23 22:36:24 +08:00
|
|
|
unsigned long d = __raw_readl(base + AU1000_GPIO2_DIR);
|
2011-05-08 16:42:20 +08: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 20:09:55 +08:00
|
|
|
if (to_out)
|
|
|
|
d |= mask;
|
|
|
|
else
|
|
|
|
d &= ~mask;
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(d, base + AU1000_GPIO2_DIR);
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
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 void alchemy_gpio2_set_value(int gpio, int v)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
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
|
|
|
unsigned long mask;
|
|
|
|
mask = ((v) ? 0x00010001 : 0x00010000) << (gpio - ALCHEMY_GPIO2_BASE);
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(mask, base + AU1000_GPIO2_OUTPUT);
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
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 alchemy_gpio2_get_value(int gpio)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
2014-07-23 22:36:24 +08:00
|
|
|
return __raw_readl(base + AU1000_GPIO2_PINSTATE) &
|
|
|
|
(1 << (gpio - ALCHEMY_GPIO2_BASE));
|
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 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************/
|
|
|
|
|
|
|
|
/* GPIO2 shared interrupts and control */
|
|
|
|
|
|
|
|
static inline void __alchemy_gpio2_mod_int(int gpio2, int en)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
2014-07-23 22:36:24 +08:00
|
|
|
unsigned long r = __raw_readl(base + AU1000_GPIO2_INTENABLE);
|
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
|
|
|
if (en)
|
|
|
|
r |= 1 << gpio2;
|
|
|
|
else
|
|
|
|
r &= ~(1 << gpio2);
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(r, base + AU1000_GPIO2_INTENABLE);
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*
|
2013-01-22 19:59:30 +08:00
|
|
|
* The GPIO2 block must be enabled excplicitly to work. On systems
|
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
|
|
|
* where this isn't done by the bootloader, this macro can be used.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_enable(void)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(3, base + AU1000_GPIO2_ENABLE); /* reset, clock enabled */
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(1, base + AU1000_GPIO2_ENABLE); /* clock enabled */
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* alchemy_gpio2_disable - disable GPIO2 block.
|
|
|
|
*
|
|
|
|
* Disable and put GPIO2 block in low-power mode.
|
|
|
|
*/
|
|
|
|
static inline void alchemy_gpio2_disable(void)
|
|
|
|
{
|
2011-05-08 16:42:20 +08:00
|
|
|
void __iomem *base = (void __iomem *)KSEG1ADDR(AU1500_GPIO2_PHYS_ADDR);
|
2014-07-23 22:36:24 +08:00
|
|
|
__raw_writel(2, base + AU1000_GPIO2_ENABLE); /* reset, clock disabled */
|
2011-05-08 16:42:20 +08:00
|
|
|
wmb();
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************/
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* _ALCHEMY_GPIO_AU1000_H_ */
|