Commit Graph

443805 Commits

Author SHA1 Message Date
Daniel Vetter
a071fa0064 drm/i915: Introduce accurate frontbuffer tracking
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj->pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects and figure out where exactly a buffer is
used as scanout.

Except that we can't due to locking order: If we already hold
dev->struct_mutex we can't acquire any modeset locks, so could
potential chase freed pointers and other evil stuff.

So we need something else. For that introduce a new set of bits
obj->frontbuffer_bits to track where a buffer object is used. That we
can then chase without grabbing any modeset locks.

Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be
able to do their magic both when called from modeset and from gem
code. But that can be easily achieved by adding locks for these
specific subsystems which always nest within either kms or gem
locking.

This patch just adds the relevant update code to all places.

Note that if we ever support multi-planar scanout targets then we need
one frontbuffer tracking bit per attachment point that we expose to
userspace.

v2:
- Fix more oopsen. Oops.
- WARN if we leak obj->frontbuffer_bits when freeing a gem buffer. Fix
  the bugs this brought to light.
- s/update_frontbuffer_bits/update_fb_bits/. More consistent with the
  fb tracking functions (fb for gem object, frontbuffer for raw bits).
  And the function name was way too long.

v3: Size obj->frontbuffer_bits correctly so that all pipes fit in.

v4: Don't update fb bits in set_base on failure. Noticed by Chris.

v5: s/i915_gem_update_fb_bits/i915_gem_track_fb/ Also remove a few
local enum pipe variables which are now no longer needed to make the
function arguments no drop over the 80 char limit.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-19 10:04:41 +02:00
Daniel Vetter
3108e99ea9 drm/i915: Drop schedule_back from psr_exit
It doesn't make sense to never again schedule the work, since by the
time we might want to re-enable psr the world might have changed and
we can do it again.

The only exception is when we shut down the pipe, but that's an
entirely different thing and needs to be handled in psr_disable.

Note that later patch will again split psr_exit into psr_invalidate
and psr_flush. But the split is different and this simplification
helps with the transition.

v2: Improve the commit message a bit.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-19 09:59:19 +02:00
Daniel Vetter
e6e559d4a9 drm/i915: Ditch intel_edp_psr_update
We have _enable/_disable interfaces now for the modeset sequence and
intel_edp_psr_exit for workarounds.

The callsites in intel_display.c are all redundant with the modeset
sequence enable/disable calls in intel_ddi.c. The one in
intel_sprite.c is real and needs to be switched to psr_exit.

If this breaks anything then we need to augment the enable/disable
functions accordingly.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-19 09:58:58 +02:00
Daniel Vetter
77c70c5667 drm/i915: Drop unecessary complexity from psr_inactivate
It's not needed and further more will get in the way of a sane
locking scheme - psr_exit _can't_ take modeset locks due to lock
inversion, and at least once dp mst hits the connector list
is no longer static.

But since we track all state in dev_priv->psr there is no need
at all.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-19 09:58:52 +02:00
Oscar Mateo
14d8ec544f drm/i915: Remove ctx->last_ring
The original comment that introduced it said:

commit 0009e46cd5
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Dec 6 14:11:02 2013 -0800

    drm/i915: Track which ring a context ran on

    Previously we dropped the association of a context to a ring. It is
    however very important to know which ring a context ran on (we could
    have reused the other member, but I was nitpicky).

    This is very important when we switch address spaces, which unlike
    context objects, do change per ring.

    As an example, if we have:

            RCS   BCS
    ctx            A
    ctx      A
    ctx      B
    ctx            B

    Without tracking the last ring B ran on, we wouldn't know to switch the
    address space on BCS in the last row.

But this is not really true, because we are already checking to != from (with
"from" being = ring->last_context) and that should be enough to make sure we
switch to the right address space.

We would have a problem if we switched the context object for every ring (since
then we would fail to do it in some situations) but we only switch it for the
render ring, so we don't care.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 21:42:42 +02:00
Daniel Vetter
5d0cf3d6e0 Merge branch 'topic/soix' into drm-intel-next-queued
Jesse's SOix work required some patches from acpi-next, so pull it in
through a topic barnch.

Conflicts:
	drivers/gpu/drm/i915/i915_drv.c
	drivers/gpu/drm/i915/intel_pm.c

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 11:44:05 +02:00
Oscar Mateo
27b6c12251 drm/i915/chv: Ack interrupts before handling them (CHV)
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.

Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).

Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.

Spotted by Bob Beckett <robert.beckett@intel.com>.

v2:
- Add warning to commit message and comments to the code as per Chris
  Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
  in IIR, so do not make valleyview_pipestat_irq_handler depend on it.

v3: Improve the source code comment.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:49:37 +02:00
Oscar Mateo
38cc46d73e drm/i915/bdw: Ack interrupts before handling them (GEN8)
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.

The right order should be:

1 - Disable Master Interrupt Control.
2 - Find the category of interrupt that is pending.
3 - Find the source(s) of the interrupt and clear the Interrupt Identity bits (IIR)
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.

Without an atomic XCHG operation with mmio space, the above merely reduces the window
in which we can miss an interrupt (especially when you consider how heavyweight the
I915_READ/I915_WRITE operations are).

Spotted by Bob Beckett <robert.beckett@intel.com>.

v2: Add warning to commit message and comments to the code as per Chris Wilson's request.

v3: Improve the source code comment.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:49:18 +02:00
Oscar Mateo
3ff60f89bc drm/i915/vlv: Ack interrupts before handling them (VLV)
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.

Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).

Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.

Spotted by Bob Beckett <robert.beckett@intel.com>.

v2:
- Reorder the IIR clearing to reduce the window even further.
- Add warning to commit message and comments to the code as per Chris
  Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
  in IIR, so do not make valleyview_pipestat_irq_handler depend on it.

v3: Improve the source code comment.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:38 +02:00
Oscar Mateo
72c90f625c drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
Otherwise, we might receive a new interrupt before we have time to ack the first
one, eventually missing it.

According to BSPec, the right order should be:

1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR).
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.

Without an atomic XCHG operation with mmio space, the above merely reduces the window
in which we can miss an interrupt (especially when you consider how heavyweight the
I915_READ/I915_WRITE operations are).

We maintain the "disable SDE interrupts when handling" hack since apparently it works.

Spotted by Bob Beckett <robert.beckett@intel.com>.

v2: Add warning to commit message and comments to the code as per Chris Wilson's request.
v3: Improve the source comments.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:37 +02:00
Daniel Vetter
f25748ea73 drm/i915: Don't BUG_ON in i915_gem_obj_offset
A WARN_ON is perfectly fine.

The BUG in here seems to be the cause behind hard-hangs when I cat the
i915_gem_pageflip debugfs file (which calls this from an irq
spinlock). But only while running a full igt run after a while. I
still need to root cause the underlying issue.

I'll also start reject patches which add new BUG_ON but don't come
with a really good justification for it. The general rule really
should be to just WARN and hope the driver survives for long enough.

v2: Make the WARN a bit more useful per Chris' suggestion.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:37 +02:00
Daniel Vetter
8a270ebf34 drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info
We could walk of a bad list otherwise when someone concurrently
unbinds stuff for fun.

I've suspected this as the root-cause behind seemingly inconsistent
state, but alas it's not.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:36 +02:00
Brad Volkin
c9224faa59 drm/i915: Add some L3 registers to the parser whitelist
Beignet needs these in order to program the L3 cache config for
OpenCL workloads, particularly when using SLM.

Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:35 +02:00
Ville Syrjälä
beff0d0f61 drm/i915: Don't prefault the entire obj if the vma is smaller
Take the minimum of the object size and the vma size and prefault
only that much. Avoids a SIGBUS when mmapping only a portion of the
object.

Prefaulting was introduced here:
 commit b90b91d870
 Author: Chris Wilson <chris@chris-wilson.co.uk>
 Date:   Tue Jun 10 12:14:40 2014 +0100

    drm/i915: Prefault the entire object on first page fault

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Testcase: igt/gem_mmap/short-mmap
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-18 00:48:35 +02:00
Sourab Gupta
84c33a64b4 drm/i915: Replaced Blitter ring based flips with MMIO flips
This patch enables the framework for using MMIO based flip calls,
in contrast with the CS based flip calls which are being used currently.

MMIO based flip calls can be enabled on architectures where
Render and Blitter engines reside in different power wells. The
decision to use MMIO flips can be made based on workloads to give
100% residency for Media power well.

v2: The MMIO flips now use the interrupt driven mechanism for issuing the
flips when target seqno is reached. (Incorporating Ville's idea)

v3: Rebasing on latest code. Code restructuring after incorporating
Damien's comments

v4: Addressing Ville's review comments
    -general cleanup
    -updating only base addr instead of calling update_primary_plane
    -extending patch for gen5+ platforms

v5: Addressed Ville's review comments
    -Making mmio flip vs cs flip selection based on module parameter
    -Adding check for DRIVER_MODESET feature in notify_ring before calling
     notify mmio flip.
    -Other changes mostly in function arguments

v6: -Having a seperate function to check condition for using mmio flips (Ville)
    -propogating error code from i915_gem_check_olr (Ville)

v7: -Adding __must_check with i915_gem_check_olr (Chris)
    -Renaming mmio_flip_data to mmio_flip (Chris)
    -Rebasing on latest nightly

v8: -Rebasing on latest code
    -squash 3rd patch in series(mmio setbase vs page flip race) with this patch
    -Added new tiling mode update in intel_do_mmio_flip (Chris)

v9: -check for obj->last_write_seqno being 0 instead of obj->ring being NULL in
intel_postpone_flip, as this is a more restrictive condition (Chris)

v10: -Applied Chris's suggestions for squashing patches 2,3 into this patch.
These patches make the selection of CS vs MMIO flip at the page flip time, and
make the module parameter for using mmio flips as tristate, the states being
'force CS flips', 'force mmio flips', 'driver discretion'.
Changed the logic for driver discretion (Chris)

v11: Minor code cleanup(better readability, fixing whitespace errors, using
lockdep to check mutex locked status in postpone_flip, removal of __must_check
in function definition) (Chris)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # snb, ivb
[danvet: Fix up parameter alignement checkpatch spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-17 16:16:20 +02:00
Daniel Vetter
f02a326e32 drm/i915: Add missing statics to recent psr functions
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-17 10:46:21 +02:00
Daisy Sun
032843a5a5 drm/i915: Broaden FBC resolution limit to 4096*4096
Staring from HSW, the resolution limit of FBC has increased to
4096*4096

Issue: VIZ-2813
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun <daisy.sun@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-17 10:46:12 +02:00
Akash Goel
24f3a8cf77 drm/i915: Added write-enable pte bit supportt
This adds support for a write-enable bit in the entry of GTT.
This is handled via a read-only flag in the GEM buffer object which
is then used to see how to set the bit when writing the GTT entries.
Currently by default the Batch buffer & Ring buffers are marked as read only.

v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
    Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)

v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring Buffers(Daniel).

v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries functions,
    in lieu of overloading the cache_level enum (Daniel).

v5: Removed the superfluous VLV check & changed the definition location of PTE_READ_ONLY flag (Imre)

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-17 09:21:47 +02:00
Matt Roper
5aa8a93773 drm/i915: Handle disabled primary plane in debugfs i915_display_info (v2)
Now that the primary plane can be disabled independently of the CRTC,
the debugfs code needs to be updated to recognize when the primary plane
is disabled and not try to return information about the primary plane's
framebuffer.

This change prevents a NULL dereference when reading i915_display_info
with a disabled primary plane.

v2: Replace a seq_printf() with seq_puts() (suggested by Damien)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 20:16:12 +02:00
Daniel Vetter
8c0f92e1f8 drm/i915: Fix comment about our plane remapping on gen2/3
Spotted while crawling around in the area.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 20:01:35 +02:00
Paulo Zanoni
1100244e31 drm/i915: update intel_dp_voltage_max comment
Any comment containing "current Intel hardware supports" quickly
becomes obsolete, so remove it and let people discover the information
by looking at the function implementation.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 19:57:22 +02:00
Paulo Zanoni
9576c27f52 drm/i915: update BDW DDI buffer translations
Two BSpec updates changed the recommended values for BDW eDP and DP
DDI buffer translations. Now the signal levels also match the HSW signal
levels, which simplify things a little bit.

It seems some DP sinks don't work properly without voltage level 0 and
pre-emphasis level 3, so this patch may fix some bugs on
panels/monitors that happen on BDW but not on HSW.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 19:57:05 +02:00
Chris Wilson
1ce826d436 drm/i915: Simplify processing of the golden render context state
Rewrite i915_gem_render_state.c for the purposes of clarity and
compactness, in the process we can eliminate some dodgy math that did
not handle 64bit addresses correctly.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 19:53:09 +02:00
Chris Wilson
6254b2042c drm/i915: Simplify i915_gem_release_all_mmaps()
An object can only have an active gtt mapping if it is currently bound
into the global gtt. Therefore we can simply walk the list of all bound
objects and check the flag upon those for an active gtt mapping.

From commit 48018a57a8
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 13 15:22:31 2013 -0200

    drm/i915: release the GTT mmaps when going into D3

Also note that the WARN is inappropriate for this function as GPU
activity is orthogonal to GTT mmap status. Rather it is the caller that
relies upon this condition and so it should assert that the GPU is idle
itself.

References: https://bugs.freedesktop.org/show_bug.cgi?id=80081
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-16 19:52:20 +02:00
Christoph Jaeger
868d665b43 drm/i915: Fix memory leak in intel_dsi_init() error path
intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
'intel_connector' point to. Simply bail out before allocating memory.

Picked up by Coverity - CID 1222750.

Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 22:08:15 +02:00
Rodrigo Vivi
5755c78f77 drm/i915: Improve PSR debugfs status.
Now we have the active/inactive state for exit and this actually changes the
HW enable bit the status was a bit confusing for users. So let's provide
more info.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 21:28:10 +02:00
Rodrigo Vivi
7c8f8a7007 drm/i915: Force PSR exit by inactivating it.
The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.

However there are many other scenarios that this isn't true. Mainly one right
now is KDE users on HSW and BDW with PSR on. User would miss many screen
updates. For instances any key typed could be seen only when mouse cursor is
moved. So this patch introduces the ability of trigger PSR exit on kernel side
on some common cases that.

Most of the cases are coverred by psr_exit at set_domain. The remaining cases
are coverred by triggering it at set_domain, busy_ioctl, sw_finish and
mark_busy.

The downside here might be reducing the residency time on the cases this
already work very wall like Gnome environment. But so far let's get focused
on fixinge issues sio PSR couild be used for everybody and we could even
get it enabled by default. Later we can add some alternatives to choose the
level of PSR efficiency over boot flag of even over crtc property.

v2: remove exit from connector_dpms. Daniel pointed this is the wrong way and
also this isn't needed for BDW and HSW anyway.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 21:21:36 +02:00
Jesse Barnes
62942ed727 drm/i915/vlv: disable PPGTT on early revs v3
Early revs didn't have PPGTT support, so disable there.

v2: add debug msg when disabling on early stepping
v3: enable on other B3 packages as well (untested) (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
References: https://bugs.freedesktop.org/show_bug.cgi?id=79670
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 18:52:28 +02:00
Ville Syrjälä
d593d992a9 drm/i915: Fix __user sparse warning
CHECK   linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: warning: incorrect type in initializer (different address spaces)
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47:    expected struct drm_i915_gem_exec_object2 *user_exec_list
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47:    got void [noderef] <asn:1>*
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: warning: incorrect type in argument 1 (different address spaces)
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61:    expected void [noderef] <asn:1>*dst
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61:    got unsigned long long *<noident>

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:29 +02:00
Ville Syrjälä
19c656a173 drm/i915: Print PCI revision in i915_dump_device_info()
Knowing the device stepping may be crucial in analyzing problems. Since
we always ask bug reporters for dmegs with drm.debug=0xe (or something)
it would be nice if the PCI revision is already included in the dump.
Avoids having to ask for lspci output as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:29 +02:00
Ville Syrjälä
60a5ca015f drm/i915: Add locking around framebuffer_references--
obj->framebuffer_references isn't an atomic_t so the decrement needs to
be protected by some lock. struct_mutex seems like the appropriate lock
here, and we may already take it for the obj unref anyway.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:28 +02:00
Rodrigo Vivi
642f9bb558 drm/i915: PSR HSW: update after enabling sprite.
On the current structure HSW doesn't support PSR with sprites enabled
but sprites can be enabled after PSR was enabled what would cause
user to miss screen updates.

v2: move it to update_plane.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:28 +02:00
Rodrigo Vivi
0e0ae65236 drm/i915: BDW PSR: Remove DDIA limitation for Broadwell.
Broadwell has a PSR per transcoder, where DDIA supports
link disable and link standby modes while other
transcoders only support link standby.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:27 +02:00
Rodrigo Vivi
4c8c7000cc drm/i915: BDW PSR: Remove limitations that aren't valid for BDW.
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:26 +02:00
Rodrigo Vivi
82c562549b drm/i915: BDW PSR: Add single frame update support.
When link is in stand by and PSR exit is triggered by a primary or sprite
plane flip this mode allows only one single updated frame to be send to
display than get back to PSR immediately.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:26 +02:00
Rodrigo Vivi
34eb7579dc drm/i915: Do not try to enable PSR when Panel doesn't suport it.
Also do not cache aux info. That info could be related to another panel.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:25 +02:00
Rodrigo Vivi
164872543e drm/i915: Don't let update_psr function actually enable PSR.
Being more conservative by enabling PSR only on psr_enable function.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:24 +02:00
Rodrigo Vivi
4704c573fc drm/i915: Use HAS_PSR to avoid unecessary interactions.
Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:24 +02:00
Matt Roper
3d7d6510e6 drm/i915: Switch to unified plane cursor handling (v4)
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support.  This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was called.

The aim here is to transition to the universal plane interface with
minimal code change.  There's a lot of cleanup that can be done (e.g.,
using state stored in crtc->cursor->fb rather than intel_crtc) that is
left to future patches.

v4:
 - Drop drm_gem_object_unreference() that is no longer needed now that
   we receive the GEM obj directly rather than looking up the ID.
v3:
 - Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes,
   even if 'visible' is false.  intel_crtc_cursor_set_obj() will notice
   that the cursor isn't visible and disable it properly, but we still
   need to get intel_crtc->cursor_addr set properly so that we behave
   properly if the cursor becomes visible again in the future without
   changing the cursor buffer (noted by Chris Wilson and verified
   via i-g-t kms_cursor_crc).
 - s/drm_plane_init/drm_universal_plane_init/.  Due to type
   compatibility between enum and bool, everything actually works
   correctly with the wrong init call, except for the type of plane that
   gets exposed to userspace (it shows up as type 'primary' rather than
   type 'cursor').
v2:
 - Remove duplicate dimension checks on cursor
 - Drop explicit cursor disable from crtc destroy (fb & plane
   destruction will take care of that now)
 - Use DRM plane helper to check update parameters

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:23 +02:00
Matt Roper
e328795139 drm/i915: Add intel_crtc_cursor_set_obj() to set cursor buffer (v2)
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter.  The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call this new function.

This refactoring is in preparation for the universal plane cursor
support where we'll want to update the cursor with an actual GEM buffer
object (obtained via drm_framebuffer) rather than a userspace handle.

v2:  Drop obvious kerneldoc and replace with note about function's
     reference consumption

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:23 +02:00
Matt Roper
fc1d3e44ef drm: Allow drivers to register cursor planes with crtc
Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them.  Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:22 +02:00
Chris Wilson
17cfd91f39 drm: Avoid NULL deference when disabling a plane from userspace
To disable a plane, userspace passes in an framebuffer id of 0. This
causes us to pass CRTC == NULL to setplane_internal, who promptly
deferences it to grab the struct drm_device. Oops.

[ 1296.467327] BUG: unable to handle kernel NULL pointer dereference at   (null)
[ 1296.467332] IP: [<c134dc51>] setplane_internal+0x11/0x280
[ 1296.467338] *pde = 00000000
[ 1296.467341] Oops: 0000 [] SMP
[ 1296.467344] Modules linked in: ccm bnep bluetooth snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel arc4 iwldvm snd_hda_controller snd_hda_codec mac80211 snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer iwlwifi sdhci_pci snd cfg80211 x86_pkg_temp_thermal hp_wmi sdhci sparse_keymap mmc_core crc32c_intel rfkill microcode hp_accel lpc_ich lis3lv02d wmi mfd_core serio_raw input_polldev soundcore e1000e ptp pps_core
[ 1296.467367] CPU: 1 PID: 672 Comm: Xorg Tainted: G        W     3.15.0-rc8+ 
[ 1296.467369] Hardware name: Hewlett-Packard HP ProBook 6360b/1620, BIOS 68SCF Ver. B.42 12/29/2010
[ 1296.467371] task: f423b5c0 ti: c2332000 task.ti: c2332000
[ 1296.467374] EIP: 0060:[<c134dc51>] EFLAGS: 00013286 CPU: 1
[ 1296.467376] EIP is at setplane_internal+0x11/0x280
[ 1296.467378] EAX: 00000000 EBX: c2333e90 ECX: 00000000 EDX: f3165600
[ 1296.467380] ESI: f430f400 EDI: 00000000 EBP: c2333e14 ESP: c2333dd4
[ 1296.467382]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 1296.467384] CR0: 80050033 CR2: 00000000 CR3: 00159000 CR4: 000407d0
[ 1296.467385] Stack:
[ 1296.467387]  000200da 00000002 c2333de8 c15dc4a0 f430f400 c2333e00 c134c54f eeeeeeee
[ 1296.467391]  f430f400 00000007 f416b480 c2333e14 00000000 c2333e90 f430f400 00000000
[ 1296.467396]  c2333e4c c1350aed 00000000 00000000 00000000 00000000 00000000 00000000
[ 1296.467400] Call Trace:
[ 1296.467406]  [<c15dc4a0>] ? mutex_lock+0x10/0x28
[ 1296.467408]  [<c134c54f>] ? _object_find+0x5f/0x90
[ 1296.467413]  [<c1350aed>] drm_mode_setplane+0x10d/0x1f0
[ 1296.467416]  [<c13509e0>] ? drm_mode_getplane+0x100/0x100
[ 1296.467420]  [<c1342e4d>] drm_ioctl+0x1bd/0x4f0
[ 1296.467423]  [<c13509e0>] ? drm_mode_getplane+0x100/0x100
[ 1296.467427]  [<c111c023>] ? handle_mm_fault+0x5d3/0xb30
[ 1296.467431]  [<c1118f31>] ? tlb_finish_mmu+0x11/0x40
[ 1296.467435]  [<c1342c90>] ? drm_ioctl_flags+0x40/0x40
[ 1296.467438]  [<c11593d2>] do_vfs_ioctl+0x2f2/0x4d0
[ 1296.467443]  [<c1226512>] ? inode_has_perm.isra.32+0x32/0x40
[ 1296.467446]  [<c122662f>] ? file_has_perm+0x7f/0x90
[ 1296.467449]  [<c1226fec>] ? selinux_file_ioctl+0x4c/0xf0
[ 1296.467452]  [<c1159610>] SyS_ioctl+0x60/0x90
[ 1296.467456]  [<c15e578c>] sysenter_do_call+0x12/0x22
[ 1296.467457] Code: 3f cf ff eb dd ba 3f 00 00 00 b8 d9 c9 7f c1 e8 e6 3f cf ff eb d9 8d 74 26 00 55 89 e5 57 56 53 83 ec 34 66 66 66 66 90 89 45 f0 <8b> 00 85 c9 89 d6 89 cb 89 45 ec 0f 84 16 01 00 00 8b 45 f0 e8
[ 1296.467485] EIP: [<c134dc51>] setplane_internal+0x11/0x280 SS:ESP 0068:c2

Fixes regression from
commit b02fd7fd8a541c3d590bfdda23365a927b507ceb
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Jun 10 08:28:10 2014 -0700

    drm: Support legacy cursor ioctls via universal planes when possible (v4)

While at it move the plane parameter to the first position in
setplane_internal since that's the main object we're manipulating.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Pallavi G<pallavi.g@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Add note about parameter reordering.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:21 +02:00
Matt Roper
161d0dc1dc drm: Support legacy cursor ioctls via universal planes when possible (v4)
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls.  Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition to universal planes will continue to operate
without any change to behavior.

Note that there's a bit of a mismatch between the legacy cursor ioctls
and the universal plane API's --- legacy ioctl's use driver buffer
handles directly whereas the universal plane API takes drm_framebuffers.
Since there's no way to recover the driver handle from a
drm_framebuffer, we can implement legacy ioctl's in terms of universal
plane interfaces, but cannot implement universal plane interfaces in
terms of legacy ioctls.  Specifically, there's no way to create a
general cursor helper in the way we previously created a primary plane
helper.

It's important to land this patch before any patches that add universal
cursor support to individual drivers so that drivers don't have to worry
about juggling two different styles of reference counting for cursor
buffers when userspace mixes and matches legacy and universal cursor
calls.  With this patch, a driver that switches to universal cursor
support may assume that all cursor buffers are wrapped in a
drm_framebuffer and can rely on framebuffer reference counting for all
cursor operations.

v4:
 - Add comments pointing out setplane_internal's reference-eating
   semantics.
v3:
 - Drop drm_mode_rmfb() call that is no longer needed now that we're
   using setplane_internal(), which takes care of deref'ing the
   appropriate framebuffer.
v2:
 - Use new add_framebuffer_internal() function to create framebuffer
   rather than trying to call directly into the ioctl interface and
   look up the handle returned.
 - Use new setplane_internal() function to update the cursor plane
   rather than calling through the ioctl interface.  Note that since
   we're no longer looking up an fb_id, no extra reference will be
   taken here.
 - Grab extra reference to fb under lock in !BO case to avoid issues
   where racing userspace could cause the fb to be destroyed out from
   under us after we grab the fb pointer.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:21 +02:00
Matt Roper
b36552b32a drm: Refactor setplane to allow internal use (v3)
Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID.  We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.

v3:
 - Move integer overflow checking from setplane_internal to setplane
   ioctl.  The upcoming legacy cursor support via universal planes needs
   to maintain current cursor ioctl semantics and not return error for
   these extreme values (found via intel-gpu-tools kms_cursor_crc test).
v2:
 - Allow planes to be disabled without a valid crtc again (and add
   mention of this to setplane's kerneldoc, since it doesn't seem to be
   mentioned anywhere else).
 - Reformat some parameter line wrap

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:20 +02:00
Matt Roper
c394c2b08e drm: Refactor framebuffer creation to allow internal use (v2)
Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly.  The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl handler.

v2: Take struct drm_mode_fb_cmd2 parameter directly rather than void*

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:20 +02:00
Tom O'Rourke
7405f42c79 drm/i915/chv: Fix "drm/i915/chv: Add a bunch of pre production workarounds"
Correct a merge mishap in commit e4443e459c.

Wa*:chv belongs in cherryview_enable_rps, not gen8_enable_rps.

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:19 +02:00
Oscar Mateo
3b2cc8ab64 drm/i915/bdw: Do not write the Semaphore Sync Registers in GEN8+
These do not exist anymore.

Spotted while reading through intel_ringbuffer.c

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 17:45:18 +02:00
Chris Wilson
b90b91d870 drm/i915: Prefault the entire object on first page fault
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which we in return receive the benefit of removing the
per-page faulting overhead.

On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces:	8127MiB/s -> 8134MiB/s
Upload rate for 2 tiled surfaces:	8607MiB/s -> 8625MiB/s
Upload rate for 4 linear surfaces:	8127MiB/s -> 8127MiB/s
Upload rate for 4 tiled surfaces:	8611MiB/s -> 8602MiB/s
Upload rate for 8 linear surfaces:	8114MiB/s -> 8124MiB/s
Upload rate for 8 tiled surfaces:	8601MiB/s -> 8603MiB/s
Upload rate for 16 linear surfaces:	8110MiB/s -> 8123MiB/s
Upload rate for 16 tiled surfaces:	8595MiB/s -> 8606MiB/s
Upload rate for 32 linear surfaces:	8104MiB/s -> 8121MiB/s
Upload rate for 32 tiled surfaces:	8589MiB/s -> 8605MiB/s
Upload rate for 64 linear surfaces:	8107MiB/s -> 8121MiB/s
Upload rate for 64 tiled surfaces:	2013MiB/s -> 3017MiB/s

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Testcasee: igt/gem_fence_upload/performance
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 15:17:41 +02:00
Rodrigo Vivi
a8aab8bd5e drm/i915: Fix VLV CRC reading.
Adding missing Display mmio reg offset.

Credits-to: Laws, Philip <philip.laws@intel.com>
Cc: He, Shuang <shuang.he@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 15:17:41 +02:00
Daniel Vetter
75a91c975b drm/i915: Update DRIVER_DATE to 20140606
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13 15:17:40 +02:00