summaryrefslogtreecommitdiff
path: root/include/linux/vexpress.h
AgeCommit message (Collapse)Author
2013-07-09reboot: arm: change reboot_mode to use enum reboot_modeRobin Holt
Preparing to move the parsing of reboot= to generic kernel code forces the change in reboot_mode handling to use the enum. [akpm@linux-foundation.org: fix arch/arm/mach-socfpga/socfpga.c] Signed-off-by: Robin Holt <holt@sgi.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Russ Anderson <rja@sgi.com> Cc: Robin Holt <holt@sgi.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-03-21arm: vexpress: Decouple vexpress-poweroff implementation from machine_descCatalin Marinas
This patch adds the pm_power_off and arm_pm_restart variable settings to the vexpress-poweroff.c driver to decouple it from the machine_desc definition. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Pawel Moll <pawel.moll@arm.com>
2013-02-13mfd: vexpress: Add pseudo-GPIO based LEDsPawel Moll
The LEDs on the Versatile Express motherboard are controlled through simple memory-mapped register. This patch extends the pseudo-GPIO controller definition for these lines and creates generic "leds-gpio" device using them Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-11-05ARM: vexpress: Start using new Versatile Express infrastructurePawel Moll
This patch starts using all the configuration infrastructure. - generic GPIO library is forced now - sysreg GPIOs are used as MMC CD and WP information sources; thanks to this MMCI auxiliary data is not longer necessary - DVI muxer and mode control is removed from non-DT V2P-CA9 code as this is now handled by the vexpress-dvi driver - clock generators control is removed as is being handled by the common clock driver now - the sysreg and sysctl control is now delegated to the appropriate drivers and all related code was removed - NOR Flash set_vpp function has been removed as the control bit used does _not_ control its VPP line, but the #WP signal instead (which is de facto unusable in case of Linux MTD drivers); this also allowed the remove its DT auxiliary data The non-DT code defines only minimal required number of the config devices. Device Trees are updated to make use of all new features. Signed-off-by: Pawel Moll <pawel.moll@arm.com>
2012-11-05mfd: Versatile Express system registers driverPawel Moll
This is a platform driver for Versatile Express' "system register" block. It's a random collection of registers providing the following functionality: - low level platform functions like board ID access; in order to use those, the driver must be initialized early, either statically or based on the DT - config bus bridge via "system control" interface; as the response from the controller does not generate interrupt (yet), the status register is periodically polled using a timer - pseudo GPIO lines providing MMC card status and Flash WP# signal control - LED interface for a set of 8 LEDs on the motherboard, with "heartbeat", "mmc0" and "cpu0" to "cpu5" as default triggers Signed-off-by: Pawel Moll <pawel.moll@arm.com>
2012-11-05mfd: Versatile Express config infrastructurePawel Moll
Versatile Express platform has an elaborated configuration system, consisting of microcontrollers residing on the mother- and daughterboards known as Motherboard/Daughterboard Configuration Controller (MCC and DCC). The controllers are responsible for the platform initialization (reset generation, flash programming, FPGA bitfiles loading etc.) but also control clock generators, voltage regulators, gather environmental data like temperature, power consumption etc. Even the video output switch (FPGA) is controlled that way. Those devices are _not_ visible in the main address space and the usual communication channel uses some kind of a bridge in the peripheral block sending commands (requests) to the controllers and receiving responses. It can take up to 500 microseconds for a transaction to be completed, therefore it is important to provide a non-blocking interface to it. This patch adds an abstraction of this infrastructure. Bridge drivers can register themselves with the framework. Then, a driver of a device can request an abstract "function" - the request will be redirected to a bridge referred by thedd "arm,vexpress,config-bridge" property of the device tree node. Signed-off-by: Pawel Moll <pawel.moll@arm.com>