CHROMIUM: mmc: shdci: Prevent CPU in deeper Cx states when data transferring

The patch is ported from Intel Android source tree.

On Baytrail SoC, sometimes block data DMA transfer would stop in the middle
and controller stops generating interrupts. The issue can be resolved by
preventing CPU from entering lower than Cx states  during eMMC data
transferring.

Changes to Android implementation:

1. Change to ACPI implementation from PCI;
2. Android has a C2 state with latency of 20us. This state is not supported
on Chrome. Thus we use C1 instead.
3. Moved QoS to runtime PM and other cleanup as suggested by Andrew Bresticker

Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Reviewed-by: Gao, Yunpeng <yunpeng.gao@intel.com>

BUG=chrome-os-partner:29021
TEST=Manual:  verified eMMC normal operation on Rambi.

Original-Change-Id: I4b8dd2a065f7d5a26c4cc990e597f49ddc5bb510
Originally-signed-off-by: Wenkai Du <wenkai.du@intel.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/201790
Originally-reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit cfcada3455e5b485c3eaf4ccbbbab5446ff2b1cd)

Change-Id: I43bf2998114bac63c6277a77d4e50ab9bb013c99
Reviewed-on: https://chromium-review.googlesource.com/203483
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
CHROMIUM: input: standardize elants_i2c sysfs

Currently the elants_i2c driver looks for it's new FW at
/lib/firmware/ElanFW.fw, but all our other touch drivers looks for a
file of the form /lib/firmware/$DRIVERNAME.bin, so this patch
changes the name to elants_i2c.bin for consistency and since that's
what the FW updating scripts expect.

The autoupdater also needs to have a hw_version sysfs entry where it can
read a number that identifies which device it's updating so it knows it
has the right one.  This patch adds that.

Additionally, the sysfs entry to update the FW used to be accessed by
reading from it, but all of our others are triggered by writing to it,
so this patch simple flips the functionality for the fw_update sysfs
entry when it moves them out of their nested group.

BUG=chrome-os-partner:29412
TEST=manual testing

Change-Id: I7a1286f00f9114b769df534fac23cd8edd615e47
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202576
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
(cherry picked from commit 213d2a6b64e310894172cc34a9d48056bd2c203f)
Reviewed-on: https://chromium-review.googlesource.com/203647
CHROMIUM: video: tegra: Filter out CEA pixel repeat modes

Filter out HDMI CEA modes that does pixel repeat.

BUG=chrome-os-partner:29382
TEST=Tested on a projector that defines these mode in EDID and
see that it does not appear with xrandr.

Change-Id: I6398e5c01ef25a1c2d4d04f6daee5e92af2da81a
Signed-off-by: David Ung <davidu@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/202553
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 547287335a81ba459e0a0c451eb54d4aaadfc902)
Reviewed-on: https://chromium-review.googlesource.com/203846
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: video: tegra: hdcp: use cancel_delayed_work_sync()

- nvhdcp driver uses flush_workqueue()
- instead make use of cancel_delayed_work_sync() since
  work scheduled is delayed work

BUG=chrome-os-partner:28497
TEST=System boots/HDCP works/HDMI resume time decreases 1s

Change-Id: I9d06487760f5ff2f9580c91cf03a544b65dcd2bf
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/202084
Tested-by: Peer Chen <pchen@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: David Ung <davidu@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/203844
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ALSA: hda_tegra - powergate/unpowergate SOR partition

We've observed that HDA commands would timeout when the display(s) are
disabled on Tegra, such as in the suspend/resume paths.  It appears
that the HDA block depends specifcally on the SOR partition of the SoC
being unpowergated in order to operate normally, so add calls to explicitly
powergate/unpowergate the SOR partition when necessary.

BUG=chrome-os-partner:28497
TEST=No more azx_get_response timeout spew, suspsend entry time down
to ~200ms.  HDMI/HDA audio still work after suspend/resume.

Change-Id: Ib6001dd4b722d25b0770d6ac6aef59ddf59ebfbc
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202982
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/203845
UPSTREAM: mmc: core: Stop bkops for eMMC only from mmc suspend

Move mmc suspend specific operations to be executed from the .suspend
callback in the mmc bus_ops. This simplifies the mmc_suspend_host
function which is supposed to handle nothing but common suspend tasks.

Since eMMC can be considered non-removable there are no need to check
for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 39b9431b0f371294dd2d1a492cf77f2f17390a1f)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Id3a110df4f6c2e83ef0bb1ae3fba4c1bc877ec4f
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202366
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203822
UPSTREAM: mmc: core: Add bus_ops for runtime pm callbacks

SDIO is the only protocol that uses runtime pm for the card device
right now. To provide the option for sd and mmc to use runtime pm as
well the bus_ops callback are extended with two new functions. One for
runtime_suspend and one for runtime_resume.

This patch will also implement the callbacks for SDIO to make sure
existing functionality is maintained. It also prepares to move
away from using the mmc_power_restore_host API, since it is not
needed when using runtime PM.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 12d01d0b813b93e7bde1b5f468b5c85aa8b33590)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I85f87981a63184551070d569eecc051109fea968
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202367
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203823
UPSTREAM: mmc: block: Enable runtime pm for mmc blkdevice

Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to be configurable somehow since it needs to be trimmed depending
on the power save algorithm.

For SD-combo cards, we are still leaving the enablement of runtime PM
to the SDIO init sequence since it depends on the capabilities of the
SDIO func driver.

Moreover, when the blk device is being suspended, we make sure the device
will be runtime resumed. The reason for doing this is that we want the
host suspend sequence to be unaware of any runtime power save operations
done for the card in this phase. Thus it can just handle the suspend as
the card is fully powered from a runtime perspective.

Finally, this patch prepares to make it possible to move BKOPS handling
into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
accomplished.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit e94cfef698aae6b209d8918dd319312e4b02118d)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I319d531201aa79ac8a616d9a9f92790f661e5826
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202368
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203824
UPSTREAM: mmc: core: Support aggressive power management for (e)MMC/SD

Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.

Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latency. This latency
is card-specific, experiments has shown in general that SD-cards
has quite poor initialization time, around 300ms-1100ms. eMMC is
not surprisingly far better but still a couple of hundreds of ms
has been observed.

Except for the request latency, it is important to know that
suspending the card will also prevent the card from executing
internal house-keeping operations in idle mode. This could mean
degradation in performance.

To use this feature make sure the request inactivity timeout is
chosen carefully. This has not been done as a part of this patch.

Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
by setting CONFIG_MMC_UNSAFE_RESUME.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit c4d770d72492df510077b277f21ac5f0dad9e5eb)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Ib0c62a8816eb89ed6e2fedb2c53926355b81f5c2
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202369
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203825
UPSTREAM: mmc: core: Restructure and simplify code for mmc sleep|awake

The mmc_card_sleep|awake APIs are not being used since the support is
already properly encapsulated within the suspend sequence. Sleep|awake
command is also specific for eMMC.

We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
move the code into the mmc specific core instead. This also includes
the mmc ops function, mmc_sleepawake. All releated functions have then
become static and we have got far less code to maintain.

Additionally this patch also simplifies the code from mmc_sleepawake,
since it is only used to put the card to sleep and not awake.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 07a682160866e302d696f5c76d74024d575fb79d)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Ie5df69ff67e191ef83657dd8f3f0ae4e9cfad79f
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202410
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203826
UPSTREAM: mmc: core: Remove unnecessary check for the remove callback

For every bus_ops type the .remove callback always exist, thus there
are no need to check the existence of it, before we decide to call it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 58a8a4a1a5da4694a3a069de5e0a8c15995e7b5f)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I1c29278ed0ff8d75f09d79ff7d435a5cd4ebece3
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202411
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203827
UPSTREAM: mmc: core: Validate suspend prerequisites for SDIO at SUSPEND_PREPARE

This patch moves the validation for all the suspend prerequisites to be
done at SUSPEND_PREPARE notification. Previously in the SDIO case parts
of the validation was done from mmc_suspend_host.

This patch invents a new pre_suspend bus_ops callback and implements it
for SDIO. Returning an error code from it, will mean at SUSPEND_PREPARE
notification, the card will be removed before proceeding with the
suspend sequence.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 810caddba42a54fe5db4e2664757a9a334ba359c)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Ic71281508f57314966adb9a3a51fb3e761d16c4f
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202412
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203828
UPSTREAM: mmc: core: Push common suspend|resume code into each bus_ops

By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.

Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 74590263384e5d4601de7f0ee2790477578829ea)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I90269b90f2846dc1934fc5fa92003def258c659d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202413
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203829
UPSTREAM: mmc: core: Initiate suspend|resume from mmc bus instead of mmc host

The host should be responsible to suspend|resume the host and not the
card. This patch changes this behaviour, by moving the responsiblity
to the mmc bus instead which already holds the card device.

The exported functions mmc_suspend|resume_host are now to be considered
as depcrecated. Once all host drivers moves away from using them, we
can remove them. As of now, a successful error code is always returned.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 986892ca78eeddd9d6b629050fea432979ddd321)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I948e8dcedd0ad692bb5b5526c68dec15fe7a0331
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202414
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203830
UPSTREAM: mmc: core: Handle card shutdown from mmc_bus

Considering shutdown of the card, the responsibility to initate this
sequence shall be driven from the mmc_bus.

This patch enables the mmc_bus to handle this sequence properly. A new
.shutdown callback is added in the mmc_driver struct which is used to
shutdown the blk device.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 7628774851751e55362ec7d9d57c9334e656a655)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Iecf83ea98ef8aec239117cefc8fc420be2f4b102
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202415
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203831
UPSTREAM: mmc: core: Extend shutdown sequence to handle bus operations

By adding an optional .shutdown callback to the bus_ops struct we
provide the possibility to let each bus type handle it's shutdown
requirements.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 6b086bde71243e2596f9d8e3c060119b84110d33)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I525d2cfea3c4884c318af7624773b51b5f13e245
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202416
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203832
UPSTREAM: mmc: core: Add shutdown callback for SD bus_ops

For the SD .shutdown callback we re-use the SD suspend function since
it performs the relevant actions.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 5992e78697484d8f58b749f87a06f89f4ba40a47)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I4bb719fe879832ad0a4969653d20b9c4b910af0e
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202417
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203833
UPSTREAM: mmc: core: Handle both poweroff notification types for eMMC

Depending on the context of the operation while powering down the card,
either POWER_OFF_NOTIFY_SHORT or POWER_OFF_NOTIFY_LONG will be used. In
suspend context a short timeout is preferred while a long timeout would
be acceptable in a shutdown/hibernation context.

We add a new parameter to the mmc_suspend function so we can provide an
indication of what notification type to use.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 03d071fc8de4ad9b6e7374720ae81b7e928f6075)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I57dbce769180188458b728ffc1af553ff551f4e6
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202418
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203834
UPSTREAM: mmc: core: Add shutdown callback for (e)MMC bus_ops

The shutdown sequence of an (e)MMC is very similar to a suspend. We
re-use the suspend function and tell it we are not in suspend context.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 486fdbbc1483504cde0314e33e47bc32e9d38186)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: I0260df456012952d23cc0dd4dab52a4c6fcf83a6
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202419
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203835
UPSTREAM: mmc: core: Enable power_off_notify for eMMC shutdown sequence

In suspend mode it is important to save power. If the host is able to
cut buth vcc and vccq, the MMC_CAP2_POWEROFF_NOTIFY shall be set. It
will mean the card will be completely powered down at suspend and the
power off notification cmd will be sent prior power down.

It seems common not being able to cut both vcc and vccq for a host. In
this situation we issue the sleep cmd in favor of the power off
notification cmd, to save more power.

While maintainng the above policy, we also want to make use of the
power off notification in the shutdown sequence, even in the case were
the host has not set MMC_CAP2_POWEROFF_NOTIFY, since we know vcc and
vccq will regardless be cut.

We accomplish this by always enabling the power off notification byte
in the EXT_CSD and issue the power off notification when either
MMC_CAP2_POWEROFF_NOTIFY is set or we are executing a shutdown.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 43235679341510f58a86eb75ab23cbae4bdc59b8)

BUG=chrome-os-partner:29136
TEST=Continuously cold reboot Blaze; no eMMC corruption observed.

Change-Id: Ib970fdf3aa55468df96446762fc3eafcde7da2f5
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202420
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203836