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
|
|
|
# au1000-style gpio
|
|
|
|
config ALCHEMY_GPIO_AU1000
|
|
|
|
bool
|
|
|
|
|
|
|
|
# select this in your board config if you don't want to use the gpio
|
|
|
|
# namespace as documented in the manuals. In this case however you need
|
|
|
|
# to create the necessary gpio_* functions in your board code/headers!
|
|
|
|
# see arch/mips/include/asm/mach-au1x00/gpio.h for more information.
|
|
|
|
config ALCHEMY_GPIO_INDIRECT
|
|
|
|
def_bool n
|
|
|
|
|
2007-05-11 19:44:30 +08:00
|
|
|
choice
|
|
|
|
prompt "Machine type"
|
|
|
|
depends on MACH_ALCHEMY
|
|
|
|
default MIPS_DB1000
|
|
|
|
|
|
|
|
config MIPS_MTX1
|
|
|
|
bool "4G Systems MTX-1 board"
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select SOC_AU1500
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_BOSPORUS
|
|
|
|
bool "Alchemy Bosporus board"
|
|
|
|
select SOC_AU1500
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_DB1000
|
|
|
|
bool "Alchemy DB1000 board"
|
|
|
|
select SOC_AU1000
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_DB1100
|
|
|
|
bool "Alchemy DB1100 board"
|
|
|
|
select SOC_AU1100
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_DB1200
|
|
|
|
bool "Alchemy DB1200 board"
|
|
|
|
select SOC_AU1200
|
|
|
|
select DMA_COHERENT
|
|
|
|
select MIPS_DISABLE_OBSOLETE_IDE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_DB1500
|
|
|
|
bool "Alchemy DB1500 board"
|
|
|
|
select SOC_AU1500
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select MIPS_DISABLE_OBSOLETE_IDE
|
|
|
|
select SYS_SUPPORTS_BIG_ENDIAN
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_DB1550
|
|
|
|
bool "Alchemy DB1550 board"
|
|
|
|
select SOC_AU1550
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select MIPS_DISABLE_OBSOLETE_IDE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_MIRAGE
|
|
|
|
bool "Alchemy Mirage board"
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select SOC_AU1500
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_PB1000
|
|
|
|
bool "Alchemy PB1000 board"
|
|
|
|
select SOC_AU1000
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select SWAP_IO_SPACE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_PB1100
|
|
|
|
bool "Alchemy PB1100 board"
|
|
|
|
select SOC_AU1100
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select SWAP_IO_SPACE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_PB1200
|
|
|
|
bool "Alchemy PB1200 board"
|
|
|
|
select SOC_AU1200
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select MIPS_DISABLE_OBSOLETE_IDE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_PB1500
|
|
|
|
bool "Alchemy PB1500 board"
|
|
|
|
select SOC_AU1500
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_PB1550
|
|
|
|
bool "Alchemy PB1550 board"
|
|
|
|
select SOC_AU1550
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select HW_HAS_PCI
|
|
|
|
select MIPS_DISABLE_OBSOLETE_IDE
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
config MIPS_XXS1500
|
|
|
|
bool "MyCable XXS1500 board"
|
|
|
|
select DMA_NONCOHERENT
|
|
|
|
select SOC_AU1500
|
|
|
|
select SYS_SUPPORTS_LITTLE_ENDIAN
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config SOC_AU1000
|
|
|
|
bool
|
|
|
|
select SOC_AU1X00
|
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
|
|
|
select ALCHEMY_GPIO_AU1000
|
2007-05-11 19:44:30 +08:00
|
|
|
|
|
|
|
config SOC_AU1100
|
|
|
|
bool
|
|
|
|
select SOC_AU1X00
|
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
|
|
|
select ALCHEMY_GPIO_AU1000
|
2007-05-11 19:44:30 +08:00
|
|
|
|
|
|
|
config SOC_AU1500
|
|
|
|
bool
|
|
|
|
select SOC_AU1X00
|
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
|
|
|
select ALCHEMY_GPIO_AU1000
|
2007-05-11 19:44:30 +08:00
|
|
|
|
|
|
|
config SOC_AU1550
|
|
|
|
bool
|
|
|
|
select SOC_AU1X00
|
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
|
|
|
select ALCHEMY_GPIO_AU1000
|
2007-05-11 19:44:30 +08:00
|
|
|
|
|
|
|
config SOC_AU1200
|
|
|
|
bool
|
|
|
|
select SOC_AU1X00
|
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
|
|
|
select ALCHEMY_GPIO_AU1000
|
2007-05-11 19:44:30 +08:00
|
|
|
|
|
|
|
config SOC_AU1X00
|
|
|
|
bool
|
2007-08-02 07:36:08 +08:00
|
|
|
select 64BIT_PHYS_ADDR
|
2008-12-21 16:26:23 +08:00
|
|
|
select CEVT_R4K_LIB
|
|
|
|
select CSRC_R4K_LIB
|
2007-10-17 17:58:43 +08:00
|
|
|
select IRQ_CPU
|
2007-05-11 19:44:30 +08:00
|
|
|
select SYS_HAS_CPU_MIPS32_R1
|
|
|
|
select SYS_SUPPORTS_32BIT_KERNEL
|
|
|
|
select SYS_SUPPORTS_APM_EMULATION
|
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
|
|
|
select GENERIC_GPIO
|
|
|
|
select ARCH_WANT_OPTIONAL_GPIOLIB
|