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