drm/i915/bios: split the MIPI DSI VBT block parsing to two

There's two blocks to parse, have one function per block. The existing
one cuts neatly into two.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/6c9598e2b4d07e8d264617cdfe8b6527a74261f7.1450702954.git.jani.nikula@intel.com

drm/i915/bios: fix header define name for intel_bios.h

Just for OCD.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/730e41760133dbaa1e3ab1b91631ada18676810c.1450702954.git.jani.nikula@intel.com

drm/i915/guc: Add GuC ADS - enabling ADS

Set ADS enabling flag during GuC init.

Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450468812-4882-6-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Add GuC ADS - MMIO reg state

GuC needs to know which registers and how they will be saved and
restored during event such as engine reset or power state changes.
For now only the base address of reg state is initialized. The
detail register table probably will be setup in future GuC TDR or
Preemption patch series.

Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450468812-4882-5-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Add GuC ADS - scheduler policies

GuC supports different scheduling policies for its four internal
queues. Currently these have been set to the same default values
as KMD_NORMAL queue.

Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
maximum submit queue numbers to avoid an out-of-space problem.
This value indicates max number of work items allowed to be queued
for one DPC process. A smaller value will let GuC schedule more
frequently while a larger number may increase chances to optimize
cmds (such as collapse cmds from same lrc) with risks that keeps
CS idle.

v1: tidy up code

Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450468812-4882-4-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored during reset etc.

This is the first patch of a series to enable GuC ADS. For now, we
only create the ADS obj whilst keep it disabled.

v1: remove dead code checking return of kmap_atomic (Chris Wilson)
v2: use kmap instead of the atomic version of it.

Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450468812-4882-3-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Expose (intel)_lr_context_size()

The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.

For: VIZ-2021
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450468812-4882-2-git-send-email-yu.dai@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Move GuC wq_check_space to alloc_request_extras

Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.

v1: Move wq_reserve_space to ring_reserve_space
v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson)
v3: The work queue head pointer is cached by driver now. So we can
    quickly return if space is available.
    s/reserve/check/g (Dave Gordon)
v4: Update cached wq head after ring doorbell; check wq space before
    ring doorbell in case unexpected error happens; call wq space
    check only when GuC submission is enabled. (Dave Gordon)

Signed-off-by: Alex Dai <yu.dai@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450295155-10050-1-git-send-email-yu.dai@intel.com
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable shrinker for non-swapped backed objects

If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. By doing so, we avoid unbinding objects that cannot be
shrunk and so wasting CPU cycles flushing those objects from the GPU to
the system and then immediately back again (as they will more than
likely be reused shortly after).

Based on a patch by Akash Goel.

v2: frontswap registers extra swap pages available for the system, so it
is already include in the count of available swap pages.

v3: Use get_nr_swap_pages() to query the currently available amount of
swap space. This should also stop us from shrinking the GPU buffers if
we ever run out of swap space. Though at that point, we would expect the
oom-notifier to be running and failing miserably...

Reported-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: linux-mm@kvack.org
Cc: Akash Goel <akash.goel@intel.com>
Cc: sourab.gupta@intel.com
Link: http://patchwork.freedesktop.org/patch/msgid/1449244734-25733-2-git-send-email-chris@chris-wilson.co.uk
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

mm: Export nr_swap_pages

Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so, they
want to check using get_nr_swap_pages() to see if any swap space is
available as otherwise they will waste time purging the object from the
device without recovering any memory for the system. This requires the
nr_swap_pages counter to be exported to the modules.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Link: http://patchwork.freedesktop.org/patch/msgid/1449244734-25733-1-git-send-email-chris@chris-wilson.co.uk
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Avoid writing relocs with addresses in non-canonical form

According to PRM, some parts of HW require the addresses to be in
a canonical form, where bits [63:48] == [47]. Let's convert addresses to
canonical form prior to relocating and return converted offsets to
userspace. We also need to make sure that userspace is using addresses
in canonical form in case of softpin.

v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville)
v3: Rebase on top of softpin, fix a hole in relocate_entry,
    s/expect/require (Chris)
v4: Handle softpin in validate_exec_list (Chris)
v5: Convert back to canonical form at copy_to_user time (Chris)
v6: Don't use struct exec_object2 in place of exec_object
v7: Use sign_extend64 for converting to canonical form (Joonas),
    reject non-canonical and non-page-aligned offset for softpin (Chris)
v8: Convert back to non-canonical form in a function,
    split the test for EXEC_OBJECT_PINNED (Chris)
v9: s/canonial/canonical, drop accidental double newline (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451409892-13708-1-git-send-email-michal.winiarski@intel.com
Testcase: igt/gem_bad_reloc/negative-reloc-blt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92699
Cc: drm-intel-fixes@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915: correctly handling failed allocation

Since devm_kzalloc can be failed, it needs to be checked
if not, NULL dereference could be happened.

Signed-off-by: Insu Yun <wuninsu@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451491169-35068-1-git-send-email-wuninsu@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix whitespace (trivial)

Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451427643-7266-1-git-send-email-benjamin.widawsky@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: increase the tries for HDMI hotplug live status checking

The total delay of HDMI hotplug detecting with 30ms is sometimes not
enoughtfor HDMI live status up with specific HDMI monitors in BSW platform.

After doing experiments for following monitors, it needs 80ms at least
for those worst cases.

Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/40/60/40ms)
Philips HH2AP (9 failed, necessary hot-plug delay: 80/50/50/60/46/40/58/58/39ms)
BENQ ET-0035-N (6 failed, necessary hot-plug delay: 60/50/50/80/80/40ms)
DELL U2713HM (2 failed, necessary hot-plug delay: 58/59ms)
HP HP-LP2475w (5 failed, necessary hot-plug delay: 70/50/40/60/40ms)

It looks like 70-80 ms is BSW platform needs in some bad cases of the
monitors at this end (8 times delay at most). Keep less than 100ms for
HDCP pulse HPD low (with at least 100ms) to respond a plug out.

Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450858295-12804-1-git-send-email-gary.c.wang@intel.com
Tested-by: Shobhit Kumar <shobhit.kumar@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Calculate visibility in check_plane correctly regardless of dpms.

When the crtc is configured but not active we currently clip to (0,0)x(0,0).
This results in differences in calculations depending on dpms setting.
When the crtc is enabled but not active run check_plane as if it were on,
but afterwards set plane_state->visible = false for the checks.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-13-git-send-email-maarten.lankhorst@linux.intel.com

drm/i915: Keep track of the cdclk as if all crtc's were active.

On skylake when calculating plane visibility with the crtc in
dpms off mode the real cdclk may be different from what it would be
if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
if all crtc's were active.

This is required to get the same calculations done correctly regardless
of dpms mode.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-12-git-send-email-maarten.lankhorst@linux.intel.com

drm/i915: Do not acquire crtc state to check clock during modeset, v4.

Parallel modesets are still not allowed, but this will allow updating
a different crtc during a modeset if the clock is not changed.

Additionally when all pipes are DPMS off the cdclk will be lowered
to the minimum allowed.

Changes since v1:
- Add dev_priv->active_crtcs for tracking which crtcs are active.
- Rename min_cdclk to min_pixclk and move to dev_priv.
- Add a active_crtcs mask which is updated atomically.
- Add intel_atomic_state->modeset which is set on modesets.
- Commit new pixclk/active_crtcs right after state swap.
Changes since v2:
- Make the changes related to max_pixel_rate calculations more readable.
Changes since v3:
- Add cherryview and missing WARN_ON to readout.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

drm/i915/skl: Do not allow scaling when crtc is disabled.

This fixes a warning when the crtc is turned off. In that case fb
will be NULL, and crtc_clock will be 0. Because the crtc is no longer
active this is not a bug, and shouldn't trigger the WARN_ON.

Also remove handling a null crtc_state, with all transitional helpers
gone this can no longer happen.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448360945-5723-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)

Add an overview and documentation for the VBT/BDB header structures.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/3d826d4600688ca3518713776ab5bd8a8fc9f20f.1450702954.git.jani.nikula@intel.com

drm/i915: Unbreak check_digital_port_conflicts()

Atomic changes broke check_digital_port_conflicts(). It needs to look
at the global situation instead of just trying to find a conflict
within the current atomic state.

This bug made my HSW explode spectacularly after I had split the DDI
encoders into separate DP and HDMI encoders. With the fix, things
seem much more solid.

I hope holding the connection_mutex is enough protection that we can
actually walk the connectors even if they're not part of the current
atomic state...

v2: Regenerate the patch so that it actually applies (Jani)

Cc: stable@vger.kernel.org
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Fixes: 5448a00d3f06 ("drm/i915: Don't use staged config in check_digital_port_conflicts()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449764551-12466-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Compile-time concatenate WARN_ON macro strings

Using __stringify(x) instead of #x adds support for macros as
a parameter and compile-time concatenation reduces the runtime
overhead.

Slightly increases the .text size but should not matter.

v2:
- Define I915_STATE_WARN_ON though I915_STATE_WARN
  (Bikeshed inspiration by Chris)

v3:
- More specific commit message

v4:
- Do not directly pass arbitary string as format, instead
  guard with "%s" (Dave)

Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450441647-23924-3-git-send-email-joonas.lahtinen@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Simplify _STATE_ debug macros

Take advantage of WARN return value to simplify the flow.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450441647-23924-2-git-send-email-joonas.lahtinen@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove obsolete code from intelfb_alloc()

Clean up after 0c82312f3f15 ("drm/i915: Pin the ifbdev for the
info->system_base GGTT mmapping"):

At each of the remaining "goto out" in intelfb_alloc(), fb can only be
either an ERR_PTR or NULL, so the call to drm_framebuffer_unreference()
is now obsolete.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/56756c41.c306c20a.d0602.1830SMTPIN_ADDED_MISSING@mx.google.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Workaround CHV pipe C cursor fail

Turns out CHV pipe C was glued on somewhat poorly, and there's something
wrong with the cursor. If the cursor straddles the left screen edge,
and is then moved away from the edge or disabled, the pipe will often
underrun. If enough underruns are triggered quickly enough the pipe
will fall over and die (it just scans out a solid color and reports
a constant underrun). We need to turn the disp2d power well off and
on again to recover the pipe.

None of that is very nice for the user, so let's just refuse to place
the cursor in the compromised position. The ddx appears to fall back
to swcursor when the ioctl returns an error, so theoretically there's
no loss of functionality for the user (discounting swcursor bugs).
I suppose most cursors images actually have the hotspot not exactly
at 0,0 so under typical conditions the fallback will in fact kick in
as soon as the cursor touches the left edge of the screen.

Any atomic compositor should anyway be prepared to fall back to
GPU composition when things don't work out, so there should be no
problem with those.

Other things that I tried to solve this include flipping all
display related clock gating knobs I could find, increasing the
minimum gtt alignment all the way up to 512k. I also tried to see
if there are more specific screen coordinates that hit the bug, but
the findings were somewhat inconclusive. Sometimes the failures
happen almost across the whole left edge, sometimes more at the very
top and around the bottom half. I wasn't able to find any real pattern
to these variations, so it seems our only choice is to just refuse
to straddle the left screen edge at all.

Cc: stable@vger.kernel.org
Cc: Jason Plum <max@warheads.net>
Testcase: igt/kms_chv_cursor_fail
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reorder i915_params struct.

Move all the bool variables to the end as per the comment.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450436898-20408-3-git-send-email-joonas.lahtinen@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Decouple struct i915_params i915 into i915_params.h

Otherwise usage in the i915 debug macros yields problems due to
i915_drv.h <-> i915_trace.h <-> intel_drv.h include loops.

v2:
- Document not-so-obvious need for linux/cache.h (Chris)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450436898-20408-2-git-send-email-joonas.lahtinen@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Limit VF cache invalidate workaround usage to gen9

It is unclear if this is even required on BXT.

v2: Make sure to set the default value to false. Uncertain how my compiler
doesn't complain with v1.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450374597-7021-1-git-send-email-benjamin.widawsky@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Correct max delay for HDMI hotplug live status checking

The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms delay.

v2:
- straight up to loop execution for more clear in code readability
- mdelay will replace with msleep by Daniel's new patch

drm/i915: mdelay(10) considered harmful

- suggest to re-evaluate try times for being compatible to old HDMI monitor

Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
[danvet: fixup conflict with s/mdelay/msleep/ patch.]
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move Braswell stop_machine GGTT insertion workaround

There was a silent conflict between

commit 0a878716265e9af9f697264dc2e858fcc060d833
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 14:23:01 2015 +0200

    drm/i915: restore ggtt double-bind avoidance

and

commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 23 18:43:32 2015 +0100

    drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

thankfully caught by the extra WARN safegaurd in 0a878716. Since we now
override the GGTT insert_pages callback when installing the aliasing
ppgtt, we assert that the callback is the original ggtt routine.
However, on Braswell we now use a different insertion routine to
serialise access through the GGTT with updating the PTE and hence the
conflict. To avoid the conflict, move the custom insertion routine for
Braswell down a level.

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447859979-20107-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Apply broader WaRsDisableCoarsePowerGating for guc also

commit 344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
failed to take into account that the same workaround is used in guc
when forcewake is sampled.

Wrap the condition check inside a macro and use it in both places
to fix the guc side scope.

Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450286318-6854-1-git-send-email-mika.kuoppala@intel.com

drm/i915: Update DRIVER_DATE to 20151218

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Default to noncoherent access up to F0

The workarounds for disabling hdc invalidation and also forcing
context to be non coherent, are advised to be used up until rev D0.

However as it was found that rev F0, without the
WaForceEnableNonCoherent might system hang if the mesa
tried to use coherent mode.

As these two workarounds are about non coherent access, are
grouped in scope and they point the same HSD, increase the
scope of both to set default behaviour to non coherent access.

References: HSD: gen9lp/2131413
References: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101515.html
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450448093-22906-1-git-send-email-mika.kuoppala@intel.com

drm/i915: Only spin whilst waiting on the current request

Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.

v2: Check for logical inversion when rebasing - we were incorrectly
checking for this request being active, and instead busywaiting for
when the GPU was not yet processing the request of interest.

v3: Try another colour for the seqno names.
v4: Another colour for the function names.

v5: Remove the forced coherency when checking for the active request. On
reflection and plenty of recent experimentation, the issue is not a
cache coherency problem - but an irq/seqno ordering problem (timing issue).
Here, we do not need the w/a to force ordering of the read with an
interrupt.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk

drm/i915: Limit the busy wait on requests to 5us not 10ms!

When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as possible. However, if it is a slow
request, we want to sleep as quickly as possible. The tradeoff between
waiting and sleeping is roughly the time it takes to sleep on a request,
on the order of a microsecond. Based on measurements of synchronous
workloads from across big core and little atom, I have set the limit for
busywaiting as 10 microseconds. In most of the synchronous cases, we can
reduce the limit down to as little as 2 miscroseconds, but that leaves
quite a few test cases regressing by factors of 3 and more.

The code currently uses the jiffie clock, but that is far too coarse (on
the order of 10 milliseconds) and results in poor interactivity as the
CPU ends up being hogged by slow requests. To get microsecond resolution
we need to use a high resolution timer. The cheapest of which is polling
local_clock(), but that is only valid on the same CPU. If we switch CPUs
because the task was preempted, we can also use that as an indicator that
 the system is too busy to waste cycles on spinning and we should sleep
instead.

__i915_spin_request was introduced in
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 7 16:20:41 2015 +0100

     drm/i915: Optimistically spin for the request completion

v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
so we can use native register sizes on smaller architectures. Mention
the approximate microseconds units for elapsed time and add some extra
comments describing the reason for busywaiting.

v3: Raise the limit to 10us
v4: Now 5us.

Reported-by: Jens Axboe <axboe@kernel.dk>
Link: https://lkml.org/lkml/2015/11/12/621
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: Break busywaiting for requests on pending signals

The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.

In the worst case this could cause a delay in signal processing of 20ms,
which would be a noticeable jitter in cursor tracking. If a higher
resolution signal was being used, for example to provide fairness of a
server timeslices between clients, we could expect to detect some
unfairness between clients (i.e. some windows not updating as fast as
others). This issue was noticed when inspecting a report of poor
interactivity resulting from excessively high __i915_spin_request usage.

Fixes regression from
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 7 16:20:41 2015 +0100

     drm/i915: Optimistically spin for the request completion

v2: Try to assess the impact of the bug

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk

drm/i915: don't enable autosuspend on platforms without RPM support

pm_runtime_{use,dont_use}_autosuspend() controls whether the device's
sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on
access to user space. Since

commit 25b181b46e4340f69793a886f2cd46608487783b
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Dec 17 13:44:56 2015 +0200

  drm/i915: get a permanent RPM reference on platforms w/o RPM support

this sysfs file is writeable also on platforms without RPM support, but
userspace (at least IGT) depends on this file being unchangable to
determine whether the device supports runtime PM at all. So restore the
old behavior.

This gets rid of igt/pm_rpm failures on old platforms without RPM
support, where the test should be skipped.

Testcase: igt/pm_rpm/basic-rte
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: David Weinehall <david.weinehall@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com

drm/i915/backlight: prefer dev_priv over dev pointer

Use dev_priv rather than dev pointer where applicable. Remove plenty of
unnecessary temp variables. No functional changes.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450428695-28831-1-git-send-email-jani.nikula@intel.com

drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)

If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb.  This mismatch causes problems later on
(e.g., for the watermark code).  Since we've failed to reconstruct the
BIOS FB, the best solution is to just disable the primary plane and
pretend the BIOS never had it enabled.

v2: Add intel_pre_disable_primary() call (Maarten)

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com

drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb is only pinned whilst it is active and we no
longer have an explicit pin for the info->system_base mmapping used by
the fbdev. The result is that after some aperture pressure the fbdev may
be evicted, but we continue to write the fbcon into the same GGTT
address - overwriting anything else that may be put into that offset.
The effect is most pronounced across suspend/resume as
intel_fbdev_set_suspend() does a full clear over the whole scanout.

v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from
the BIOS, we do not own the pinned vma (except for the reference we add
in this patch for our access via info->screen_base).

v3: Finish balancing the vma pinning for the normal !preallocated case.

v4: Try to simplify the pinning even further.
v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1449245126-26158-1-git-send-email-chris@chris-wilson.co.uk
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set the map-and-fenceable flag for preallocated objects

As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that later
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1448029000-10616-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: mdelay(10) considered harmful

I missed this myself when reviewing

commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal <sonika.jindal@intel.com>
Date:   Tue Sep 15 09:44:20 2015 +0530

    drm/i915: Check live status before reading edid

Long sleeps like this really shouldn't waste cpu cycles spinning.

Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: "Wang, Gary C" <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters

The device should be on for the whole duration of the update, so check
for this.

v2:
- use the existing dev_priv directly everywhere (Ville)
v3:
- check also that we are in an RPM atomic section (Chris)
- add the assert to i915_ggtt_insert_entries/clear_range too (Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-11-git-send-email-imre.deak@intel.com

drm/i915: add support for checking RPM atomic sections

In some cases we want to check whether we hold an RPM wakelock reference
for the whole duration of a sequence. To achieve this add a new RPM
atomic sequence counter that we increment any time the wakelock refcount
drops to zero.  Check whether the sequence number stays the same during
the atomic section and that we hold the wakelock at the beginning of the
section.

Motivated by Chris.

v2-v3:
- unchanged
v4:
- swap the order of atomic_read() and assert_rpm_wakelock_held() in
  assert_rpm_atomic_begin() to avoid race

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com

drm/i915: check that we hold an RPM wakelock ref before we put it

With this change we have the corresponding wake lock checks in both the
rpm get and put functions.

v2-v3:
- unchanged
v4:
- keep the corresponding check in the get helper (Chris)
v5:
- add a note to the commit message that with this change we have the
  checks both in the rpm get and put functions (Joonas)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-9-git-send-email-imre.deak@intel.com

drm/i915: add support for checking if we hold an RPM reference

Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device suspend may be delayed. Change assert_rpm_wakelock_held()
accordingly to check for a non-zero RPM refcount in addition to the
current device-not-suspended check.

For the new asserts to work we need to annotate every place explicitly in
the code where we expect that the device is powered. The places where we
only assume this, but may not hold an RPM reference:
- driver load
  We assume the device to be powered until we enable RPM. Make this
  explicit by taking an RPM reference around the load function.
- system and runtime sudpend/resume handlers
  These handlers are called when the RPM reference becomes 0 and know the
  exact point after which the device can get powered off. Disable the
  RPM-reference-held check for their duration.
- the IRQ, hangcheck and RPS work handlers
  These handlers are flushed in the system/runtime suspend handler
  before the device is powered off, so it's guaranteed that they won't
  run while the device is powered off even though they don't hold any
  RPM reference. Disable the RPM-reference-held check for their duration.

In all these cases we still check that the device is not suspended.
These explicit annotations also have the positive side effect of
documenting our assumptions better.

This caught additional WARNs from the atomic modeset path, those should
be fixed separately.

v2:
- remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
v3:
- use a new dedicated RPM wakelock refcount to also catch cases where
  our own RPM get/put functions were not called (Chris)
- assert also that the new RPM wakelock refcount is 0 in the RPM
  suspend handler (Chris)
- change the assert error message to be more meaningful (Chris)
- prevent false assert errors and check that the RPM wakelock is 0 in
  the RPM resume handler too
- prevent false assert errors in the hangcheck work too
- add a device not suspended assert check to the hangcheck work
v4:
- rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts
  and wakelock_count to wakeref_count
- disable the wakeref asserts in the IRQ handlers and RPS work too
- update/clarify commit message
v5:
- mark places we plan to change to use proper RPM refcounting with
  separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com

drm/i915: use assert_rpm_wakelock_held instead of opencoding it

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-7-git-send-email-imre.deak@intel.com

drm/i915: add assert_rpm_wakelock_held helper

As a preparation for follow-up patches add a new helper that checks
whether we hold an RPM reference, since this is what we want most of
the cases. Atm this helper will only check for the HW suspended state, a
follow-up patch will do the actual change to check the refcount instead.
One exception is the forcewake release timer function, where it's
guaranteed that the HW is on even though the RPM refcount drops to zero.
This guarantee is provided by flushing the timer in the runtime suspend
handler. So leave the assert_device_not_suspended check in place there.

Also rename assert_device_suspended for consistency and export these
helpers as a preparation for the follow-up patches.

No functional change.

v3:
- change the assert warning message to be more meaningful (Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-6-git-send-email-imre.deak@intel.com

drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers

We don't really need to check this flag in the get/put/assert helpers,
as on platforms without RPM support we won't ever enable RPM. That means
pm.suspend will be always false and the assert will be always true.

Do this to simplify the code and to let us extend the RPM asserts to all
platforms for a better coverage.

Motivated by Ville.

v2-v3:
- unchanged
v4:
- remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too
  made possible by the previous two patches
v5:
- rebased on the previous new patch in the series that keeps
  HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent
  reference taken there

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450352931-16498-1-git-send-email-imre.deak@intel.com

drm/i915: get a permanent RPM reference on platforms w/o RPM support

Currently we disable RPM functionality on platforms that doesn't support
this by not putting/getting the RPM reference we receive from the RPM
core during driver loading/unloading respectively. This is somewhat
obscure, so make it more explicit by keeping a reference dedicated for
this particular purpose whenever the driver is loaded. This makes it
possible to remove the HAS_RUNTIME_PM() special casing from every other
places in the next patch.

v2:
- fix intel_runtime_pm_get vs. intel_runtime_pm_put in
  intel_power_domains_fini()
v3:
- take only a low level RPM reference so the ref tracking asserts
  continue to work (Ville)
- update the commit message
- move the patch earlier for bisectability

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450352696-16135-1-git-send-email-imre.deak@intel.com

drm/i915: refactor RPM disabling due to RC6 being disabled

We can make the RPM dependency on RC6 explcit in the code by taking an
actual RPM reference, instead of avoiding to drop the initial one. This
will also enable us to remove the HAS_RUNTIME_PM special casing from
more places in the next patch.

v2:
- fixed typo in commit message (Joonas)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-4-git-send-email-imre.deak@intel.com

drm/i915: clarify comment about mandatory RPM put/get during driver load/unload

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-2-git-send-email-imre.deak@intel.com

drm/i915/opregion: handle VBT sizes bigger than 6 KB

The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
mailbox may specify an alternate location for VBT instead of mailbox #4.
Use the alternate location if available and valid, falling back to
mailbox #4 otherwise.

v2: Update debug logging (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com

drm/i915: Fix AVI/HDMI/SPD infoframes on HSW+

I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
safety changes. We were supposed to check that the infoframe data
register is valid before writing the infoframe data, but the check
ended up inverted, and so in practice we never wrote or enabled
these infoframes.

We were still sending out the GCP infoframe when the sink was
deep-color capable. That and the fact that we use a single
bool to track our infoframe state meant that the state checker
only caught this when a HDMI sink that doesn't do deep-color was
used.

We really need to fix our infoframe state checking to be much
more anal. But in the meantime let's just fix the regression.
In fact let's just throw out the register validity check and
convert some of the "unknown info frame type" debug messages
into MISSING_CASE(). So far we support the same set of infoframe
types on all platforms, so the silent debug messages make no
sense.

Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: f0f59a00a1c9 ("drm/i915: Type safe register read/write")
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450282200-4203-1-git-send-email-ville.syrjala@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93119
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bios: reduce indent in parse_general_features

Slightly cleaner with early exit.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-4-git-send-email-jani.nikula@intel.com

drm/i915/bios: prefer using dev_priv over dev pointer

dev_priv is the new black. Or something.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-3-git-send-email-jani.nikula@intel.com

drm/i915/bios: fix format string of the VBT signature logging

Specify the maximum number of letters to print from the potentially
unterminated buffer, not the minimum. While at it, use sizeof instead of
a magic number.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-2-git-send-email-jani.nikula@intel.com

drm/i915: move drmP.h include to i915_drv.h

The intel_bios.h header doesn't even need it, but other headers included
from i915_drv.h do. Let's untangle the mess a bit.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450271061-32646-1-git-send-email-jani.nikula@intel.com

drm/i915: prefer for_each_intel_* macros for iteration

Use the for_each_intel_* macros for iterating intel_encoder,
intel_connector, and intel_crtc. No functional changes.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450262896-5325-1-git-send-email-jani.nikula@intel.com

drm/i915/debugfs: add a separate debugfs file for VBT

In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.

v2: Drop the locking as unneeded (Chris)
v3: Rebase

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178232-27780-1-git-send-email-jani.nikula@intel.com

drm/i915: don't use a temp buffer for opregion debugfs file

Hasn't been necessary since

commit 115719fceaa733d646e39cdce83cc32ddb891a49
Author: Williams, Dan J <dan.j.williams@intel.com>
Date:   Mon Oct 12 21:12:57 2015 +0000

    i915: switch from acpi_os_ioremap to memremap

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/74664a556a56d0eceb0029bbd77ffc1d771b0628.1450089383.git.jani.nikula@intel.com

drm/i915/opregion: make VBT pointer a const

Because we can. It's not to be touched so tell the compiler too.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/4b1872b121fb34a193cff9a5cb4e7c858d4a55aa.1450089383.git.jani.nikula@intel.com

drm/i915/opregion: make VBT size limit more strict

The VBT in OpRegion should fit in mailbox #4.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/4bdb3f5820e3dbd1cdfa7b65cadfce4f80b880f0.1450089383.git.jani.nikula@intel.com

drm/i915: refactor VBT validation

Make the validation function a boolean operating on a buffer of given
size, removing the extra pointer dances.

Move the OpRegion based VBT validation to intel_opregion_setup(), only
initializing opregion->vbt if it's valid.

v2: move logging about valid VBT to opregion setup too (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178175-27420-1-git-send-email-jani.nikula@intel.com

drm/i915/bios: rename intel_parse_bios to intel_bios_init

While at it, move the declaration to where everything else is declared.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/7d9d879603038889f0128cf7cbbd9f591edc11dd.1450089383.git.jani.nikula@intel.com

drm/i915/bios: move debug logging about VBT source to intel_parse_bios()

The decision about which source will be used for VBT is done in
intel_parse_bios(), not in the VBT validation function. Make the VBT
validation function strictly about validation, and move the debug
logging to where it logically belongs.

Also split the logging about where the valid VBT was found and what the
signature is. This will make even more sense in the future when the
validation for ACPI OpRegion based VBT takes place at OpRegion setup
time.

v2: Split logging about VBT signature and BDB version.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178092-27148-1-git-send-email-jani.nikula@intel.com

drm/i915/bios: have functions return vbt, not bdb, header pointer

This will simplify further work.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/d2c5210402fdd8c277e1d50892b0620d10c50ae8.1450089383.git.jani.nikula@intel.com

drm/i915: move "no VBT in opregion" quirk to intel_opregion_setup()

Check the quirk in intel_opregion_setup(), and don't initialize
opregion->vbt at all if the quirk says it's not present, hiding the
quirk from the rest of the driver.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/7cdc86eb441f8b7075142445a800b07ecf8c76cb.1450089383.git.jani.nikula@intel.com

drm/i915: Add Intel opregion mailbox 5 structure

Mailbox 5 is BIOS to Driver Notification mailbox is intended
to support BIOS to Driver event notification or data storage
for BIOS to Driver data synchronization purpose. Mailbox 5 is
the extension of mailbox 3.

v4 by Jani:
 - don't add asle_ext to dev_priv as it's unused
 - use u8 for bddc and rsvd fields in asle ext struct
 - add BUILD_BUG_ON the asle ext struct size
 - debug logging for asle ext present

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com

drm/i915: Drop the broken cursor base==0 special casing

The cursor code tries to treat base==0 to mean disabled. That fails
when the cursor bo gets bound at ggtt offset 0, and the user is left
looking at an invisible cursor.

We lose the disabled->disabled optimization, but that seems like
something better handled at a slightly higher level.

Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450091808-32607-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Kill intel_crtc->cursor_bo

The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other uses thanks to universal plane support.

Chris pointed out that cursor updates are currently too slow
via universal planes that micro optimizations like these wouldn't
even help.

v2: Add a note about futility of micro optimizations (Chris)

Cc: drm-intel-fixes@lists.freedesktop.org
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: PSR also doesn't have link_entry_time on SKL.

This bit is also reserved on Skylake. Actually the only
platform that supports this is Haswell, so let's fix
this logic and apply this link entry time only for the
platform that supports it, i.e. Haswell.

This also changes the style to let more clear platform
differences outside the reg write. We would probably catch
this case sooner if separated, or not...

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449880291-21388-1-git-send-email-rodrigo.vivi@intel.com

Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queued

Add get_eld audio component for i915/HD-audio

Currently, the HDMI/DP audio status and ELD are notified and obtained
via the hardware-level communication over HD-audio unsolicited event
and verbs although the graphics driver holds the exactly same
information.  As we already have a notification via audio component,
this is another step forward; namely, the audio driver may fetch
directly the audio status and ELD via the new component op.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: mark a newly-created GEM object dirty when filled with data

When creating a new (pageable) GEM object and filling it with data, we
must mark it as 'dirty', i.e. backing store is out-of-date w.r.t. the
newly-written content. This ensures that if the object is evicted under
memory pressure, its pages in the pagecache will be written to backing
store rather than discarded.

Based on an original version by Alex Dai.

Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-3-git-send-email-david.s.gordon@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: mark GEM object pages dirty when mapped & written by the CPU

In various places, a single page of a (regular) GEM object is mapped into
CPU address space and updated. In each such case, either the page or the
the object should be marked dirty, to ensure that the modifications are
not discarded if the object is evicted under memory pressure.

The typical sequence is:
va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
*(va+offset) = ...
kunmap_atomic(va);

Here we introduce i915_gem_object_get_dirty_page(), which performs the
same operation as i915_gem_object_get_page() but with the side-effect
of marking the returned page dirty in the pagecache.  This will ensure
that if the object is subsequently evicted (due to memory pressure),
the changes are written to backing store rather than discarded.

Note that it works only for regular (shmfs-backed) GEM objects, but (at
least for now) those are the only ones that are updated in this way --
the objects in question are contexts and batchbuffers, which are always
shmfs-backed.

Separate patches deal with the cases where whole objects are (or may
be) dirtied.

v3: Mark two more pages dirty in the page-boundary-crossing
    cases of the execbuffer relocation code [Chris Wilson]

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update to post-reset execlist queue clean-up

When clearing an execlist queue, instead of traversing it and unreferencing all
requests while holding the spinlock (which might lead to thread sleeping with
IRQs are turned off - bad news!), just move all requests to the retire request
list while holding spinlock and then drop spinlock and invoke the execlists
request retirement path, which already deals with the intricacies of
purging/dereferencing execlist queue requests.

This patch can be considered v3 of:

commit b96db8b81c54ef30485ddb5992d63305d86ea8d3
Author: Tomas Elf <tomas.elf@intel.com>
drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues

This patch assumes v2 of the above patch is part of the baseline, reverts v2
and adds changes on top to turn it into v3.

Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1445619757-19822-1-git-send-email-tomas.elf@intel.com
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Dave Gordon <dave.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: dual link pipe selection for bxt

Pipe is assigned based on the port, but it should be
based on current crtc. Correcting the same in this patch.

v2: Use macro BXT_PIPE_SELECT(pipe) (Daniel)

Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add VBT address and size fields to ASLE mailbox struct

To be used on systems where the VBT does not fit into the normal VBT
mailbox.

v3: rebase

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448923632-16760-3-git-send-email-m.deepak@intel.com
[Jani: updated commit message]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix random aux transactions failures.

Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.

Since drm level was already taking care of retries and didn't want
to through random retries on that level the second solution was to
put the retries at aux_transfer layer what was nacked.

So I realized we had so many retries in different places and
started to organize that a bit. During this organization I noticed
that we weren't handing at all the case were the message size was
zeroed. And this was exactly the case that was affecting sink_crc.

Also we weren't respect BSPec who says this size message = 0 or > 20
are forbidden.

It is a fact that we still have no clue why we are getting this
forbidden value there. But anyway we need to handle that for now
so we return -EBUSY and drm level takes care of the retries that
are already in place.

v2: Print debug messsage when this case is reached as suggested
    by Jani.
v3: This patch is crucial to make PSR test cases reliably working
    on SKL. So split this patch from the aux re-org series and add
    a FIXME as a promisse to continue that effort besides reminding
    to remove the sleep when that is merged.
v4: Use a bigger usleep range so kernel doesn't need to be interrupted
    on a exact time, as suggested by Paulo.
    But anyway we should discuss the better time
    ranges on the EBUSY handle re-org at drm level since this one here
    is temporary.
v5: s/1000,1500/1000, 1500/ (by Paulo).

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449774747-2772-1-git-send-email-rodrigo.vivi@intel.com

drm/i915: intel_ring_initialized() must be simple and inline

Based on Chris Wilson's patch from 6 months ago, rebased and adapted.

The current implementation of intel_ring_initialized() is too heavyweight;
it's a non-inlined function that chases several levels of pointers. This
wouldn't matter too much if it were rarely called, but it's used inside
the iterator test of for_each_ring() and is therefore called quite
frequently. So let's make it simple and inline ...

The idea here is to use ring->dev as an indicator showing which engines
have been initialised and are therefore to be included in iterations that
use for_each_ring(). This allows us to avoid multiple memory references
and a (non-inlined) function call on each iteration of each such loop.

Fixes regression from
commit 48d823878d64f93163f5a949623346748bbce1b4
Author: Oscar Mateo <oscar.mateo@intel.com>
Date:   Thu Jul 24 17:04:23 2014 +0100

    drm/i915/bdw: Generic logical ring init and cleanup

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449586956-32360-2-git-send-email-david.s.gordon@intel.com

drm/i915: Add reverse mapping between port and intel_encoder

This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.

Note that, even if it's a valid digital port, the dig_port_map[] might
point still to NULL -- usually it implies a DP MST port.  Due to this
fact, the NULL check in each place has no WARN_ON() and just skips the
port.  Once when the situation changes in future, we might introduce
WARN_ON() for a more strict check.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Add get_eld audio component

Implement a new i915_audio_component_ops, get_eld().  It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port.  It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code.  The
current state of audio on/off is stored in the given pointer, too.

Note that the returned size isn't limited to the given max bytes.  If
the size is greater than the max bytes, it means that only a part of
ELD has been copied back.

For achieving this implementation, a new field audio_connector is
added to struct intel_digital_port.  It points to the connector
assigned to the given digital port.  It's set/reset at each audio
enable/disable call in intel_audio.c, and protected with av_mutex.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Do a better job at disabling primary plane in the noatomic case.

When disable_noatomic is called plane_mask is not correct yet, and
plane_state->visible = true is left as true after disabling the primary
plane.

Other planes are already disabled as part of crtc sanitization, only the
primary is left active. But the plane_mask is not updated here. It gets
updated during fb takeover in modeset_gem_init, or set to the new value
on resume.

This means that to disable the primary plane 1 << drm_plane_index(primary)
needs to be used.

Afterwards because the crtc is no longer active it's forbidden to keep
plane_state->visible set, or a WARN_ON in
intel_plane_atomic_calc_changes triggers. There are other code points
that rely on accurate plane_state->visible too, so make sure the bool is
cleared.

The other planes are already disabled in intel_sanitize_crtc, so they
don't have to be handled here.

Cc: stable@vger.kernel.org #v4.3, v4.2?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655
Tested-by: Tomas Mezzadra <tmezzadra@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/5652DB88.9070208@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove BUG_ON call in vlv_enable_pll

Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.

In this case remove the BUG_ON call in vlv_enable_pll().

v2: Also remove the BUG_ON call in chv_enable_pll(). (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449529362-18193-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Only set gem object L3 cache level for IVB devices

Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.

In this case, in i915_gem_alloc_context_obj() only call
i915_gem_object_set_cache_level() for Ivy Bridge devices
since later platforms don't have L3 control bits in the PTE.

v2: Expand comment to mention snooping requirement. (Ville, Imre)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449596332-23470-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Remove VLV A0 hack

Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.

In this case remove a hack for VLV A0.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449514270-15171-4-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Use HAS_PCH_SPLIT to determine correct devices

Do some further clean up based on the initial review of
drm/i915: Separate cherryview from valleyview.

In this case check for '(GEN7 || GEN8) && HAS_PCH_SPLIT' since we're
reading FUSE_STRAP and SFUSE_STRAP which live in the PCH.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449514270-15171-3-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Separate cherryview from valleyview

The cherryview device shares many characteristics with the valleyview
device.  When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.

This patch changes .is_valleyview to .is_cherryview in the cherryview
device info structure and simplifies the IS_CHERRYVIEW macro.
Then where appropriate, instances of IS_VALLEYVIEW are replaced with
IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent.

v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro.
    Also add followup patches to fix issues discovered during the first
    review. (Ville)
v3: Fix some style issues and one gen check. Remove CRT related changes
    as CRT is not supported on CHV. (Imre, Ville)
v4: Make a few more optimizations. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Wayne Boyer <wayne.boyer@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Cancel hangcheck before GPU is suspended

In order to avoid accessing GPU registers while GPU is suspended cancel
the hangcheck work before calling intel_suspend_complete which actually
puts the GPU to suspend. Otherwise hangcheck might do MMIO reads to a
suspended GPU.

Placement before intel_guc_suspend is imitated from i915_drm_suspend
which cancels the work at i915_gem_suspend, to keep the functions
similar.

On VLV systems, namely BYT, this was causing an error during runtime
suspend cycle:

[drm:vlv_check_no_gt_access [i915]] *ERROR* GT register access while GT waking disabled

Testcase: igt/pm_rpm/basic-rte
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93121

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1449669373-8588-1-git-send-email-joonas.lahtinen@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>

drm/i915: start adding dp mst audio

This patch adds support for DP MST audio in i915.

Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.

Another separated patches to support DP MST audio will be implemented
in audio driver.

Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-2-git-send-email-libin.yang@linux.intel.com

dp/mst: add SDP stream support

This adds code to initialise the SDP streams
for a sink in the simplest ordering.

I've no idea how you'd want to control the
ordering at this level, so don't bother
until someone comes up with a use case.

Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-1-git-send-email-libin.yang@linux.intel.com

drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e} macros

All of these iterator macros require a 'temp' argument, used merely to
hold internal partial results. We can instead declare the temporary
variable inside the macro, so the caller need not provide it.

Some of the old code contained nested iterators that actually reused the
same 'temp' variable for both inner and outer instances. It's quite
surprising that this didn't introduce bugs! But it does show that the
value of 'temp' isn't required to persist during the iterated body.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449581451-11848-2-git-send-email-david.s.gordon@intel.com

drm/i915/kbl: Fix DMC load on Kabylake.

Kabylake A0 is based on Skylake H0.

v2: Don't assume revid+7 and only load the one we are sure about.

v3: Rebase on top of latest changes.

v4: Accept cleaner solution from Jani with kbl_stepping_info
    starting on H0 instead of put a hack on revid.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449676319-6959-1-git-send-email-rodrigo.vivi@intel.com

drm/i915: check for return value

We were not checking the return value of drm_encoder_init() which can
fail. And if it fails then we will be working with an uninitialized
encoder.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1444312681-10149-2-git-send-email-sudipm.mukherjee@gmail.com

drm/i915: Add soft-pinning API for execbuffer

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
(Not published externally)

v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
to allow eviction of soft-pinned objects when another soft-pinned object used
by a subsequent execbuffer overlaps reported by Michal Winiarski.
(Not published externally)

v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
pinned first after an address conflict happens to avoid repeated conflicts in
rare cases (Suggested by Chris Wilson).  Expanded comment on
drm_i915_gem_exec_object2.offset to cover this new API.

v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
(Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
buffers are not considered misplaced without the user specifying
EXEC_OBJECT_SUPPORTS_48B_ADDRESS.  User must assume responsibility for any
addressing workarounds.  Updated object2.offset field comment again to clarify
NO_RELOC case (Chris).  checkpatch cleanup.

v6: Trivial rebase on latest drm-intel-nightly

v7: Catch attempts to pin above the max virtual address size and return
EINVAL (Tvrtko). Decouple EXEC_OBJECT_SUPPORTS_48B_ADDRESS and
EXEC_OBJECT_PINNED flags, user must pass both flags in any attempt to pin
something at an offset above 4GB (Chris, Daniel Vetter).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Kristian Høgsberg <hoegsberg@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: PDT
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449575707-20933-1-git-send-email-thomas.daniel@intel.com

drm/i915: constify intel_dvo_dev_ops structures

The intel_dvo_dev_ops structures are never modified, so declare them as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449608127-21715-1-git-send-email-Julia.Lawall@lip6.fr

drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake.

GuC has no version for KBL published yet and it is not recommended
to load the Skylake one, so let's avoid loading this for now while
we don't have the proper GuC firmware for Kabylake.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449622718-21684-1-git-send-email-rodrigo.vivi@intel.com

drm/i915/kbl: Use propper ddi buffer translation table for Kabylake ULT and ULX.

Let's introduce ULT and ULX Kabylake definitions and start
using it for a propper DDI buffer translation.

v2: Remove extra white space. (Paulo)

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

drm/i915: vlv: clamp minimum RPS frequency to what Punit allows

As described in the code comment, I couldn't set the minimum RPS
frequency on my BYT-M B0 to the minimum allowed as reported by Punit.
Fix this by clamping the minimum value to the first one that was
accepted on my machine.

Atm this issue doesn't cause any test failures, since in igt/pm_rps we
only check the cached version of the current frequency which is the same
what has been set. In the future we'll add checks for the actual
frequency too, and for that to pass this fix is necessary.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1417711175-13271-1-git-send-email-imre.deak@intel.com

drm/i915: Leave FDI running after failed link training on LPT-H

Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
crtc enabling, nor for crtc disabling.

Ideally we should abort the modeset and follow the proper disable
sequence to shut off everything we enabled so far, but that would
require a big rework of the modeset code. So instead just leave FDI
up and running in its untrained state, and log an error. This is
what we do on older platforms too.

v2: Fix a typo in the commit message

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260570-14670-1-git-send-email-ville.syrjala@linux.intel.com

drm/i915: Disable LPT-H VGA dotclock during crtc disable

Currently we leave the LPT-H VGA dotclock running after turning
the pipe/fdi/port/etc. Properly disable the VGA dotclock as
specified in the modeset sequence.

v2: Fix commit message typo (Paulo)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260534-14551-1-git-send-email-ville.syrjala@linux.intel.com