leds: leds-qpnp: use a single global mutex for flash led

Add a single global mutex for all instances of flash leds -
flash_0,flash_1 and flash_torch to avoid concurrency issues.

CRs-Fixed: 640712
Change-Id: I38a30432a86e47e11f975358c71557da1f58667e
Signed-off-by: Abinaya P <abinayap@codeaurora.org>
leds: leds-qpnp: remove the usage of mutex_destroy for static mutex

Remove the call to mutex_destroy for the statically defined
mutex flash_lock.

CRs-Fixed: 640712
Change-Id: I664b0b94ff8e2f74d49d3f759d955bee513e5daf
Signed-off-by: Abinaya P <abinayap@codeaurora.org>
leds: leds-qpnp: make blink functionality synchronous

pwm_cfg->blinking is a shared parameter between qpnp_mpp_set
and led_blink function. When a blink operation is given to
the led when it is glowing with some brightness value, the led
does not blink because the blinking parameter is wrongly
reset to false in the end of qpnp_mpp_set. So making the blink
functionality synchronous will solve the issue.

Change-Id: Ie84fe52bc84d5c14573e3f1a042e163e62152cce
CRs-Fixed: 714466 703170
Signed-off-by: Abinaya P <abinayap@codeaurora.org>
leds: leds-qpnp: allocate ordered work queue for led

From user space, the call procedures of red led blink are as
below:
1. turn off red led.
2. blink red led.

Each above step will be transitioned from user space to kernel
driver and trigger a led WORK. The order from user space is
very important because if the step 2 completes before step 1,
then the red led will be turned off, while the user wants to
blink it.

On kernel version 3.4, below sequences will cause the order
from user space fail:
1. CPU0 schedule a led WORK on system_wq, which is to turn off
   the red led.
2. CPU1 schedule a led WORK on system_wq, which is to blink the
   red led.
3. Although the first WORK is queued before the second WORK,
   both of them can executed concurrently on CPU0 and CPU1.
4. CPU0's workload is very heavy because it will handle almost
   all the hardware interrupt, so it is probably that the first
   WORK thread is scheduled out for some time. At that moment,
   the second WORK can complete faster than the first WORK.
   This finally cause the red led is first blinking then been
   turned off.

To solve this issue on Kernel version 3.4, we can create an
ordered workqueue which will promise us that the same led WORK
will not be scheduled on different cpu and cannot be executed on
different cpu concurrently.

On kernel version 3.10, because the default system_wq has
already promised the concurrency of the same WORK, so we don't
need to use ordered workqueue for led module.

Change-Id: I23fda20f2951bfcebb7ce7c9ecea542435496efe
CRs-Fixed: 714466 703170
Signed-off-by: Mao Li <maol@codeaurora.org>
Signed-off-by: Abinaya P <abinayap@codeaurora.org>
ARM: dts: msm: use ordered workqueue only when specified

Use alloc_ordered_workqueue function to queue work only
when specified from the dtsi node for the corresponding led.

Change-Id: Ie5e1763f48cd6455b6afcb7fbee44bf15449810c
CRs-Fixed: 714466 703170
Signed-off-by: Abinaya P <abinayap@codeaurora.org>
Signed-off-by: Mao Li <maol@codeaurora.org>
Merge "leds: leds-qpnp: use a single global mutex for flash led"
Merge "leds: leds-qpnp: remove the usage of mutex_destroy for static mutex"
Merge "leds: leds-qpnp: make blink functionality synchronous"
Merge "leds: leds-qpnp: allocate ordered work queue for led"
Merge "ARM: dts: msm: use ordered workqueue only when specified"