- 08 12月, 2011 1 次提交
-
-
由 Manuel Lauss 提交于
Add basic support for the Au1300 variant(s): - New GPIO/Interrupt controller - DBDMA ids - USB setup - MMC support - enable various PSC drivers - detection code. Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com> To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/2866/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 25 10月, 2011 1 次提交
-
-
由 Manuel Lauss 提交于
For GPIOLIB=y decide at runtime which gpiochips to register; in the GPIOLIB=n case, the gpio headers need to be reshuffled a bit to make multiple implementations coexist peacefully. Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com> To: Linux-MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/2679/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 27 2月, 2010 1 次提交
-
-
由 Manuel Lauss 提交于
Remove the cpu subtype cpp macros in favor of runtime detection, to improve compile coverage of the alchemy common code. (Increases kernel size by 700 bytes). Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/699/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 17 6月, 2009 1 次提交
-
-
由 Manuel Lauss 提交于
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: NManuel Lauss <manuel.lauss@gmail.com> Acked-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-