This reverts commit 60f2b4af.

The same warning has been fixed in e5081a53 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
difference to unsigned long and the other commit changed the output type from
long to ptrdiff_t.

The other commit fixes the original warning the better way so I'm reverting
this commit now.
Signed-off-by: NJan Moskyto Matejka <mq@suse.cz>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a struct_mutex deadlock during driver init on ILK

[   54.320273] =============================================
[   54.320371] [ INFO: possible recursive locking detected ]
[   54.320471] 3.15.0-rc2-flip_race+ #2 Not tainted
[   54.320567] ---------------------------------------------
[   54.320665] modprobe/2178 is trying to acquire lock:
[   54.320762]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0568b05>] intel_enable_gt_powersave+0xa5/0x9d0 [i915]
[   54.321111]
[   54.321111] but task is already holding lock:
[   54.321250]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]
[   54.321583]
[   54.321583] other info that might help us debug this:
[   54.321724]  Possible unsafe locking scenario:
[   54.321724]
[   54.321863]        CPU0
[   54.321954]        ----
[   54.322046]   lock(&dev->struct_mutex);
[   54.322221]   lock(&dev->struct_mutex);
[   54.322397]
[   54.322397]  *** DEADLOCK ***
[   54.322397]
[   54.322638]  May be due to missing lock nesting notation
[   54.322638]
[   54.322781] 4 locks held by modprobe/2178:
[   54.322875]  #0:  (&dev->mutex){......}, at: [<ffffffff813592eb>] __driver_attach+0x5b/0xb0
[   54.323230]  #1:  (&dev->mutex){......}, at: [<ffffffff813592f9>] __driver_attach+0x69/0xb0
[   54.323582]  #2:  (drm_global_mutex){+.+.+.}, at: [<ffffffffa04e1e0d>] drm_dev_register+0x2d/0x120 [drm]
[   54.323945]  #3:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]

This regression got introduced in:
 commit 586d5270b60dc1f35cc3ca982d403765bad77965
 Author: Imre Deak <imre.deak@intel.com>
 Date:   Mon Apr 14 20:24:28 2014 +0300

    drm/i915: move getting struct_mutex lower in the callstack during GPU reset

Fix the problem by not taking struct_mutex around intel_enable_gt_powersave()
in intel_modeset_init_hw() since intel_enable_gt_powersave() now grabs the
mutex itself.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In recent dmesg logs reported for unrelated issues I noticed some power
domain WARNs caused by the following.

The workaround

commit ce352550
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 20 10:14:23 2013 +0300

    drm/i915: Fix unclaimed register access due to delayed VGA memory disable

and following fixup of it

commit a1485320
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 16 17:38:34 2013 +0300

    drm/i915: Move power well init earlier during driver load

was partially reverted by

commit 7f16e5c1
Merge: 9d1cb914 5e01dc7b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 4 16:28:47 2013 +0100

    Merge tag 'v3.12' into drm-intel-next

but kept the power domain put calls on the error path.

I think for now we can keep things as-is (not reintroduce the w/a) and just fix
the error path, since
- nobody complained seeing this issue
- according to Ville someone is reworking the VGA arbitration scheme at the
  moment and when that's ready we have to rethink this part anyway

So fix this by just removing the put calls from the error path as well.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ville noticed that we have this nice kerneldoc but it's not integrated
anywhere. Fix this asap!

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A common issue we have is that retiring requests causes recursion
through GTT manipulation or page table manipulation which we can only
handle at very specific points. However, to maintain internal
consistency (enforced through our sanity checks on write_domain at
various points in the GEM object lifecycle) we do need to retire the
object prior to marking it with a new write_domain, and also clear the
write_domain for the implicit flush following a batch.

Note that this then allows the unbound objects to still be on the active
lists, and so care must be taken when removing objects from unbound lists
(similar to the caveats we face processing the bound lists).

v2: Fix i915_gem_shrink_all() to handle updated object lifetime rules,
by refactoring it to call into __i915_gem_shrink().

v3: Missed an object-retire prior to changing cache domains in
i915_gem_object_set_cache_leve()

v4: Rebase
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NBrad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

lib/interval_tree.c provides a simple interface for an interval-tree
(an augmented red-black tree) but is only built when testing the generic
macros for building interval-trees. For drivers with modest needs,
export the simple interval-tree library as is.

v2: Lots of help from Michel Lespinasse to only compile the code
    as required:
    - make INTERVAL_TREE a config option
    - make INTERVAL_TREE_TEST select the library functions
      and sanitize the filenames & Makefile
    - prepare interval_tree for being built as a module if required
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: NMichel Lespinasse <walken@google.com>
[Acked for inclusion via drm/i915 by Andrew Morton.]
[danvet: switch to _GPL as per the mailing list discussion.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've seen latencies up to 15msec, so increase the timeout to 20msec.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed by the VLV runtime PM helpers too, so factor it out.

Also add a safety check for the case where the previous force-off is
still pending, since I'm not sure if Punit can handle a new setting
while the previous one hasn't settled yet.

v2:
- unchanged
v3:
- add a note to the commit message about the safety check (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When enabling runtime PM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During runtime suspend there can be a last pending rps.work, so make
sure it's canceled. Note that in the runtime suspend callback we can't
get any RPS interrupts since it's called only after the GPU goes idle
and we set the minimum RPS frequency. The next possibility for an RPS
interrupt is only after getting an RPM ref (for example because of a new
GPU command) and calling the RPM resume callback.

v2:
- patch introduced in v2 of the patchset
v3:
- Change the order of canceling the rps.work and disabling interrupts to
  avoid the race between interrupt disabling and the the rps.work. Race
  spotted by Ville.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.

No functional change.

v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.

On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On VLV we depend on RC6 to save the GT render and media HW context
before going to the D3 state via RPM, so as a preparation for the
VLV RPM support (added in an upcoming patch) disable RPM if RC6 is
disabled.

There is probably a similar dependency on other platforms too, so for
safety require RC6 for those too. For these platforms (SNB, HSW, BDW)
this is then a possible fix.

v2:
- require RC6 for all RPM platforms, not just for VLV (Paulo, Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the caller would have to filter a non-zero return
value based on the platform we are running on. For example on VLV with
i915.enable_rc6 set to 2, RC6 won't be enabled but atm
intel_enable_rc6() would still return 2 in this case.

v2:
- simplify the platform check condition (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm, we call intel_gt_powersave_enable() for GEN6 and GEN7 but disable
it for everything starting from GEN6. This is a problem in case of BDW.
Since I don't have a BDW to test if RC6 works properly, just keep it
disabled for now and fix only the disable function.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.

Suggested by Daniel.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.

The move also revealed that we actually don't include this register in
the error report, so fix that too.

v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
  that it's the same as !HAS_PCH_SPLIT. ]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
getting an RPM reference around accessing the HW in the reset work.

v2:
- Instead of getting/putting the RPM reference in the reset work itself,
  get it already before scheduling the work. By this we also prevent
  going to D3 before the work gets to run, in addition to making sure
  that we run the work itself in D0. (Ville, Daniel)
v3:
- fix inverted logic fail when putting the RPM ref on behalf of a
  cancelled GPU reset work (Ville)
v4:
- Taking the RPM ref in the interrupt handler isn't really needed b/c
  it's already guaranteed that we hold an RPM ref until the end of the
  reset work in all cases we care about. So take the ref in the reset
  work (for cases like i915_wedged_set). (Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

At least on VLV but probably on other platforms too we depend on RC6
being enabled for RPM, so disable RPM until the delayed RC6 enabling
completes.

v2:
- explain the reason for the _noresume version of RPM get (Daniel)
- use the simpler 'if (schedule_work()) rpm_get();' instead of
  'if (!cancel_work_sync()) rpm_get(); schedule_work();'
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Getting struct_mutex around the whole intel_enable_gt_powersave()
function is not necessary, since it's only needed for the ILK path
therein.

This will make intel_enable_gt_powersave() useable on the RPM resume
path for >=GEN6 (added in an upcoming patch to reset the RPS state
during RPM resume), where we can't (and need not) get this mutex.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These debugfs entries access registers that need the D0 power state so
get an RPM ref for them.

v2:
- for all these entries we only need D0 state, so get only an RPM ref,
  not a power domain ref (Daniel, Paulo)
- the dpio entry is not an issue any more as it got removed (Ville)
- restore commit message from v1 (Paulo)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are igt tools that can read/write the DPIO registers, so having a
debugfs entry for only some of those registers is somewhat arbitrary /
redundant. Remove it.

v2:
- instead of fixing the entry by taking a power domain reference around
  the register accesses, remove the entry (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The parsing was incorrect for ILK and VLV.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Not clearing this flag causes spurious interrupts at least in D3 state,
so before enabling RPM we need to fix this. We were already setting this
flag when enabling interrupts, only clearing it was missing.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.

As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case it can play back video stream while encoding
another video stream. The coarse ping-pong mechanism is used to determine
which BSD ring is used to dispatch the BSD video command.

V1->V2: Follow Daniel's comment and use the simple ping-pong mechanism.
This is only to add the support of dual BSD rings on BDW GT3 machine.
The further optimization will be considered in another patch set.

V2->V3: Follow Daniel's comment to use the struct_mutext instead of
atomic_t during determining which ring can be used to dispatch Video command.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.

V1->V2: Follow Daniel's comment to update the comment
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.

V3->V4: Follow Imre's comment to do some minor updates. For example:
more comments are added to describe the semaphore between ring.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[danvet: Fix up checkpatch error.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.

V1->V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in kernel/early-quirks.c
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to make sure that userspace keeps on following the contract,
otherwise we won't be able to use the reserved fields at all.

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/*-dirt
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A bit tricky since 0 is also a valid constant ...

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/rel-constants-*
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we catch it, but silently succeed. Our userspace is
better than this.

v2: Add DRM_DEBUG (Chris)

Testcase: igt/gem_exec_params/sol-reset-*
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we include the expected values for the failing ring register checks,
it makes it marginally easier to see which is the culprit.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>