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>
ENGR00225131-01 USB: revert ENGR00221317-02 about set stop_mode_config patch

IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.

This reverts commit c6f69925f9d1f39ccc8c6fcc583122fcf03c105c.

Signed-off-by: make shi <b15407@freescale.com>
ENGR00225131-02 USB: revert ENGR00221317-02 stop_mode_config patch head file

IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.

This reverts commit cc2e51368f2620a37370746eaf35f0b70674b31e.

Signed-off-by: make shi <b15407@freescale.com>
ENGR00225131-03 MX6 USB: add platform_phy_power_on platform data in head file

IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.

add platform_1p1_on platform data in head file.

Signed-off-by: make shi <b15407@freescale.com>
ENGR00225131-04 MX6 USB: implement platform_phy_power_on for USB otg and h1

IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.

Set stop_mode_config bit to turn on 1P1 during system suspend to support USB
host remote wake up or USB device DP/DM wake up.

Signed-off-by: make shi <b15407@freescale.com>
ENGR00225131-05 MX6 USB: set stop_mode_config bit if wake up is enabled

IC designer had clarified that 1P1 can be turned off if we do not need support
remote wakeup. So If there is no requirement for USB remote wake up, the 1P1
can be turn off. USB driver will support dynamically turn on(off) 1P1 during
system suspend. 1P1 will be turn on depend on USB wakeup is enabled.

- Set stop_mode_config bit if USB host need support USB remote wake up
- Set stop_mode_config bit if USB device need support USB DP/DM wake
  up system

Signed-off-by: make shi <b15407@freescale.com>
ENGR00225131-06 MX6 PM: clear stop_mode_config after system resume

- If stop_mode_config is set as 1, the USB otg vbus wakeup system can be
  supported
- After system resume, need clear stop_mode_config bit to keep the 1P1
  default off

Signed-off-by: make shi <b15407@freescale.com>
ARM: etm: Don't require clock control

If clk_get fail, assume the etb does not need a separate clock.

Change-Id: Ia0bf3f5391e94a60ea45876aa7afc8a88a7ec3bf
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Don't limit tracing to only non-secure code.

On some systems kernel code is considered secure, and this code
already limits tracing to the kernel text segment which results
in no trace data.

Change-Id: I098a0753e874859446d098e1ee209f67fc13cd5d
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Don't try to clear the buffer full status after reading the buffer

If the write address was at the end of the buffer, toggling the trace
capture bit would set the RAM-full status instead of clearing it, and
if any of the stop bits in the formatter is set toggling the trace
capture bit may not do anything.

Instead use the read position to find out if the data has already
been returned.

This also fixes the read function so it works when the trace buffer is
larger than the buffer passed in from user space. The old version
would reset the trace buffer pointers after every read, so the second
call to read would always return 0.

Change-Id: I75256abe2556adfd66fd5963e46f9e84ae4645e1
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Allow range selection

Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything by writing 0 0.

Change-Id: Ibb734ca820fedf79560b20536247f1e1700cdc71
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Configure data tracing

The old code enabled data tracing, but did not configure the
range. We now configure it to trace all data addresses by default,
and add a trace_data_range attribute to change the range or disable
data tracing.

Change-Id: I9d04e3e1ea0d0b4d4d5bcb93b1b042938ad738b2
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Add some missing locks and error checks

It is not safe to call etm_lock or etb_lock without holding the
mutex since another thread may also have unlocked the registers.

Also add some missing checks for valid etb_regs in the etm sysfs
entries.

Change-Id: I939f76a6ea7546a8fc0d4ddafa2fd2b6f38103bb
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Return the entire trace buffer if it is empty after reset

On some SOCs the read and write pointer are reset when the chip
resets, but the trace buffer content is preserved. If the status
bits indicates that the buffer is empty and we have never started
tracing, assume the buffer is full instead. This can be useful
if the system rebooted from a watchdog reset.

Change-Id: Iaf21c2c329c6059004ee1d38e3dfff66d7d28029
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Support multiple ETMs/PTMs.

If more than one ETM or PTM are present, configure all of them
and enable the formatter in the ETB. This allows tracing on dual
core systems (e.g. omap4).

Change-Id: I028657d5cf2bee1b23f193d4387b607953b35888
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Power down etm(s) when tracing is not enabled

Without this change a saw an 18% increase in idle power consumption
on one deivce when trace support is compiled into the kernel. Now
I see the same increase only when tracing.

Change-Id: I21bb5ecf1b7d29ce3790ceeb5323409cc22d5a3b
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Wait for etm/ptm(s) to stop before requesting PowerDown

When PowerDown was requested at the same time as ProgBit, the
formatter flush command that follows could get stuck.

Change-Id: Iafb665f61f055819e64ca1dcb60398c656f593e4
Signed-off-by: Arve Hjønnevåg <arve@android.com>
ARM: etm: Check arch version and disable data tracing for ptm

Change-Id: If2cb7928d0711f48348443d882a12416be9c5910
Signed-off-by: Arve Hjønnevåg <arve@android.com>