Commit Graph

441918 Commits

Author SHA1 Message Date
Chris Wilson
5cc9ed4b9a drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).

v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
    to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
     Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
     with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
     within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
     rearrange error path to destroy the mmu_notifier locklessly.
     Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
     allocations of the same userptr range - and notice that
     struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
     for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
     hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
     infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
     be used to fix up the kernel thread's current->mm for use with
     copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
     userptr details elsewhere, and clean up comments based on
     suggestions by Bradley.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 19:31:29 +02:00
Mika Kuoppala
992f191f2c drm/i915: Be careful with non-disp bit in PMINTRMSK
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 16:28:56 +02:00
Oscar Mateo
19656430a8 drm/i915: Gracefully handle obj not bound to GGTT in is_pin_display
Otherwise, we do a NULL pointer dereference.

I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():

If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is still not pinned
to GGTT and maybe not even bound, so we have to check before we
dereference its GGTT vma.

The IGT kms_flip/bo-too-big tests for this bug.

v2: Chris Wilson says restoring the old value is easier, but that
is_pin_display is useful as a theory of operation. Take the solomonic
decision: at least this way is_pin_display is a little more robust
(until Chris can kill it off).

v3: Chris suggests the WARN in i915_gem_obj_to_ggtt has outlived its
usefulness: add a reminder to remove it.

Issue: VIZ-3772
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Testcase: igt/kms_flip/bo-too-big
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 16:24:39 +02:00
Daniel Vetter
4271b753bb drm/i915: Stop calling encoder->mode_set
All the callbacks are gone now.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 12:01:50 +02:00
Daniel Vetter
07e4fb9eb3 drm/i915/dsi: Remove ->mode_set callback
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
  code.
- All the modeset state seems to be tracked in the intel_dsi structure
  instead of the pipe config.

Given all that I can't properly audit the dsi ->mode_set callback. So
just do it as the first thing in the ->pre_pll_enable hook and hope
for the best.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:59:38 +02:00
Daniel Vetter
30cf6db8b2 drm/i915/ddi: Remove ->mode_set callback
A bit more care required here since there are some very few things
between the call to encoder->mode_set and encoder->pre_enable. But
they're either book-keeping or only matter for the vga port on the
pch. So of no concern.

Note that with the new sequence we write the infoframes after
selecting the clock source, but that shouldn't matter. I've simply
opted for this to have simpler code.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:59:29 +02:00
Daniel Vetter
85a50fb0d3 drm/i915/lvds: Remove ->mode_set callback
All the hard work was already done, only thing left to do is remove
the empty callback. And a now rather misleading comment I've spotted
while reading through code.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:59:09 +02:00
Daniel Vetter
4cde8a215f drm/i915/hdmi: Remove ->mode_set callback
Similar to dp the only thing we do is call intel_write_eld and prepare
a bit of state for the enable hooks. The only difference is that we
write that to the hardware instead of keeping track of it somewhere in
software.

Still we can just move all this to the very first enable hook.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:59:02 +02:00
Daniel Vetter
e55dd225c8 drm/i915/hdmi: Remove redundant IS_VLV checks
Those functions are only used on vlv platforms, so no need to check.
Especially if we're not too consistent about it.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:56 +02:00
Daniel Vetter
8ac33ed3dc drm/i915/dp: Remove ->mode_set callback
With all the preceding refactoring the dp mode_set callback only
computes a bit of state (all derived from the pipe config) and also
writes the eld. As long as we do that before we enable the audio bit
or depend upon the correct value in intel_dp->DP we'll be fine.

No other hw state is touched.

We therefore only need to check that clearing intel_dp->DP is save.
Which it is since when we re-enable we already mask out all the bits
the link training code sets. And we need to keep on doing that so that
the re-train loop walking over pre-emph/voltage-swing values still
works properly.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:48 +02:00
Daniel Vetter
d41f1efb32 drm/i915/dp: Move port A pll setup to g4x_pre_enable_dp
Only ilk/snb/ivb need the port A pll setup, so move it to the
pre_enable hook for those platforms. We can savely do this since on
those platforms there's nothing that touches the hardware between the
encoder->mode_set and the encoder->pre_enable calls.

Also add a comment that port A is ilk+ only.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:33 +02:00
Daniel Vetter
9ed109a7b4 drm/i915: Track has_audio in the pipe config
Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.

Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
  that means some pretty extensive reworking of our code which
  currently does all this while the pipe/port is still off.

I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
  encoder.

I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:26 +02:00
Daniel Vetter
acfa75b02e drm/i915: Simplify audio handling on DDI ports
There's no need to check whether audio is enabled (which for ddi ports
is done through the crtc->eld_vld flag) since at the cost of a
potentially unecessary register rmw cycle we can unconditionally do
this.

Note that the edp check is just paranoia since we won't ever call the
write_eld function for an edp panel.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:18 +02:00
Daniel Vetter
9f04003e2b drm/i915/sdvo: use config->has_hdmi_sink
This way we can rely on the state cross-checker to have a bit
assurance that we'll get it right.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:09 +02:00
Daniel Vetter
b5a9fa09ea drm/i915: state readout and cross checking for limited_color_range
At least on those platforms which have a simple bit and don't rely
on the fully programmable CSC unit to do this.

Note that with the current code this includes CHV, but I guess that
platform will match BYT.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:58:01 +02:00
Daniel Vetter
69f5acc839 drm/i915/sdvo: Use pipe_config->limited_color_range consistently
We in the pre_enable hook we should only rely on the pipe config and
not on some other state set through properties or detect functions.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:57:53 +02:00
Daniel Vetter
6897b4b5d3 drm/i915: Track hdmi mode in the pipe config
Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:57:44 +02:00
Daniel Vetter
abac6a009c drm/i915/hdmi: Enable hdmi mode on g4x, too
For compliance we really should be sending NULL infoframes always
when we detect a hdmi capable monitor. Also remove the now redudant
setting for the has_audio case and enforce that audio is only
possible with a hdmi sink.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 11:57:33 +02:00
Mika Kuoppala
b7bb243924 drm/i915: Enable rc6 with bdw
Everything should be in place so enable rc6/rps for bdw.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 23:15:54 +02:00
Mika Kuoppala
8fd9c1a9d7 drm/i915: Fix rc6 options debug info
by correctly displaying result and requested.

Suggested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 23:15:45 +02:00
Deepak S
baccd4586e drm/i915: Enable PM Interrupts target via Display Interface.
In BDW, Apart from unmasking up/down threshold interrupts. we need
to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
Interface.

v2: Add (1<<31) mask (Ville)

v3: Add Gen check for the mask (ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 23:14:56 +02:00
Ben Widawsky
0961021aef drm/i915/bdw: Implement a basic PM interrupt handler
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the interrupt handler, since
interrupts are not shared in the same way.

The patch is mostly a copy-paste of the existing snb+ code, with updates
to the relevant parts requiring changes to the interrupt handling. As
such it /should/ be relatively trivial. It's highly likely that I missed
some places where I need a gen8 version of the PM interrupts, but it has
become invisible to me by now.

This patch could probably be split into adding the new functions,
followed by actually handling the interrupts. Since the code is
currently disabled (and broken) I think the patch stands better by
itself.

v2: Move the commit about not touching the ringbuffer interrupt to the
snb_* function where it belongs (Rodrigo)

v3: Rebased on Paulo's runtime PM changes

v4: Not well validated, but rebase on
commit 730488b2ed
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Mar 7 20:12:32 2014 -0300

    drm/i915: kill dev_priv->pm.regsave

v5: Rebased on latest code base. (Deepak)

v6: Remove conflict markers, Unnecessary empty line and use right
IIR interrupt (Ville)

v7: mask modified without rmw (Ville Syrjälä)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 23:14:32 +02:00
Mika Kuoppala
6e450ab24d drm/i915: Bail out early on gen6_signal if no semaphores
If we dont have semaphores enabled, we allocate 4
dwords for signalling. But end up emitting more regardless.

Fix this by bailing out early if semaphores are not enabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78274
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78283
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 23:14:13 +02:00
Shobhit Kumar
df38e6558d drm/i915: MIPI PPS delays added
Added as generic parameters which will be initialized in the panel
driver and are specific to panels.

Backlight delays have also kept as placeholders and will be used used
once we have MIPI backlight enabling support

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 22:44:21 +02:00
Shobhit Kumar
cf4dbd2ecb drm/i915: MIPI init count programming as generic parameter
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 22:44:05 +02:00
Shobhit Kumar
dfba2e2d33 drm/i915: Correct MIPI operation mode as per expected values from VBT
In VBT fields operation mode is 0 for Video mode and 1 for command mode.
This field will be directly used as is in generic panel driver. So
adjust accordingly.

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-15 22:43:48 +02:00
Mika Kuoppala
229b0489aa drm/i915: add null render states for gen6, gen7 and gen8
These are generated with intel-gpu-tools/tools/null_state_gen

v2: Don't use header file for states (Daniel Vetter)

v3: Proper URB state size for gen8/GT3 (Damien Lespiau)

Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1)
Tested-by: Oscar Mateo <oscar.mateo@intel.com> (v2)
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 19:17:08 +02:00
Mika Kuoppala
9d0a6fa6c5 drm/i915: add render state initialization
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.

For each new uninitialized context, generate a
valid null render state to be run on context
creation.

This patch introduces a skeleton with empty states.

v2: - No need to vmap (Chris Wilson)
    - use .c files for state (Daniel Vetter)
    - no need to flush as i915_add_request does it
    - remove parameter for batch alloc size
    - don't wait for the init (Ben Widawsky)

v3: - move to cpu/gpu (Chris Wilson)

Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1)
Tested-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 19:16:13 +02:00
Daniel Vetter
8b1bc9b4f1 drm/i915: Only do gtt cleanup in vma_unbind for the global vma
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 18:39:54 +02:00
Daniel Vetter
aff10b30a1 drm/i915: Don't drop pinned fences
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.

Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite gtt
fastpath. But that one checks of obj tiling, so should be ok.

But one thing that _does_ blow up is the vma unbinding with more than
one address space. The next patch will fix this.

v2: Use a WARN_ON - Chris pointed out that we already catch all cases
so userspace can't provoke this like I've originally feared.

While reviewing relevant code I've noticed a pile of DRM_ERROR in the
overlay&cursor code which are all triggerable by userspace. Tune them
down while at it.

v3: Split out the DRM_ERROR->DRM_DEBUG_KMS change into a separate patch,
as requested by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 18:39:31 +02:00
Daniel Vetter
2206e6a11b drm/i915: use dev_priv directly in i915_driver_unload
Noticed while playing with coccinelle.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 13:12:24 +02:00
Chris Wilson
c0c97622c1 drm/i915: Use the connector name in fbdev debug messages
During initial probing of the modes to assign to the fbdev console, we
use the CRTC and connector ids. These are much harder for us to
understand than if we used their actual names (or pipe in the CRTC
case). Similarly, we want to manually print the mode size rather than
rely on mode->name being set.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 12:10:45 +02:00
Damien Lespiau
70e1e0ec02 drm/i915: Use for_each_crtc() when iterating through the CRTCs
Patch done using the following semantic patch (thanks Daniel for the
help!)

  @@
  iterator name list_for_each_entry;
  iterator name for_each_crtc;
  struct drm_crtc * crtc;
  struct drm_device * dev;
  @@
  -list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) {
  +for_each_crtc(dev,crtc) {
  	...
  }

Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 00:38:46 +02:00
Damien Lespiau
d79b814d2f drm/i915: Introduce a for_each_crtc() macro
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 00:38:38 +02:00
Damien Lespiau
d3fcc808b2 drm/i915: Use for_each_intel_crtc() when iterating through intel_crtcs
Generated using the semantic patch:

  @@
  iterator name list_for_each_entry;
  iterator name for_each_intel_crtc;
  struct intel_crtc * crtc;
  struct drm_device * dev;
  @@
  -list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) {
  +for_each_intel_crtc(dev,crtc) {
	...
  }

Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 00:38:24 +02:00
Damien Lespiau
d063ae48c4 drm/i915: Introduce a for_each_intel_crtc() macro
Fed up with having that long list_for_each_entry() invocation?

Use for_each_intel_crtc()!

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-14 00:38:18 +02:00
Damien Lespiau
546c81fd1a drm/i915: Use ilk_wm_max_level() in latency debugfs files
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Squash in patch that exported ilk_wm_max_level.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 20:01:48 +02:00
Damien Lespiau
9f25d00742 drm/i915: Don't cast void* pointers
That's not necessary and makes the code not as neat as it could be.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 18:45:37 +02:00
Daniel Vetter
ffd93f2480 drm/i915: Work-around garbage DR4 from UXA
Somehow UXA submits a completely bogus DR4 value since essentially
forever. It was originally introduced in

commit bade7d7d2505a10a8a7d24b084aff9742e2d6d64
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Jun 6 14:03:25 2008 -0700

    Use the DRM for submitting batchbuffers when available.

and dutifully copied around ever since. Since we want to keep the
general dirt catching around just special case the UXA value.

This regression was introduced in

commit 9cb346648d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 24 08:09:11 2014 +0200

    drm/i915: Catch dirt in unused execbuffer fields

Comment from Chris' review:

"To be fair, it is a sensible value if one supposes a Region style API to
cliprects. Under that API, DR[14] define the extents of the clip region,
and ((0,0), (0,0)) [DR1==DR4==0] would mean all clipped, do not draw
anything."

v2: Pimp commit message a bit and remove the double space.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78494
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jörg Otte <jrg.otte@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 17:16:13 +02:00
Daniel Vetter
d8ffa60b52 drm/i915: WARN_ON fence pin leaks
The fence pin count should always be <= the bo pin count. If that's
not the case then we have a funny problem and are leaking references
somewhere.

Which means we can catch fence pin leaks by checking for the same
upper limit as we do for the bo pin count. Inspired by a discussion
with Ville about a fence leak igt testcase.

v2: Also check for fence->pin_count <= ggtt_vma->pin_count, since that
might catch a leak even quicker. Also de-inline them, they're getting
too big.

v3: Don't separately check for MAX_PIN_COUNT since the > vma->pin_count
check will catch that already (Chris).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 17:16:12 +02:00
Ville Syrjälä
56ef52cad5 drm/i915: Kill vblank waits after pipe enable on gmch platforms
The pipe might not start to actually run until the port has been enabled
(depends on the platform and port type). So don't try to wait for vblank
after we enabled the pipe but haven't yet enabled the port.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 17:16:04 +02:00
Ville Syrjälä
9ab0460b1b drm/i915: Disable/enable planes as the first/last thing during modeset on gmch platforms
We already moved the plane disable/enable to happen as the first/last
thing on every other platforms. Follow suit with gmch platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict, as usual.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:25 +02:00
Oscar Mateo
d153337958 drm/i915: Ringbuffer signal func for the second BSD ring
This is missing in:

commit 78325f2d27
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Tue Apr 29 14:52:29 2014 -0700

    drm/i915: Virtualize the ringbuffer signal func

Looks to me like a rebase side-effect...

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:24 +02:00
Ville Syrjälä
36dfcea47a x86/gpu: Sprinkle const, __init and __initconst to stolen memory quirks
gen8_stolen_size() is missing __init, so add it.

Also all the intel_stolen_funcs structures can be marked
__initconst.

intel_stolen_ids[] can also be made const if we replace the
__initdata with __initconst.

Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:23 +02:00
Damien Lespiau
3e3b2c3908 x86/gpu: Implement stolen memory size early quirk for CHV
CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field
(GFX stolen memory size) with the addition of finer granularity modes:
4MB increments from 0x11 (8MB) to 0x1d.

Values strictly above 0x1d are either reserved or not supported.

v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new
    values (Ville Syrjälä)

v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville
    Syrjälä)

v4: Don't assign a value that needs 20bits or more to a u16 (Rafael
    Barbalho)

[vsyrjala: v5: Split from i915 changes and add chv_stolen_funcs]

Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:23 +02:00
Damien Lespiau
d7f25f23d2 drm/i915/chv: Implement stolen memory size detection
CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field
(GFX stolen memory size) with the addition of finer granularity modes:
4MB increments from 0x11 (8MB) to 0x1d.

Values strictly above 0x1d are either reserved or not supported.

v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new
    values (Ville Syrjälä)

v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville
    Syrjälä)

v4: Don't assign a value that needs 20bits or more to a u16 (Rafael
    Barbalho)

[vsyrjala: v5: Split the early quirks to another patch]

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:22 +02:00
Ville Syrjälä
7895a81dcf drm/i915/chv: CHV doesn't have CRT output
No CRT output on CHV, so don't call intel_crt_init().

v2: Don't disable CRT on HAS.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:18 +02:00
Ville Syrjälä
70b23a980e drm/i915/chv: Add DPLL state readout support
Add chv_crtc_clock_get() to read out the DPLL settings.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fix compile due to bikeshedded headers in an earlier patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-13 14:13:06 +02:00
Chon Ming Lee
44f37d1f52 drm/i915/chv: Pipe select change for DP and HDMI
With additional of pipe C, current 1 bit registers for pipe select
for HDMI and DP are no longer able to gather for 3 pipes. As a result,
new bits location in the same registers are added.

For HDMI, VLV uses bit 30, CHV uses bit 24-25.

For DP, VLV uses bit 30, CHV uses bit 16-17.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12 19:50:16 +02:00
Chon Ming Lee
e4a1d8467d drm/i915/chv: Add phy supports for Cherryview
Added programming phy layer for CHV based on "Application note for 1273
CHV Display phy".

v2: Rebase the code and do some cleanup.
v3: Rework based on Ville review.
    -Fix the macro where the ch info need to swap, and add parens to ?
	 operator.
	-Fix wrong bit define for DPIO_PCS_SWING_CALC_0 and
	 DPIO_PCS_SWING_CALC_1 and rename for meaningful.
    -Add some comments for CHV specific DPIO registers.
    -Change the dp margin registery value to decimal to align with the
	 doc.
	-Fix the not clearing some value in vlv_dpio_read before write again.
    -Create new hdmi/dp encoder function for chv instead of share with
	valleyview.
v4: Rebase the code after rename the DPIO registers define and upstream
	change.
    Based on Ville review.
    -For unique transition scale selection, after Ville point out, look
	 like the doc might wrong for the bit 26.  Use bit 27 for ch0 and
	 ch1.
	-Break up some dpio write value into two/three steps for readability.
	-Remove unrelated change.
    -Add some shift define for some registers instead just give the hex
	value.
    -Fix a bug where write to wrong VLV_TX_DW3.
v5: Based on Ville review.
	- Move tx lane latency optimal setting from chv_dp_pre_pll_enable to
	  chv_pre_enable_dp, and chv_hdmi_pre_pll_enable to
	  chv_hdmi_pre_enable respectively.
 	- Fix typo in one margin_reg_value for DP_TRAIN_VOLTAGE_SWING_400.
	- Clear DPIO_TX_UNIQ_TRANS_SCALE_EN for DP and HDMI.
	- Mask the old deemph and swing bits for hdmi.
v6: Remove stub for pre_pll_enable for dp and hdmi.

Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[vsyrjala: Don't touch panel power sequencing on DP]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-12 19:50:15 +02:00