msm_serial_hs: Improve UART Shutdown path

For uart port close operation, serial core calls msm_hs_stop_rx_locked()
which sends discard flush request to ADM driver after changing rx.flush
state machine from FLUSH_NONE to FLUSH_STOP value. Next serial core
calls msm_hs_shutdown()and it waits for discard flush completion with
rx.flush state machine to be set as FLUSH_SHUTDOWN to complete uart
port close operation. With this approach, transfer termination is not
known by UART Core which may still allow UART core to make CRCI request
with ADM Core if new data is being received from remote uart. Hence
invoke Force RxStale from msm_hs_stop_rx_locked() which informs UART
core to terminate current Rx transfer and do not make any new CRCI
request with ADM core for any new incoming data. On receiving RxStale
interrupt, it sends discard flush request to ADM driver to terminate
transfer with ADM hardware.

This new programming sequence is required to get both UART and ADM
hardwares in-sync for termination of transfer.

CRs-Fixed: 475230
Change-Id: I802a456294d4fd2fa51a5f4e918a4f4f22bc5ee3
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: Fixing issue during UART shutdown

During UART port close in msm_hs_shutdown(), flag is_shutdown is
set as true and then UART interrupt is disabled and UART irq line
is freed. This is causing corner case in which even if uart shutdown
is in progress, UART interrupt can come as the UART interrupt is not
disabled and UART irq line not freed at this point. As flag
is_shutdown is set as true in msm_hs_shutdown() and then if UART
interrupt comes, it is hitting BUG_ON in UART Interrupt handler
msm_hs_isr(). To fix this issue, disable the UART irq and free
the UART irq line at the beginning of the msm_hs_shutdown() and
then set the flag is_shutdown.

In msm_hs_shutdown, disabling UART Interrupt and setting flag
is_shutdown is done with uart spinlock acquired. There is a
possibility that on other core, msm_hs_isr() might need to wait
for the same uart spinlock and later when msm_hs_isr() is executed
BUG_ON is hit. As by this time all UART Interrupt is disabled,
hence removing the BUG_ON and instead keep prints to notify the
same.

CRs-Fixed: 487945
Change-Id: I0a19b8f3098f1c9215935ca7fa9d9e5895c44a8c
Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>
msm_serial_hs: Use RFR GPIO to communicate remote uart

CTS and RFR GPIOs are used for hardware flow control between
two uarts. RFR GPIO provides current status of uart receiver
to remote uart and based on this remote uart sends data.
Hence use this functionality to prevent remote uart to send
data when port is being opened, baud rate change operation
is in progress and port is being closed.

This change also set UART_DM_MR2 (Bit: 8 and 9) before
configuring connected UART GPIOs to prevent RX_BREAK character
and any character having PARTIY or FRAMING error which can be
generated due to configuration of those GPIOs. Allows those
character once port is opened successfuly.

This change also zeroed uart rx software buffer which would
help to see how many bytes copied by ADM from received data
with UART RX FIFO to this memory. This would be useful if
there is any Rx Stall issue is seen.

CRs-Fixed: 495564
Change-Id: I69382994356073c4c86f205015503c935ad09e8d
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: Cleanup code to configure/unconfigure UART GPIOs

With current approach UART GPIOs are configure/unconfigure from
board files by using GPIOLib APIs. UART driver uses gpio_config
pdata based function pointer to call per uart device related API
from board file for the same. Hence correct this approach and
pass only UART GPIOs numbers to UART driver using pdata and
configure/unconfigure those GPIOs using GPIOLib APIs once UART
port is being opened and closed respectively.

CRs-Fixed: 460961
Change-Id: I4bb007b2b476525cb50dd2eb5788c735aae0e32d
Signed-off-by: Mayank Rana <mrana@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: Fix some driver hangs when dealing with broken devices

There are infinite loops in the mmc code that can be caused by bad
hardware.  The code will loop forever if the device never comes back
from program mode, R1_STATE_PRG, and it is not ready for data,
R1_READY_FOR_DATA.

A long timeout is added to prevent the code from looping forever.
The timeout will occur if the device never comes back from program
state or the device never becomes ready for data.

It's not clear whether the timeout will do more than log a pr_err()
and then start a fresh hang all over again.  We may need to extend
this patch later to perform some kind of reset of the device (is
that possible?) or rejection of new I/O to the device.

Change-Id: I1f3e5fddffb5134743fbfbcdef5e97803fd25fc6
Signed-off-by: Trey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>

Conflicts:
	drivers/mmc/core/core.c
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: 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: msm_sdcc: Reset SDCC controller if check for Tx/Rx active fails

Reset SDCC controller if the check for TX/RX ACTIVE bit fails while
carrying out DPSM reset after the end of current transaction
instead of taking the entire system down by doing BUG().

CRs-Fixed: 423356
Change-Id: I9e2e945eb9a31d12e0a435df29a8215ae634724b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 0a29588be6d3d6bd9122191e7e850c687bb1b166)

Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: msm_sdcc: fix data timeout calculation for DDR bus speed mode

When card operates in DDR (Double Data Rate) bus speed mode,
most of the HW logic of SDCC controller needs to have clock
frequency that is twice the clock frequency going out to card.
For example, if a card operates at 50MHz clock in DDR mode then
internally SDCC controller logic will operate at a clock of 100MHz.

But SDCC controller's data timeout logic works on the clock rate
that actually goes to card. So this change calculates the data
timeout value based on the clock frequency that goes to card rather
than SDCC controller's clock frequency.

CRs-Fixed: 450675
Change-Id: Icd8b648eae0ad4efad2598749bed7b0bd65c65c9
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>