linux/arch/mips/alchemy/Kconfig

155 lines
3.2 KiB
Plaintext
Raw Normal View History

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
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
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
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
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
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
config SOC_AU1X00
bool
select 64BIT_PHYS_ADDR
select CEVT_R4K_LIB
select CSRC_R4K_LIB
select IRQ_CPU
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