mmc: core: Don't cancel detect work during MMC suspend

When MMC host is suspending the cancellation of the MMC detect
work is in progress. And mmc_rescan() which had triggered for
SD card is blocked since mmcqd/1 has acquired the host lock.
The mmcqd/1 is waiting to proceed for the card status check.
Meanwhile, a write request is received on eMMC but it cannot
proceed as it is waiting for the ongoing runtime suspend to finish.

"kworker/0:1"
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|wait_for_common(x = 0xD9391E90, ?, state = 2, iowait = 0)
-003|flush_workqueue(wq = 0xD92DCA80)
-004|mmc_suspend_host(host = 0xD8B20000)
-005|msmsdcc_runtime_suspend(dev = 0xC08B0598)
-006|pm_generic_runtime_suspend(?)
-007|__rpm_callback(cb = 0xC02F1BD8, dev = 0xC08B0598)
-008|rpm_suspend(dev = 0xC08B0598, rpmflags = 2)
-009|pm_runtime_work(work = 0xC08B065C)
-010|process_one_work(worker = 0xD9367F40, work = 0xC08B065C)
-011|worker_thread(__worker = 0xD9367F40)
-012|kthread(_create = 0xD924FF18)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

"kworker/u:4"
----
-000|need_resched()
-001|__mmc_claim_host(host = 0xD8B21000, abort = 0x0)
-002|mmc_sd_detect(host = 0xD8B21000)
-003|mmc_rescan(work = 0xD8B212A0)
-004|process_one_work(worker = 0xCDB12440, work = 0xD8B212A0)
-005|worker_thread(__worker = 0xCDB12440)
-006|kthread(_create = 0xD8BC7F18)
-007|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/1 (running)
----
-000|need_resched()
-001|schedule_timeout(timeout = 2147483647)
-002|io_schedule_timeout(timeout = 2147483647)
-003|wait_for_common(x = 0xD8633E2C, ?, state = 2, iowait = 1)
-004|mmc_wait_for_req_done(host = 0xD8B21000, mrq = 0xD8633E1C)
-005|mmc_wait_for_cmd(host = 0xD8B21000, cmd = 0xD8633E50, retries = 5)
-006|get_card_status(card = 0xD8D8B800, status = 0xD8633EA4, retries = 5)
-007|mmc_blk_err_check(card = 0xD8D8B800, areq = 0xD8624440)
-008|mmc_start_req(host = 0xD8B21000, areq = 0x0, error = 0xD8633F4C)
-009|mmc_blk_issue_rw_rq(mq = 0xD8624008, ?)
-010|mmc_blk_issue_rq(mq = 0xD8624008, req = 0x0)
-011|mmc_queue_thread(d = 0xD8624008)
-012|kthread(_create = 0xD9397D80)
-013|kernel_thread_exit(asm)
 ---|end of frame
    |

mmcqd/0
----
-000|need_resched()
-001|rpm_resume(dev = 0xC08B0598, rpmflags = 4)
-002|__pm_runtime_resume(dev = 0xC08B0598, rpmflags = 4)
-003|msmsdcc_enable(mmc = 0xD8B20000)
-004|__mmc_claim_host(host = 0xD8B20000, abort = 0x0)
-005|mmc_blk_issue_rq(mq = 0xD8C43008, req = 0xC52C9798)
-006|mmc_queue_thread(d = 0xD8C43008)
-007|kthread(_create = 0xD9397D80)
-008|kernel_thread_exit(asm)
 ---|end of frame
    |

So remove the cancellation of the detect work for the
MMC suspend to proceed and avoid this deadlock.

CRs-Fixed: 471053
Change-Id: Id79d6b81e992b08039d639b1c0f6c2eb4a79df62
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: msm_sdcc: Fix SPS-BAM flags while in producer mode

For read operation (writing data into system memory), the
SDCC-BAM producer will update the EOT flags while writing
data done descriptors into pipe memory. It is not necessary
that the s/w should set EOT flag in system consumer mode as
that may confuse hardware.

CRs-Fixed: 468046
Change-Id: I31988fdcfaf6c9fb9c9bfc540837513ea40e125c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: block: reduce the block timeout to 30 secs

After completion of block write request, MMC block driver waits for the
card to come out of the programming state. If card doesn't come out of
the programming state in 10 mins, it would be considered as error
condition and card would reinitialized. But this 10 mins is just too huge
and if card is continuously stuck in programming state for 10 mins,
mmcqd thread would take increase the CPU load significantly as we are
continuously polling for the card status (by sending status commands).

This patch reduces this timeout from 10 mins to 30 secs which is quite
reasonable for all well-behaved cards.

Change-Id: I4e8eaf29c836a81419220f312ee867b0dd5cccc7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: block: Update error handling if block data is not available

While handling IOCTL command, if the block is not available then in the
bail-out path it is trying to free the block data which will be executed
against NULL pointer.

So, don't attempt to free the block data and only release the IOCTL
data.

CRs-Fixed: 476581
Change-Id: Icba46c861258d2d84b1fae5a2f5fca52ffe54255
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: core: Allow changing bus frequency for SD/eMMC cards in runtime

Currently, bus frequency is set during the card initialization and
never changed until a new card is inserted. In some low power use
cases, scaling the clock frequencies while the card is in transfer
state would allow power savings. This change allows bus frequency
to be changed after the card initialization.

Change-Id: Iac064221199f69d162d91f5311becd735c15700a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add load based clock scaling support

The SD3.0/eMMC4.5/SDIO3.0 cards can support clock rates upto
200MHz (SDR104 or HS200 bus speed modes). For some workloads
like video playback it isn't necessary for these cards to run
at such high speed. Running at lower frequency, say 50MHz, in
such cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has huge power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.

Provide an ondemand clock scaling support similar to cpufreq
ondemand governor having two thresholds, up_threshold and
down_threshold to decide whether to increase the frequency or
scale it down respectively. The sampling interval is in the
order of milliseconds and should be chosen by host drivers that
enable MMC_CAP2_CLK_SCALE capability to take advantage of clock
scaling. The sampling interval mainly depends on the the clock
switching delays and hence a host driver decision. If sampling
interval is too low frequent switching of frequencies can lead
to high power consumption and if sampling interval is too high,
the clock scaling logic would take long time to realize that the
underlying hardware (controller and card) is busy and scale up
the clocks.

Change-Id: I22a5054beec41b0b66b3bf030ddfcf284de448b3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add sysfs entries for dynamic control of clock scaling

Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".

Change-Id: I4753c75c3b3eeea91e93bceba7af2535b793612e
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: claim mmc host while enabling clock scaling from userspace

A race condition can occur while enabling clock scaling and removal
of the card. If the card is removed just after the host->card check
is successful then there could be NULL pointer dereference later.
Claim mmc host before card availability check to avoid this race
condition.

Change-Id: I6339cad5857732ec6b66280940cd6b8b7ed30614
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: run clock scaling only in valid card state

Clock scaling requires the tuning and if the tuning command
is sent to the card in invalid state, tuning procedure will
fail.

With urgent request mechanism implemented, there is a chance
that clock scaling invoked when card is not in a proper state
to receive the tuning command.

This change checks the card state (by sending the status command)
before invoking the clock scaling request.

Change-Id: Icb71a8e74a9afdc70380a5901cd3d28931959e9c
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: Log MMC clock frequency transitions

Use kernel's ftrace support to capture MMC clock frequency
transitions which can be useful for debugging issues related
to power consumption.

Usage:
mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_clk/enable
cat /sys/kernel/debug/tracing/trace_pipe

Change-Id: I25c4ee39dcbe30e7665902a9f723a5a421b55ca3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add support for notifying host driver while scaling clocks

Host drivers can participate in clock scaling by registering
->notify_load host operation, which allows host driver to carry out
platform specific operations for further power savings or increasing
throughput based on whether load is LOW or HIGH respectively. This
can be applicable to non-ultra high speed cards as well so remove
the check for ultra high speed cards to initialize clock scaling.

Change-Id: Icaab9520135e384f5470db68b2f25c5cdce5663a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: msm_sdcc: Add support for dynamic bus clock vote

SDCC controller on some targets like 8660, 8960, 8064 and their
variants connects with Daytona Fabric (DFAB). To achieve max.
possible performance the DFAB clock is voted to 64MHz at the
cost of some power consumption. Since we now have dynamic clock
scaling for SD/eMMC clock we can also scale the DFAB clock
accordingly without impact on performance but have some power
savings in low throughput cases.

Change-Id: Ic26541d6845b65803aa813d672ccabdfc4658d9c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: msm_sdcc: fix a type mismatch in msmsdccc_config_dma()

msmsdcc_prep_xfer() function returns a signed integer value but
caller function msmsdcc_config_dma() is storing this value in an unsigned
integer variable which is obviously not the correct thing to do.

CRs-Fixed: 476578
Change-Id: I39159e2f4f73c7f54de359cbe4faba5e902915ff
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: Enable clock scaling capability

Enable capability, MMC_CAP2_CLK_SCALE to allow mmc core
to scale the clocks at runtime based on load on card.

Clock scaling in MSM platforms also allow voltage scaling between
NOMINAL and SVS levels, thus allowing additional power savings.

Change-Id: Id1995ffea7a6c06a2e8b29b43da70894f35f6c0b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: remove the polling for BKOPS completion

The original intention of polling for BKOPS completion was to give
the card enough time to perform the BKOPS before it is runtime suspended.
But as the BKOPS completion polling was happening in a different
context, it may race with card runtime/platform suspend which is quite
difficult to fix. So instead of BKOPS polling, let the runtime suspend
get deferred if the BKOPS is running on the card. Also if BKOPS is running
when platform suspend is triggered, stop the BKOPS before suspending the
card.

CRs-Fixed: 489523
Change-Id: I21e524dc2da37c4985c210abfaca00a28049c651
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
ASoC: msm: Change QOS value for low latency path

There were variations in the time taken to
return from each write. This was due
to the delay in switching in and out of
power collapse. To manage this set QOS
value to 1ms so that the core has enough
time to wake up from power collapse

Signed-off-by: Alexy Joseph <alexyj@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
Revert "ASoC: msm: Decrease the playback period size of PCM driver"

This reverts commit b0580099ac7d5e735fb42946612a499bf196cda1.

Change-Id: I487797334cf75978daa3c536ff92de8a54b1f7fb
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
ASoC: msm: Flexible period size for pcm playback

PCM driver was configured for fixed buffer
size on the playback path. With this, varying
the buffer sizes on the playback path was not
possible. To fix this, support for flexible
period sizes is added by setting different
values for min and max buffer sizes

Change-Id: I7f69db4940f67e5e3a795101af1b1682afbdb530
Signed-off-by: Alexy Joseph <alexyj@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
msm: kgsl: Use the kmalloc/vmalloc trick for the sharedmem page array

It was previously assumed that most GPU memory allocations would be
small enough to allow us to fit the array of page pointers into one
or two pages allocated via kmalloc.  Recent reports have proven
those assumptions to be wrong - allocations on the order of 32MB will
end up trying to get 8 pages from kmalloc and 8 contiguous pages
on a busy system are a rare beast indeed.

So use the usual kmalloc/vmalloc trick instead - use kmalloc for the
page array when we can and vmalloc if we can't.

CRs-fixed: 513469
Change-Id: Ic0dedbad0a5b14abe6a8bd73342b3e68faa8c8b7
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: send ringbuffer NOP padding with the next command

If there isn't enough room at the bottom of the ringbuffer for a
whole command, the remaining space is filled with NOPs and
the command starts again at the top of the ringbuffer, the write
pointer of the ringbuffer shall update accordingly; the existing
implementation sends out in-complete NOP command which may potentially
cause GPU hang. This fix submits the NOP command along with the next
command instead of submitting them separately to have GPU read both
commands in the same fetch.

Change-Id: Ia3c9933c11d986c6743d8026b809bbcb1eaf54bf
Signed-off-by: Zhong Liu <zhongl@codeaurora.org>