Revert "Revert "mako: msm: board: enable HS200 bus speed mode support""

This reverts commit e039dcb2ebcf3afcfc133caefb60a6836f437a63.
msm: camera: nullify pointers after kfree and fix the memory leaks

nullify pointers after kfree and remove unnecessary kmallocs

Also fix the memory leaks. should free the memory after v4l2_event_dequeue()
even if there are some errors in copy_to/from_user(). Because entry was
already removed from its own list after v4l2_event_dequeue().

Change-Id: I733538c2fd76a6b77cfd8d6b780caebcb3fd70a8
v4l2: fix the memory leak

commit 9985432a82e6700cf9759f413ecaecbf617318cb

check for fh->dev being NULL before kzalloc to fix the memory leak

Change-Id: I3377ef39297f63c692aa5451d2bdbe327e2df18a
mmc: msm_sdcc: fix race conditions in runtime PM

commit 386ad800716b6660d40c677b57ee4bf8e4430329 msm-3.4

What is the race condition? (NOTE: RPM stands for Runtime Power Management)

1. SDCC is in RPM_SUSPENEDED state and SDCC platform suspend gets
   triggered and then system goes into suspend.
2. During platform resume, SDCC platform resume is triggered
   which blindly sets the pending_resume flag in SDCC host structure.
3. If new MMC transfer request comes then MMC block driver calls
   mmc_claim_host() which internally calls msmsdcc_enable().
4. msmsdcc_enable() checks for following 3 conditions to be true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false
   But as SDCC state is RPM_SUSPENDED, 3rd condition is not be satisfied
   so msmsdcc_enable() don't clear the host->pending_resume flag and simply
   calls pm_runtime_get_sync() to resume the SDCC. Once SDCC is resumed,
   host->sdcc_suspended = false, runtime_status = RPM_ACTIVE but
   host->pending_resume is still set.
5. Now after RPM idle timeout, SDCC runtime suspend gets triggered which
   calls SDCC driver's runtime suspend callback (msmsdcc_runtime_suspend).
   Note that before executing the RPM suspend calllback, SDCC RPM status
   is set to RPM_SUSPENDING.
6. As SDCC driver's runtime suspend callback gets executed, it sets the
   host->sdcc_suspended to true. But now before the RPM framework
   sets the SDCC RPM status to RPM_SUSPENDED, on other active CPU core,
   new MMC transfer reques comes in which would first call msmsdcc_enable()
   and all of the 3 conditions below is true:
	1. host->sdcc_suspended == true
	2. host->pending_resume == true
	3. pm_runtime_suspended() == false (RPM status is RPM_SUSPENDING)

   As these conditions are satisfied, msmsdcc_enable() does not call
   pm_runtime_get_sync(), instead just calls pm_runtime_get_noresume() and
   msmsdcc_runtime_resume(). This means even after execution of
   msmsdcc_enable(), SDCC RPM status is either RPM_SUSPENDING or
   RPM_SUSPENDED.
7. RPM suspend framework on 1st core sets the SDCC RPM status to
   RPM_SUSPENDED once SDCC runtime suspend callback returns.
8. Now once MMC transfer request is completed on other core, it will call
   msmsdcc_disable(). This function calls pm_runtime_put_sync() which
   returns -EAGAIN error as RPM status is already RPM_SUSPENED.
   This error gets returned to MMC layer so MMC layer thinks that
   SDCC is still enabled and skips call to msmsdcc_enable() until
   msmsdcc_disable() succeeds.
8. Note when msmsdcc_disable() returned error, RPM usage_counter was set to
   0 so next call to msmsdcc_disable() decrements RPM usage_counter to -1
   (remember msmsdcc_enable() was skipped).
9. Now new MMC request comes in and it will first call msmsdcc_enable()
   which calls pm_runtime_get_sync() and it sets the usage_counter to 0
   and blindly resumes the SDCC as it was already suspended. After this
   RPM status will be RPM_ACTIVE.
10. Once MMC request is processed, it will call smsdcc_disable() which
    calls pm_runtime_put_sync() and it decrements RPM usage counter to -1
    and skips scheduling runtime suspend callback as RPM usage counter
    is not 0. RPM status remains in RPM_ACTIVE.
11. Now onwards for every new MMC transfer requests, 9 and 10 repeats and
    SDCC always stays in RPM_ACTIVE state forever.

How is this race condition fixed?

Above race is created because host->pending_resume is remaining sticky.
Following changes are done to ensure that pending_resume gets set and
cleared at appropriate places:
1. In SDCC platform resume callback, set the host->pending_resume flag
   only if RPM status is RPM_ACTIVE.
2. Clear the pending_resume flag once msmsdcc_runtime_resume() is
   completed.
3. In msmsdcc_enable() function, if pending_resume flag is set skip calling
   pm_runtime_get_sync() instead directly call msmsdcc_runtime_resume()
   because RPM status is RPM_ACTIVE.

In addition, this patch adds WARN() messages in case of failures in
msmsdcc_enable() and msmsdcc_disable() functions to capture more details
in error conditions.

CRs-Fixed: 373338
Change-Id: I50d1bd63480c668dd2b83f01567f912661f0c606
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
msm_fb: display: Enable scaling bit while setting x-flip bit

To enable left-right flip x-scaling bit should be set for
MDP 4.2 and above versions. This fixes the issue when RGB layer
pipes are not properly rotated.

Change-Id: I0afae4aecde39ce3ac4dcbefc0bda93510e7d18a
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
mako: Adjust .drv value to 10mA

Fixes ULP timeout issues that causes USB enumeration failures.

b/7438555
mmc: msm_sdcc: set IO_PAD_PWR_SWITCH bit based on IO voltage level

SDCC4 controller has IO_PAD_PWR_SWITCH control bit in MCI_CLK register.
Driver should set this bit to 1 if the IO voltage level is within
low voltage range (1.7v - 1.9v) else clear it.

But driver sets this bit to 1 only if the MMC core layer initiates
the voltage switch sequence. So if voltage switch sequence is not
initiated (which is the case with non UHS-I cards) then even if
the IO voltage level is within low voltage range, IO_PAD_PWR_SWITCH
bit remains cleared.

This change checks the IO voltage level and based on that sets the
IO_PAD_PWR_SWITCH bit.

CRs-Fixed: 386445
Change-Id: Id0648b0f87ea9bcc942e855e30da810e0fe5ebf5
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: add support for AUTO_CMD19 control

SDR104 (supported by SD3.0 spec compliant SD cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning SD3.0 specification has added CMD19.

During card initialization, driver uses these tuning commands to search
for optimal sampling point and then programs the DLL HW with this optimal
sampling point.

In addition, our SDCC controller's DLL HW has a mechansim of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.

Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by ~1 MB/s. SD spec does
not mandate to send these commands before every read operations.

This change keeps AUTO_CMD19 disabled by default but provides sysfs
attribute to enable or disable AUTO_CMD19 as per need.

Change-Id: I9ef99a8dde9b9733ea99639cdab2b6714ac50d76
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: correct the hardware version number

SDCC core version number in MSM8974 is 0x2b and not 0x2d. Fixing this
and enabling hard reset supported in this newer sdcc core.

Change-Id: Ib216330af59f854ca7ebc8735b624f3005e1ba39
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: msm_sdcc: add support for AUTO_CMD21

Using HS200 (supported by eMMC 4.5 spec compliant cards) bus speed
mode requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz so that both host and card
are in sync. eMMC 4.5 spec has added CMD21 for this tuning mechanism.

During card initialization, driver uses the tuning command to search
for an optimal sampling point and then programs the DLL HW with this
optimal sampling point.

In addition, msm SDCC controller's DLL HW has a mechansim for data
tracking (CDR) which can be enabled during read transactions so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern command (CMD21) can be sent
automatically by HW (by using AUTO_CMD21 bit) before any RX transaction
to help CDR keep track of the correct sampling point.

Since sending CMD21 automatically before every read commands is an
overhead, reducing read performance by ~1 MB/s and eMMC spec does not
mandate sending the tuning command before every read operation, this
change adds support for AUTO_CMD21 (and keeps it disabled by default)
while providing a sysfs attribute to enable or disable AUTO_CMD21 as
needed.

Change-Id: I6e053db8878b273a407fa7caf8332eb064f351ce
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: msm_sdcc: Print data line status in case of errors

The MCI_TEST_INPUT register of the SDC controller depicts the status
of the data lines (if pulled down or not). Print its state in cases of
errors to isolate any device specific issues.

CRs-Fixed: 392889
Change-Id: I5d0dbcf3fb606e6a31ede58d7cc6b27f3fb80af7
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: msm_sdcc: data timeout errors are expected during HS200 tuning

HS200 bus speed mode requires DLL (Delay locked loop) HW block to be
tuned as clock rate (192 MHz) is greater than 100MHz.

While tuning the DLL block by sending CMD21 for different DLL phases,
it is quite possible that few CMD21 may fail with data CRC/timeout
errors as clock phase is not correct but these errors are not really
worth to be printed out as kernel messages. This change doesn't allow
these errors to be printed.

CRs-Fixed: 401743
Change-Id: I2b465a8e1d52458e8663d48791083be7fa4131b2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: set DDR timing mode before setting the clock rate

Setting DDR timing mode in controller before setting the clock
rate will make sure that card don't see the double clock rate
even for very small amount duration. Some eMMC cards seems to lock
up if they see clock frequency > 52MHz.

Change-Id: I8105cf52c07df01d66c3e15304ea10e2cbc498ff
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: msm_sdcc: Reset SPS BAM on error recovery

In the current soft reset sequence performed as part of
CMD/DATA error recovery we do the following:
1) Write 1 to DML_SW_RESET
2) Reset CPSM/DPSM by clearing MCI_CMD and MCI_DATA_CTL
or by writing to MCI_SW_RST_CONFIG.
3) Re-init DML
4) Reconfigure both consumer and producer BAM pipes.

The BAM pipe reset does not reset the sideband signals, since
only SDCC side is reset SDCC - BAM communication will go out
of sync and cause DML to be stuck without transferring data.
Hence reset BAM core every time SDCC is reset (which is on
error recovery).

Fix error handling for sps pipe or device reset.

Change-Id: I745e015c862fffa36a814cd007d2e82383668b3a
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
slub: fix a possible memory leak

Memory allocated by kstrdup should be freed,
when kmalloc(kmem_size, GFP_KERNEL) is failed.

Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
msm: display: Increase timeout value for fence waiting

In some benchmark use case, graphic engine is extremely
busy, need increase the fence waiting timeout value.

Signed-off-by: Ken Zhang <kenz@codeaurora.org>
camera: lm3559: change the message level

Change-Id: Ifef95ea3aaec3bd148358eb136bae52664d99079
lm3559: mark internal functions as static

Also comment out lm3559_led_shutdown, which isn't used.

Signed-off-by: Iliyan Malchev <malchev@google.com>
camera: lm3559: more cleanup

-- check error code of gpio_request() and return through ioctl
-- replace verbose logging with pr_debug
-- return -ENODEV if probe fails

Change-Id: Ic3d7d3cf766e9aa0b9eaca9b9e1d3d683439dd96
Signed-off-by: Iliyan Malchev <malchev@google.com>
msm: display: check get_unused_fd_flags return val

Not checking the error code, which might be negative, will cause us to wrongly
reference fdt[fd] by using the error code, causing kernel panic in fd_install.

Change-Id: I1f8e68e74bdbdd5b81bc3450f7d93b5cd96c9439
Signed-off-by: Iliyan Malchev <malchev@google.com>