The core fix was applied in

commit a63b03e2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 6 10:29:35 2015 +0000

    mutex: Always clear owner field upon mutex_unlock()

(note the absence of stable@ tag)

so we can now revert our band-aid commit 226e5ae9 for -next.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have had %x and %u intermixed. Bring everything in line and
use %x
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For example,

/sys/kernel/debug/dri/0/i915_hangcheck_info:

Hangcheck active, fires in 15887800ms
render ring:
        seqno = -4059 [current -583]
        action = 2
        score = 0
        ACTHD = 1ee8 [current 21f980]
        max ACTHD = 0

v2: Include expiration ETA. Can anyone spot a problem?
v3: Convert for workqueued hangcheck (Mika)
v4: Print seqnos as unsigned ints (Ville)
v5: Print seqnos as hex (Chris)

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When run as a timer, i915_hangcheck_elapsed() must adhere to all the
rules of running in a softirq context. This is advantageous to us as we
want to minimise the risk that a driver bug will prevent us from
detecting a hung GPU. However, that is irrelevant if the driver bug
prevents us from resetting and recovering. Still it is prudent not to
rely on mutexes inside the checker, but given the coarseness of
dev->struct_mutex doing so is extremely hard.

Give in and run from a work queue, i.e. outside of softirq.

v2: Use own workqueue to avoid deadlocks (Daniel)
    Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: Remove accidental kerneldoc comment starter, to appease the 0
day builder.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT (when using WC updates of the
PTE values). This is despite there being a posting read after the GTT
update. However, by changing the address of the posting read, the memory
access is indeed serialised correctly.

Whilst we are manipulating the memory barriers, we can remove the
compiler :memory restraint on the intermediate PTE writes knowing that
we explicitly perform a posting read afterwards.

v2: Replace posting reads with explicit write memory barriers - in
particular this is advantages in case of single page objects. Update
comments to mention this issue is only with WC writes.

Testcase: igt/gem_exec_big #pnv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
Tested-by: huax.lu@intel.com (v1)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent
with the code and the rest of the comment for this routine. This patch
fixes this typo in comment.
Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't have full atomic modeset support yet, but the "nuclear
pageflip" subset of functionality (i.e., plane operations only) should
be ready.  Allow the user to force atomic on for debug purposes, or for
fixed-purpose embedded devices that will only use atomic for plane
updates.

The term 'nuclear' is used here instead of 'atomic' to make it clear
that this doesn't allow full atomic modeset support, just a (very
useful) subset of the atomic functionality.

We'll drop the kernel parameter and unconditionally enable atomic in a
future patch once all of the necessary pieces are in.

v2:
 - Use module_param_named_unsafe() (Daniel)
 - Simplify comment on DRIVER_ATOMIC guard (Daniel)

v3:
 - Make the parameter "nuclear_pageflip" rather than just "nuclear"
   for clarity. (Ander)

v4:
 - Make the internal variable "nuclear_pageflip" as well as the
   command-line option. (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will exercise our atomic pipeline for legacy property updates.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The atomic helpers need these to prepare a new state object when
starting a new atomic operation.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Even though we only support atomic plane updates at the moment, we still
need to add an .atomic_get_property() entrypoint for connectors before
we allow the driver to flip on the DRIVER_ATOMIC bit.  As soon as that
bit gets set, the DRM core will start adding atomic connector properties
(in addition to the plane properties we care about at the moment), so we
need to be able to handle the new way the DRM core will interact with
us.

For simplicity, we just lookup driver-specific connector properties in
the usual shadow array maintained by the core.  Once we get real atomic
modeset support for crtc's and planes, this code should be re-written to
pull the data out of crtc/connector state structures.

v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to enable/test plane updates via the atomic interface, but as
soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
codepaths to lookup properties during drmModeGetConnector() and some of
those codepaths unconditionally dereference connector->state
(specifically when looking up the CRTC ID property in
drm_atomic_connector_get_property()).  Create a dummy connector state
for each connector at init time to ensure the DRM core doesn't try to
dereference a NULL connector->state.  The actual connector properties
will never be updated or contain useful information, but since we're
doing this specifically for testing/debug of the plane operations (and
only when a specific kernel module option is given), that shouldn't
really matter.

Once we start creating connector states, the DRM core will want to be
able to clean them up for us.  We also need to hook up the destruction
entrypoint to the core's helper.

v2: Squash in the patch to set the state destruction hook (Ander & Bob)

v3: Only create dummy connector states when we're actually faking
    atomic support.  (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add the top-level atomic entrypoints for check/commit.  These won't get
called yet; we still need to either enable the atomic ioctl or switch to
using the non-transitional atomic helpers for legacy operations.

v2:
 - Use plane->pipe rather than plane->possible_crtcs while ensuring that
   only a single CRTC is in use.  Either way will work fine since i915
   drm_plane's are always tied to a single CRTC, but plane->pipe is
   slightly more intuitive. (Ander)
 - Simplify crtc/connector checking logic. (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling
this entrypoint to set and lookup driver-specific plane property values,
rather than maintaining a shadow copy in object->properties.

Note that although we add these functions to the plane vtable, they will
not yet be called.  Future patches that switch our .set_property()
handler and/or enable full atomic functionality are required before
these code paths will be executed.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All of the previous refactoring/consolidation of plane code has resulted
in intel_primary_plane_funcs, intel_cursor_plane_funcs, and
intel_sprite_plane_funcs being identical.  Replace all of these with a
single 'intel_plane_funcs' vtable for simplicity.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Runtime state that can be manipulated via properties should now go in
intel_plane_state/drm_plane_state so that it can be tracked as part of
an atomic transaction.

We add a new 'intel_create_plane_state' function so that the proper
initial value for this property (and future properties) doesn't have to
be repeated at each plane initialization site.

v2:
 - Stick rotation in common drm_plane_state rather than
   intel_plane_state. (Daniel)
 - Add intel_create_plane_state() to consolidate the places where we
   have to set initial state values.  (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Replace all the vlv_gpu_freq(), vlv_freq_opcode(),
*GT_FREQUENCY_MULTIPLIER, and /GT_FREQUENCY_MULTIPLIER instances
with intel_gpu_freq() and intel_freq_opcode() calls.

Most of the change was performed with the following semantic patch:
@@
expression E;
@@
(
- E * GT_FREQUENCY_MULTIPLIER
+ intel_gpu_freq(dev_priv, E)
|
- E *= GT_FREQUENCY_MULTIPLIER
+ E = intel_gpu_freq(dev_priv, E)
|
- E /= GT_FREQUENCY_MULTIPLIER
+ E = intel_freq_opcode(dev_priv, E)
|
- do_div(E, GT_FREQUENCY_MULTIPLIER)
+ E = intel_freq_opcode(dev_priv, E)
)

@@
expression E1, E2;
@@
(
- vlv_gpu_freq(E1, E2)
+ intel_gpu_freq(E1, E2)
|
- vlv_freq_opcode(E1, E2)
+ intel_freq_opcode(E1, E2)
)

@@
expression E1, E2, E3, E4;
@@
(
- if (IS_VALLEYVIEW(E1)) {
-  E2 = intel_gpu_freq(E3, E4);
- } else {
-  E2 = intel_gpu_freq(E3, E4);
- }
+ E2 = intel_gpu_freq(E3, E4);
|
- if (IS_VALLEYVIEW(E1)) {
-  E2 = intel_freq_opcode(E3, E4);
- } else {
-  E2 = intel_freq_opcode(E3, E4);
- }
+ E2 = intel_freq_opcode(E3, E4);
)

One hunk was manually undone as intel_gpu_freq() ended up
calling itself. Supposedly it would be possible to exclude
certain functions via !=~, but I couldn't get that to work.

Also the removal of vlv_gpu_freq() and vlv_opcode_freq() compat
wrappers was done manually.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rename the vlv_gpu_freq() and vlv_freq_opecode() functions to have
an intel_ prefix, and handle non-VLV/CHV platforms in them as well.
Leave the vlv_ names around for now since they're currently used.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on
VLV/CHV, and the last requested frequency on other platforms. Change the
meaning of the file on VLV/CHV to follow the the other platforms, and
introduce a new file 'gt_act_freq_mhz' which shows the actual frequency
on all platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we don't call valleyview_set_rps() when changing the min/max
limits through sysfs if the current frequency is still within the new
limits. However that means we sometimes forget to update PMINTRMSK.
Eg. if the current frequency is at the old minimum, and then we reduce
the minum further we should then enable the 'down' interrupts in PMINTRMSK
but currently we don't.

Fix it up by always calling valleyview_set_rps() (just like we do for
!vlv/chv platforms). This also allows the code to be simplified a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip calls.
The call to fb_obj_invalidate (in flip) is placed before queuing flip for this
obj.

drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if
it was setup in drrs_enable(). This covers for the condition when DRRS is
not supported.

v2: Removing the call to invalidate_drrs from page_flip.
This has not been tested on Android yet, but, in case DRRS transtions do not
work as expected, check by adding back this call in page_flip.
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Calling enable/disable DRRS when enable/disable DDI are called.
These functions are responsible for setup of drrs data (in enable) and
reset of drrs (in disable).
has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in
the VBT. A check has been added for has_drrs in these functions, to make
sure the functions go through only if DRRS will work on the platform with
the attached panel.

V2: [By Ram]: WARN_ON is used when intel_edp_drrs_enable() is called more than
once [Rodrigo]
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add DRRS work function to trigger a switch to low refresh rate,
when no activity is detected on screen till 1 sec duration.

v2: [By Ram]: drrs.dp also protected with drrs.mutex and worker function
is renamed to intel_edp_drrs_downclock_work [Chris]
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Self-explanatory code is better code.

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Const is good for you. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove all the trivial and/or dummy callbacks from intel dsi device
ops. Merge send_otp_cmds into panel_reset as they're called back to
back.

This will be helpful for switching to use drm_panel for the
callbacks. If we ever need the additional callbacks, we should add them
to drm_panel funcs.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
[danvet: Resolve tiny conflict with ongoing atomic work.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add port parameter to wait_for_dsi_fifo_empty, and call it for each dsi
port.

We can now remove the transitional intel_dsi_pipe_to_port() function.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

wait_for_dsi_fifo_empty can be static in intel_dsi.c. No functional
changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This seems like the right thing to do. This also gets rid of a call to
intel_dsi_pipe_to_port() which we want to remove eventually.

v2: add braces to fix else logic (Shobhit)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of having the for each dsi port loop within dpi_send_cmd(), add
a port parameter to the function and call it for each port instead.

This is a rewrite of

commit 4510cd77
Author: Gaurav K Singh <gaurav.k.singh@intel.com>
Date:   Thu Dec 4 10:58:51 2014 +0530

    drm/i915: Dual link needs Shutdown and Turn on packet for both ports

to add more flexibility in using dpi_send_cmd() for just one port as
necessary. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We set the WIZ hashing mode to 16x4 for all the other gen6+
platfotrms, so let's follow suit on VLV.

My VLV is AWOL currently so I didn't test this, but since the results
for all the other platforms agree that 16x4 is the fastest we might
assume the same holds for VLV.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I ran a few tests with xonotic and synmark2 trying out the
different WIZ hashing modes on CHV. The results seem to match the
results I got with IVB/HSW when I did the similar tests on them
in the past. That is 16x4 is generally the fastest mode, 8x8 comes
next and finally 8x4. On CHV the difference between the modes is
at most ~1% in most tests. IIRC on IVB/HSW the difference was a little
bigger, but as there doesn't seem to be any real downside to 16x4
let's use it by default.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drop WaDisablePwrmtrEvent:chv as it's no longer needed.

Also remove the WaSetMaskForGfxBusyness:chv note, but we still
leave the GEN6_RP_MEDIA_IS_GFX bit enabled as that's still the
recommended setting.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wa4x4STCOptimizationDisable got only implemented for BDW, but according
to the w/a database CHV needs it too, so add it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can push down the decision whether to force flushing into the
implementation since in all places that matter obj->pin_display is
accurate already. The only place where the optimization really matters
is the sw_finish_ioctl, and that already checks for obj->pin_display
on its own.

I suspect that this was simply an artifact of how

commit 2c22569b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 9 12:26:45 2013 +0100

    drm/i915: Update rules for writing through the LLC with the cpu

evolved - only v2 added the pin_display tracking.

Note that we still retain the gist of this logic from the above commit
with the explicit force argument for the low-level clflush function.

Ville noted in his review that there's a slight behavioural change in
the set_to_gtt_domain function, which now also will flush display
plane data. This opens-open the potential for userspace to start doing
buggy things by omitting the sw_finish_ioctl, which is why I've
rejected a functional equivalent patch from Ville a while ago:

http://lists.freedesktop.org/archives/intel-gfx/2013-November/036421.html

But on second consideration it's not that evil, and in any case the
justification here is more clarity, not allowing crazy userspace.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Smatch doesn't like:

  struct drm_framebuffer *fb;
  fb = kzalloc(sizeof(struct intel_framebuffer), GFP_KERNEL);

and warns with:

  warn: struct type mismatch 'drm_framebuffer vs intel_framebuffer'

This implicit cast was correct as struct intel_framebuffer has struct
drm_framebuffer as its first member, but in case someone want to reorder
the fields for some reason, it's slightly safer to access the underlying
drm_framebuffer through intel_fb->base.

Also, having fewer static analysis warnings is a worthy goal.

Cc: kbuild@01.org
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we are hitting the WARN inside
i915_gem_object_set_cache_level() as we can now have an unbound object
in the GTT write domain (due to 43566ded "drm/i915: Broaden
application of set-domain(GTT)"). To avoid the warning, we need to track
when we elided the clflush on a cacheable object and then evict the
cache for the object when we move the object out of a cacheable domain.
Reported-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NJani Nikula <jani.nikula@intel.com>
Testcase: igt/gem_mmap_wc/set-cache-level
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88607
Tested-by: huax.lu@intel.com
[danvet: Split if into nested if as discussion on the m-l.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We increase it when we pin, so for the casual reader
rename it to cause less confusion.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We pin when we submit to execlist queue. Balance
the pinning when the submitted queue is cleaned on reset.

Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will let userland only try to use the new ring
when the appropriate kernel is present

v2: change the number to be consistent with upstream (Zhipeng)
Signed-off-by: NZhipeng Gong <zhipeng.gong@intel.com>
Reviewed--by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>