Merge branch 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds into next/drivers

From Bryan Wu <bryan.wu@canonical.com>:

Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a
new generic led trigger for CPU not only for ARM but also for others.

For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to
trigger idle start or idle end event.

These patches convert old style LED driver in arch/arm to gpio_led or new led
driver interface. Against 3.5 release and build successfully for all the machines.

Test ledtrig-cpu driver on OMAP4 Panda board.

v9 --> v10
 * fix compiling issue on versatile_defconfig reported by Russell King
 * rebase to 3.5 kernel and move patches to new git tree

v8 --> v9:
 * use mutex to replace rw_sema pointed out by Tim Gardner
 * add a new struct led_trigger_cpu
 * add lock_is_inited to record mutex lock initialization

v6 --> v7:
 * add a patch to unify the led-trigger name
 * fix some typo pointed
 * use BUG_ON to detect CPU numbers during building stage

v5 --> v6:
 * replace  __get_cpu_var() to per_cpu()
 * remove smp_processor_id() which is wrong with for_each_possible_cpu()
 * test on real OMAP4 Panda board
 * add comments about CPU hotplug in the CPU LED trigger driver

v4 --> v5:
 * rebase all the patches on top of latest linux-next
 * replace on_each_cpu() with for_each_possible_cpu()
 * add some description of ledtrig_cpu() API
 * remove old leds code from driver nwflash.c, which should use a new led trigger then
 * this trigger driver can be built as module now

v3 --> v4:
 * fix a typo pointed by Jochen Friedrich
 * fix some building errors
 * add Reviewed-by and Tested-by into patch log

v2 --> v3:
 * almost rewrote the whole ledtrig-cpu driver, which is more simple
 * every CPU will have a per-CPU trigger
 * cpu trigger can be assigned to any leds
 * fix a lockdep issue in led-trigger common code
 * other fix according to review

v1 --> v2:
 * remove select operations in Kconfig of every machines
 * add back supporting of led in core module of mach-integrator
 * solidate name scheme in ledtrig-cpu.c
 * add comments of CPU_LED_* cpu led events
 * fold patches of RealView and Versatile together
 * add machine_is_ check during assabet led driver init
 * add some Acked-by in patch logs
 * remove code for simpad machine in machine-sa11000, since Jochen Friedrich
   introduced gpiolib and gpio-led driver for simpad
 * on Assabet and Netwinder machine, LED operations is reversed like:
   setting bit means turn off leds
   clearing bit means turn on leds
 * add a new function to read CM_CTRL register for led driver

* 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
  ARM: use new LEDS CPU trigger stub to replace old one
  ARM: mach-sa1100: retire custom LED code
  ARM: mach-omap1: retire custom LED code
  ARM: mach-pnx4008: remove including old leds event API header file
  ARM: plat-samsung: remove including old leds event API header file
  ARM: mach-pxa: retire custom LED code
  char: nwflash: remove old led event code
  ARM: mach-footbridge: retire custom LED code
  ARM: mach-ebsa110: retire custom LED code
  ARM: mach-clps711x: retire custom LED code of P720T machine
  ARM: mach-integrator: retire custom LED code
  ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions
  ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger
  ARM: mach-shark: retire custom LED code
  ARM: mach-ks8695: remove leds driver, since nobody use it
  ARM: mach-realview and mach-versatile: retire custom LED code
  ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers
  led-triggers: create a trigger for CPU activity

Conflicts:
	arch/arm/mach-clps711x/p720t.c
	arch/arm/mach-sa1100/leds-cerf.c
	arch/arm/mach-sa1100/leds-lart.c

Let's hope this is the last time we pull this and it doesn't cause
more trouble. I have verified that version 10 causes no build
warnings or errors any more, and the patches still look good.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

1 files changed, 0 insertions, 53 deletions

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cdc6fe5..ac353cf0180b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1787,59 +1787,6 @@ config FORCE_MAX_ZONEORDER
           This config option is actually maximum order plus one. For example,
           a value of 11 means that the largest free memory block is 2^10 pages.
 
-config LEDS
-        bool "Timer and CPU usage LEDs"
-        depends on ARCH_CDB89712 || ARCH_EBSA110 || \
-                   ARCH_EBSA285 || ARCH_INTEGRATOR || \
-                   ARCH_LUBBOCK || MACH_MAINSTONE || ARCH_NETWINDER || \
-                   ARCH_OMAP || ARCH_P720T || ARCH_PXA_IDP || \
-                   ARCH_SA1100 || ARCH_SHARK || ARCH_VERSATILE || \
-                   ARCH_AT91 || ARCH_DAVINCI || \
-                   ARCH_KS8695 || MACH_RD88F5182 || ARCH_REALVIEW
-        help
-          If you say Y here, the LEDs on your machine will be used
-          to provide useful information about your current system status.
-
-          If you are compiling a kernel for a NetWinder or EBSA-285, you will
-          be able to select which LEDs are active using the options below. If
-          you are compiling a kernel for the EBSA-110 or the LART however, the
-          red LED will simply flash regularly to indicate that the system is
-          still functional. It is safe to say Y here if you have a CATS
-          system, but the driver will do nothing.
-
-config LEDS_TIMER
-        bool "Timer LED" if (!ARCH_CDB89712 && !ARCH_OMAP) || \
-                            OMAP_OSK_MISTRAL || MACH_OMAP_H2 \
-                            || MACH_OMAP_PERSEUS2
-        depends on LEDS
-        depends on !GENERIC_CLOCKEVENTS
-        default y if ARCH_EBSA110
-        help
-          If you say Y here, one of the system LEDs (the green one on the
-          NetWinder, the amber one on the EBSA285, or the red one on the LART)
-          will flash regularly to indicate that the system is still
-          operational. This is mainly useful to kernel hackers who are
-          debugging unstable kernels.
-
-          The LART uses the same LED for both Timer LED and CPU usage LED
-          functions. You may choose to use both, but the Timer LED function
-          will overrule the CPU usage LED.
-
-config LEDS_CPU
-        bool "CPU usage LED" if (!ARCH_CDB89712 && !ARCH_EBSA110 && \
-                        !ARCH_OMAP) \
-                        || OMAP_OSK_MISTRAL || MACH_OMAP_H2 \
-                        || MACH_OMAP_PERSEUS2
-        depends on LEDS
-        help
-          If you say Y here, the red LED will be used to give a good real
-          time indication of CPU usage, by lighting whenever the idle task
-          is not currently executing.
-
-          The LART uses the same LED for both Timer LED and CPU usage LED
-          functions. You may choose to use both, but the Timer LED function
-          will overrule the CPU usage LED.
-
 config ALIGNMENT_TRAP
         bool
         depends on CPU_CP15_MMU