i.MX6: mx6q_sabrelite: add vwl1271 regulator
ENGR00220342 mmc: sdhci:reform fix for dat1 glitch causes system panic

refix this bug, sdhci_init should be done before request_irq to
clear those wild interrupts.
Former fix commit is 4e3a2b40a16b8d5065b680ab86df288515cdea9c.

Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
(cherry picked from commit 9bb464fc3b5a4798ff92238ce8d8e2f68c4c5d40)
ENGR00226219 Revert "mmc: protect clk_status by spinlock"

This reverts commit 640736923c1952ccbfcebf1bb33bad25c4812464.
We revert this temporary workaround, and cherry-pick
the formal fix of eMMC clock enable/disable issue.

Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com>
ENGR00225534-1 mmc: core: move ->request() call from atomic context

mmc_request_done() is sometimes called from interrupt or other atomic
context.  Mostly all mmc_request_done() does is complete(), however it
contains code to retry on error, which uses ->request().  As the error
path is certainly not performance critical, this may be moved to the
waiting function mmc_wait_for_req_done().

This allows ->request() to use runtime PM get_sync() and guarantee it
is never in an atomic context.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Acked-by: Ryan QIAN <b32804@freescale.com>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
ENGR00225534-2 mmc: sdhci: using cancel_work_sync instread of cancel_delayed_work

We recently met an rarely happened sychronization issue which can cause
mmc timeout during transfer as follows:
[ OK ]onfiguring network interfaces...
[ OK ]ctivating swap...
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0xd00
mmcblk0: error -110 transferring data, sector 9981952, nr 16, cmd response 0x900, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 9981952

The root cause is that host uses cancel_delayed_work to cancel the delayed
clock disable work to avoid clock to be disabled if a new cmd
transfer request happens.
However, the work callback may already be running during the excution
of cancel_delayed_work which can not be cancelled and causes
the clock probably still to be disabled during cmd transfer,
then cmd timeout happens.

Using cancel_work_sync instead to wait for the completion of clock disable
first then we can make sure the clock can not be disabled during the cmd
transfer.

BTW, although the original code checks if in interrupt context, however,
it's still not interrupt context safe due to the unsafe platform_clk_ctrl,
so it's ok to directly use cancel_work_sync here and sdhci_enable_clk is
simply not allowed to be called in irq context.

Acked-by: Ryan QIAN <b32804@freescale.com>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
ENGR00225594 mmc: sdhci: remove calling enable clk in interrupt context

There's kernel warning without when insmod WiFi module as follows:

------------[ cut here ]------------
WARNING: at kernel/irq/handle.c:130 handle_irq_event_percpu+0x164/0x180()
irq 55 handler sdhci_irq+0x0/0x988 enabled interrupts
Modules linked in: ar6000
[<800471dc>] (unwind_backtrace+0x0/0xfc) from
	[<80072fd0>] (warn_slowpath_common+0x4c/0x64)
[<80072fd0>] (warn_slowpath_common+0x4c/0x64) from
	[<8007307c>] (warn_slowpath_fmt+0x30/0x40)
[<8007307c>] (warn_slowpath_fmt+0x30/0x40) from
	[<800a9f54>] (handle_irq_event_percpu+0x164/0x180)
[<800a9f54>] (handle_irq_event_percpu+0x164/0x180) from
	[<800a9fac>] (handle_irq_event+0x3c/0x5c)
[<800a9fac>] (handle_irq_event+0x3c/0x5c) from
	[<800ac2a8>] (handle_fasteoi_irq+0x98/0x148)
[<800ac2a8>] (handle_fasteoi_irq+0x98/0x148) from
	[<800a9a2c>] (generic_handle_irq+0x2c/0x38)
[<800a9a2c>] (generic_handle_irq+0x2c/0x38) from
	[<80041f60>] (handle_IRQ+0x4c/0xb8)
[<80041f60>] (handle_IRQ+0x4c/0xb8) from
	[<80040f8c>] (__irq_svc+0x4c/0xe8)
[<80040f8c>] (__irq_svc+0x4c/0xe8) from
	[<800420e4>] (default_idle+0x24/0x28)
[<800420e4>] (default_idle+0x24/0x28) from
	[<80042730>] (cpu_idle+0xbc/0xfc)
[<80042730>] (cpu_idle+0xbc/0xfc) from
	[<80008904>] (start_kernel+0x248/0x288)
[<80008904>] (start_kernel+0x248/0x288) from
	[<10008040>] (0x10008040)
---[ end trace 95ab51b95e0e8e5f ]---

it is caused by calling cancel_delayed_work_sync in sdhci_enable_clk, since
it will call spin_unlock_irq which will possibly enable irq in interrupt
context. if sdhci_enable_clk is called in interrupt context this warning
will be shown.

sdhci_enable_clk will be called in interrupt context in the following path:
sdhci_irq->mmc_signal_sdio_irq->mmc_signal_sdio_irq->sdhci_enable_sdio_irq->...
     |____________________interrupt context____________________________________

fix:
Remove calling sdhci_enable_clk in sdhci_enable_sdio_irq. For sdio cards, sdhci
clk will not be disabled, so it is save to remove it.

Signed-off-by: Ryan QIAN <b32804@freescale.com>
Acked-by: Dong Aisheng <b29396@freescale.com>