UPSTREAM: Bluetooth: btmrvl: support Marvell Bluetooth device SD8897

The register offsets have been changed in SD8897 and newer chips.
Define a new btmrvl_sdio_card_reg map for SD88xx.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit 22f2efed35e02a7c0b1ec73cfe790b1e3d207f4b)

BUG=None
TEST=Can ping bluetooth over pit/pi rev9 using hciconfig
Change-Id: I08b9caf37b7aa58c1679dda93ae19da65e36d6b1
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180913
exynos5420: devfreq: Disable 111 and 83 MHz levels for 1920x1080

Disables 83, 111MHz levels of devfreq for 1080p display
which comes with both of POP and SCP version of exynos5420.
This is required as the higher resolution demands higher
bus bandwidth.
This co-exists with the SCP code and applies only in case of 1080p or more.

BUG=chrome-os-partner:24554
TEST=Run Video, WebGL, V8 and see no stability issues.
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>

Change-Id: I9818bfc64b39a8fb249b272ea464adebd4167ff1
Reviewed-on: https://chromium-review.googlesource.com/180620
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Wonjoon Lee <woojoo.lee@samsung.com>
CHROMIUM: atmel_mxt_ts - adding prefix "atmel_mxt_ts" when logging

This makes the logging of atmel_mxt_ts driver consistent in prefix
message.

BUG=chromium:329814
TEST=checking demsg that all the atmel device logging has prefix
     "atmel_mxt_ts".

Change-Id: I14c29090f60097a8e296eae6cfa0b5263728e30d
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180985
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
drm/exynos: exclude modes from adjustment comparison

The mode adjustment logic is checking whether a "native" mode with the same
resolution as adjusted mode already exists. But it can be an another
adjusted mode (possibly with different refresh rate) or a mode with
unsupported pixel clock. This change introduces a private flag
EXYNOS_MODE_ADJUSTED which is set when the mode is adjusted and skips the
comparison with adjusted modes and also checks whether the comparison target
mode is valid using check_mode(). This solves problem with two scenarios.
One, already encountered is when 1024x768@75 is adjusted to 1024x720@75 and
prevents 1024x768@60 from also being adjusted to 1024x720@60 with both of
them being pruned later. Second is where "native" mode with unsupported
pixel clock could prevent of adjustment of another mode to the same
resolution.

BUG=chromium:331423
TEST=connect Daisy to HP LP2465 monitor. 1024x720 mode should be available.

Change-Id: I8e3fcab58ebe991f556cefe56e228399cbe793e5
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181420
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>