fix possible revert going from mfx to google.

Change-Id: Ica27ee99198f5e021e7e27e19387a67b432247e0
cpufreq: ondemand: Use the input handler when SEC_DVFS_BOOSTER isn't enabled

Change-Id: I8515fc6f258c6c2601c189291ee75d10fc623db2
drivers: cpufreq: Send a uevent when governor changes

 * Useful so userspace tools can reconfigure.

Change-Id: Ib423910b8b9ac791ebe81a75bf399f58272f64f2
cpufreq: Retain only online cpus in managed_policy->cpus

cpufreq's handling of cpu online event can incorrectly initialize
managed_policy->cpus to include offline cpus. This causes cpufreq
governors to include offline cpus in their idle time computation, which
causes frequency to shoot up beyond normal levels (on systems where 2 or
more cpus need to be synchronized wrt frequency change).

This frequency shootup was not seen prior to commit 21111be8 which
changed idle time accounting for offline cpus. Prior to commit 21111be8,
idle time statistics for offline cpus would include their offline time
as well. Post commit 21111be8, offline time is not included in a cpu's
idle time statistics.

As a result, ondemand (or other cpufreq) governors would see unchanged
idle time for offline cpus, causing them to interpret those (offline)
cpus as 100% busy, which is wrong.

This patch fixes the issue by modifying cpufreq's hotplug handling to
retain only online cpus in managed_policy->cpus field. cpufreq governors
would then skip such offline cpus from idle time calculations.

Change-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
msm: mdp: Revert MDP Port split changes

Revert MDP changes to avoid bus overflow
seen in camera usecases.

Change-Id: I1c687750bd22c8f64ab28a500562cbfbcb6a6048
Signed-off-by: Kiran Kumar H N <hurlisal@codeaurora.org>
Signed-off-by: Praveen Ac <praveenac@codeaurora.org>
msm_fb: display: get mipi frame rate from panel file

If frame rate value for mipi video panel is coded in panel file it can
be directly used to avoid calculation error.

Change-Id: I6ad86226c81da4bcf36196385f9ff4bea0bef0ca
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: add mdp clock control to histogram enable/disable

Add mdp clock control to histogram enable and disable block to
prevent system from crashing when accessing register with mdp
clocks off.

Change-Id: Ide808b332b5456f3fc639fcbb0d03d5cad0e387f
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_serial_hs: Rx discard flush timeout

While configuring the uart buadrate using set_termios
function, timeout is occuring for rx discard flush
operation. This is due to the driver is waiting for
less time for the DMA call back to occur after programing
the DMA register with the discard flush command.

To overcome this issue increased the timeout to 300ms.

Change-Id: I60db1f9eea8bb59fab4024e5f5dfcbcdcde253bb
Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
msm: rotator: Extend fast YUV invalid checker for 2-pass

For 2-pass mode, we need to check for the fast YUV constraints
separately for both the 1st and 2nd pass. Make change to extend
the fast YUV invalid checker to 2-pass mode.

CRs-fixed: 504007
Change-Id: I7ef96ff29423fbd5cc454e8fd125b4bb1a9d59e1
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
The names to the functions that acquire and release a console lock
have changed, but kernel/power/consoleearlysuspend.c still uses the old
names. See http://goo.gl/pxgOK

Change-Id: Ie972e51e1acfcec3a12c8fdc86b9287104346a99
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>