BACKPORT 3.11: drm/i915: fix lane bandwidth capping for DP 1.2 sinks

DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
the driver will treat as an invalid value and use 1.62Gbps instead. Fix
this by capping to 2.7Gbps for sinks reporting a 5.4Gbps max bw.

Also add a warning for reserved values.

v2:
- allow only bw values explicitly listed in the DP standard (Daniel,
  Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit d4eead50eb206b875f54f66cc0f6ec7d54122c28)

BUG=chrome-os-partner:32070
TEST=No graphics autotest regressions

Change-Id: Ibe0209f7499c6580c1784c169097001c5c046f3b
Reviewed-on: https://chromium-review.googlesource.com/226245
Reviewed-by: Shan-fu Chiou <shan-fu.chiou@intel.com>
Reviewed-by: Jimmy Chen <jimmy.chen@intel.com>
Commit-Queue: Jimmy Chen <jimmy.chen@intel.com>
Tested-by: Jimmy Chen <jimmy.chen@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8
MALI: Wk 28_2014 DEV r5p0-14wk28 TX011 DDK

Early releases of the r5p0 versions of this part:
  TX011-SW-99002

BUG=chrome-os-partner:33334
TEST=Checked login page, general browsing and WebGL tests (including aquarium).
     Tested on Peach Pit and Daisy.

Signed-off-by: David Garbett <david.garbett@arm.com>
Change-Id: I67abc16252fac48b2600e266b529fdda36a45990
Reviewed-on: https://chromium-review.googlesource.com/224949
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: [media] s5p-jpeg: Reset the Codec before doing a soft reset

BUG=chrome-os-partner:33364
TEST=With all the patches in the series run the decoder JPEG test
on Snow board
	./test-jpeg -m 1 -f [input jpeg file] -o [output file]
		-v [decoder node]  -r [format] -s 1
	where:
		format should be a value from 0 to 9

Change-Id: I74e713b5aa59f81dbc65599f8f6005558f5b3630
Signed-off-by: Tony K Nadackal <tony.kn@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/228986
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
Commit-Queue: Abhilash Kesavan <a.kesavan@samsung.com>
Tested-by: Abhilash Kesavan <a.kesavan@samsung.com>
MALI: Wk 42_2014 DEV r5p0-14wk42 TX011 DDK

Early releases of the r5p0 versions of this part:
  TX011-SW-99002

BUG=chrome-os-partner:33334
TEST=Checked login page, general browsing and WebGL tests (including aquarium).
     Tested on Peach Pit and Daisy.

Signed-off-by: David Garbett <david.garbett@arm.com>
Change-Id: I7e4fa60a52f4f04dfa01e37e4493ec0f7c0330a0
Reviewed-on: https://chromium-review.googlesource.com/225620
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: skip validation checks in drm_setmaster_ioctl when drm_master_relax

This change updates drm_setmaster_ioctl to skip some validation
checks if the process is root and if drm_master_relax is set.   This is
used for the chromium console to forcibly take drm master if chromium
is hung and drm_master_relax has been set.

BUG=chromium:431788
TEST=test with freon console

Signed-off-by: David Sodman <dsodman@chromium.org>
Change-Id: Ia2af1bfd9bb9390aeda8cd5120daafde5f0f462f
Reviewed-on: https://chromium-review.googlesource.com/229682
UPSTREAM: drm/i915: Fix use-after-free in do_switch

So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.

With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).

Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:

i915_gem_do_execbuffer()

i915_switch_context()

do_switch()
   from = ring->last_context;
   i915_gem_object_pin()

      i915_gem_object_bind_to_gtt()
         ret = drm_mm_insert_node_in_range_generic();
         // If the above call fails then it will try i915_gem_evict_something()
         // If that fails it will call i915_gem_evict_everything() ...
	 i915_gem_evict_everything()
	    i915_gpu_idle()
	       i915_switch_context(DEFAULT_CONTEXT)

Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.

Note that there's no need to recheck whether a context switch is still
required because:

- Doing a switch to the same context is harmless (besides wasting a
  bit of energy).

- This can only happen with the default context. But since that one's
  pinned we'll never call down into evict_everything under normal
  circumstances. Note that there's a little driver bringup fun
  involved namely that we could recourse into do_switch for the
  initial switch. Atm we're fine since we assign the context pointer
  only after the call to do_switch at driver load or resume time. And
  in the gpu reset case we skip the entire setup sequence (which might
  be a bug on its own, but definitely not this one here).

Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.

Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.

Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.

References: https://code.google.com/p/chromium/issues/detail?id=248191
Reported-by: Ian Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: stable@vger.kernel.org
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Ian Lister <ian.lister@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit acc240d41ea1ab9c488a79219fb313b5b46265ae)
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

BUG=chrome-os-partner:22147,chrome-os-partner:32694,chromium:248191
TEST=No known steps to reproduce.  Compile, install, run with no
     noticeable regressions.

Change-Id: Ia2a889eafdd9fdea10ff71ab02238c7c89137b00
Reviewed-on: https://chromium-review.googlesource.com/228527
Tested-by: Matthew E Hiltner <matthew.e.hiltner@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Ullysses A Eoff <ullysses.a.eoff@intel.com>
BACKPORT: ALSA: hda - Fix broken PM due to incomplete i915 initialization

When the initialization of Intel HDMI controller fails due to missing
i915 kernel symbols (e.g. HD-audio is built in while i915 is module),
the driver discontinues the probe.  However, since the probe was done
asynchronously, the driver object still remains, thus the relevant PM
ops are still called at suspend/resume. This results in the bad access
to the incomplete audio card object, eventually leads to Oops or stall
at PM.

This patch adds the missing checks of chip->init_failed flag at each
PM callback in order to fix the problem above.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79561
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 4da63c6fc426023d1a20e45508c47d7d68c6a53d)
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

Conflicts:
	sound/pci/hda/hda_intel.c

The conflict is due to missing chip->disabled checks in runtime
suspend/resume that were added in the context of upstream commit
246efa4a07...the scope of commit 246efa4a07 is too large to consider
backporting at this time.

BUG=chrome-os-partner:32694,chromium:410667
TEST=With entire patch series:
     1. Insert a temporary 2 minute superficial sleep delay in
        the request_firmware_work_func
     2. Boot on Peppy
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic
TEST=With entire patch series:
     1. On Peppy, remove /lib/firmware/peppy_alsa.fw
     2. Reboot system
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic

Change-Id: I7eb9799e24993c5689321d216cda6fc06fc909d9
Reviewed-on: https://chromium-review.googlesource.com/229555
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Matthew E Hiltner <matthew.e.hiltner@intel.com>
Commit-Queue: Ullysses A Eoff <ullysses.a.eoff@intel.com>
BACKPORT: ALSA: hda - Add NULL check to all PM ops in hda_intel.c

Since devptr can be NULL due to asynchronous probe, all PM ops should
have NULL checks at the beginning.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 2d9772ef653ccf2d5213603e371bbdfe7573df93)
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

Conflicts:
	sound/pci/hda/hda_intel.c

The conflict was a minor context change... no hda_intel struct.

BUG=chrome-os-partner:32694,chromium:410667
TEST=With entire patch series:
     1. Insert a temporary 2 minute superficial sleep delay in
        the request_firmware_work_func
     2. Boot on Peppy
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic
TEST=With entire patch series:
     1. On Peppy, remove /lib/firmware/peppy_alsa.fw
     2. Reboot system
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic

Change-Id: I8870a451dcd62ca8a50f64f1a64fa2bfdf78e930
Reviewed-on: https://chromium-review.googlesource.com/229556
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Matthew E Hiltner <matthew.e.hiltner@intel.com>
Commit-Queue: Ullysses A Eoff <ullysses.a.eoff@intel.com>
CHROMIUM: ALSA: hda - skip PM ops if async probe is not finished

There are a lot of crash reports on Peppy indicating that runtime
PM is being triggered before the async probe finishes.

Don't execute PM ops if the async probe has not completed yet.
The probe is finished when chip->running is true.

BUG=chrome-os-partner:32694,chromium:410667
TEST=With entire patch series:
     1. Insert a temporary 2 minute superficial sleep delay in
        the request_firmware_work_func
     2. Boot on Peppy
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic
TEST=With entire patch series:
     1. On Peppy, remove /lib/firmware/peppy_alsa.fw
     2. Reboot system
     3. Unplug power cable and wait 15 seconds.  This will trigger
        a runtime suspend
     4. Run powerd_dbus_suspend
     5. No kernel oops or panic

Change-Id: I4be75ba0d21176ed20c6efd236eff054f5bbdb41
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229557
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Matthew E Hiltner <matthew.e.hiltner@intel.com>
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8