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: 703170
Signed-off-by: Mao Li <maol@codeaurora.org>
Signed-off-by: Abinaya P <abinayap@codeaurora.org>