Commit Graph

5336 Commits

Author SHA1 Message Date
Ben Widawsky
058840c7a0 drm/i915/bdw: Flush system agent on gen8 also
gem_gtt_cpu_tlb seems to indicate that it is needed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72869

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-06 11:11:04 +01:00
Chris Wilson
a885b3ccc7 drm/i915: Use the correct GMCH_CTRL register for Sandybridge+
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.

Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-17 19:30:21 +01:00
Paulo Zanoni
be3d26b058 drm/i915: get a PC8 reference when enabling the power well
In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
we want to enable/disable PC8. On the case where we're enabling PC8
this works fine, but on the case where we disable PC8 due to a non-eDP
monitor being enabled, we first enable the power well and then disable
PC8. Although wrong, this doesn't seem to be causing any problems now,
and we don't even see anything in dmesg. But the patches for runtime
D3 turn this problem into a real bug, so we need to fix it.

This fixes the "modeset-non-lpsp" subtest from the "pm_pc8" test from
intel-gpu-tools.

v2: - Rebase (i915_disable_power_well).
v3: - More reabase.
v4: - Rebase on top of -fixes instead of -nightly.

This is commit d62292c8f7 in -next, but
we need it in -fixes to address Dave's report.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reported-by: Dave Jones <davej@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13 21:34:57 +01:00
Paulo Zanoni
96b4026878 drm/i915: change CRTC assertion on LCPLL disable
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
because intel_modeset_update_state will mark the CRTC as enabled, then
the thread that's still enabling PC8 might look at the data structure
and think that PC8 is being enabled while a pipe is enabled. Despite
the WARN, this is not really a bug since we'll wait for the
PC8-enabling thread to finish when we call modeset_global_resources.

The spec says the CRTC cannot be enabled when we disable LCPLL, so we
had a check for crtc->base.enabled. If we change to crtc->active we
will still prevent disabling LCPLL while the CRTC is enabled, and we
will also prevent the WARN above.

This is a replacement for the previous patch named
    "drm/i915: get/put PC8 when we get/put a CRTC"

Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit 798183c547
from -next due to Dave's report.)
Reported-by: Dave Jones <davej@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13 18:47:39 +01:00
Chris Wilson
4db080f9e9 drm/i915: Fix erroneous dereference of batch_obj inside reset_status
As the rings may be processed and their requests deallocated in a
different order to the natural retirement during a reset,

/* Whilst this request exists, batch_obj will be on the
 * active_list, and so will hold the active reference. Only when this
 * request is retired will the the batch_obj be moved onto the
 * inactive_list and lose its active reference. Hence we do not need
 * to explicitly hold another reference here.
 */

is violated, and the batch_obj may be dereferenced after it had been
freed on another ring. This can be simply avoided by processing the
status update prior to deallocating any requests.

Fixes regression (a possible OOPS following a GPU hang) from
commit aa60c664e6
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Wed Jun 12 15:13:20 2013 +0300

    drm/i915: find guilty batch buffer on ring resets

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Add the code comment Chris supplied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 10:49:05 +01:00
Chris Wilson
9ae9ab5220 drm/i915: Prevent double unref following alloc failure during execbuffer
Whilst looking up the objects required for an execbuffer, an untimely
allocation failure in creating the vma results in the object being
unreferenced from two lists. The ownership during the lookup is meant to
be moved from the list of objects being looked to the vma, and this
double unreference upon error results in a use-after-free.

Fixes regression from
commit 27173f1f95
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Aug 14 11:38:36 2013 +0200

    drm/i915: Convert execbuf code to use vmas

Based on the fix by Ben Widawsky.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
[danvet: Bikeshed the crucial comment above the ownership transfer as
discussed on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 10:44:57 +01:00
Dave Airlie
25945b6690 Merge tag 'drm-intel-fixes-2013-12-11' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Just a bunch of regression fixes plus a few patches for long-standing
issues in gem corner-cases that we've hunted down in the past weeks. Since
apparently people hit those in the wild (and we also have nice igts for
them) I've opted for -fixes and cc: stable.

There's 1-2 things oustanding on top of this where I'm still waiting on
confirmation from testing, but nothing really scary.

* tag 'drm-intel-fixes-2013-12-11' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: don't update the dri1 breadcrumb with modesetting
  drm/i915: Repeat eviction search after idling the GPU
  drm/i915: Fix use-after-free in do_switch
  drm/i915: fix pm init ordering
  drm/i915: Hold mutex across i915_gem_release
  drm/i915: Skip clock checks on BDW
  drm/i915: Do not clobber config status after a forced restore of hw state
  drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
2013-12-12 10:38:43 +10:00
Dave Airlie
62a3a12667 Merge branch 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
As promised bdw fixes come separate for now. Just a few minior things.

* 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell
  drm/i915/bdw: Limit GTT to 2GB
  drm/i915/bdw: Add comment about gen8 HWS PGA
  drm/i915/bdw: Free correct number of ppgtt pages
  drm/i915/bdw: Do gen6 style reset for gen8
  drm/i915/bdw: GEN8 backlight support
  drm/i915/bdw: Add BDW to ULT macro
2013-12-12 10:38:08 +10:00
Daniel Vetter
6c719faca2 drm/i915: don't update the dri1 breadcrumb with modesetting
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.

Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.

Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).

v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.

v3: Fix the spelling in the comment.

Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 14:25:58 +01:00
Chris Wilson
ad071acb53 drm/i915: Repeat eviction search after idling the GPU
With the advent of hw context support, we gained some objects that are
pinned for the duration of their request. That is we can make aperture
space available by idling the GPU and in the process performing a
context switch back to the always-pinned default context. As such, we
should not conclude that there is no space in the aperture for the
current object until we have unpinned any such context objects.

Note that we also have the problem of outstanding pageflips preventing
eviction of their framebuffer objects to resolve.

Testcase: igt/gem_ctx_exec/eviction
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72507
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 08:13:58 +01:00
Daniel Vetter
acc240d41e drm/i915: Fix use-after-free in do_switch
So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.

With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).

Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:

i915_gem_do_execbuffer()

i915_switch_context()

do_switch()
   from = ring->last_context;
   i915_gem_object_pin()

      i915_gem_object_bind_to_gtt()
         ret = drm_mm_insert_node_in_range_generic();
         // If the above call fails then it will try i915_gem_evict_something()
         // If that fails it will call i915_gem_evict_everything() ...
	 i915_gem_evict_everything()
	    i915_gpu_idle()
	       i915_switch_context(DEFAULT_CONTEXT)

Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.

Note that there's no need to recheck whether a context switch is still
required because:

- Doing a switch to the same context is harmless (besides wasting a
  bit of energy).

- This can only happen with the default context. But since that one's
  pinned we'll never call down into evict_everything under normal
  circumstances. Note that there's a little driver bringup fun
  involved namely that we could recourse into do_switch for the
  initial switch. Atm we're fine since we assign the context pointer
  only after the call to do_switch at driver load or resume time. And
  in the gpu reset case we skip the entire setup sequence (which might
  be a bug on its own, but definitely not this one here).

Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.

Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.

Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.

References: https://code.google.com/p/chromium/issues/detail?id=248191
Reported-by: Ian Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: stable@vger.kernel.org
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Ian Lister <ian.lister@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-06 13:09:11 +01:00
Daniel Vetter
f742a55231 drm/i915: fix pm init ordering
Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.

While at it also shovel the pc8 setup code into the same functions.
I wanted to also ditch the header declaration of the hws pc8 functions,
but for unfathomable reasons that stuff is in intel_display.c instead
of intel_pm.c.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-06 13:08:15 +01:00
Dave Airlie
1ec2c7fc11 Merge tag 'drm-intel-fixes-2013-12-02' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Just flushing out my pile of bugfixes, most of them for regressions/cc:
stable. Nothing really serious going on.

For outstanding issues we still have the S4 fun due to the hsw S4
duct-tape pending (seems like I need to switch into angry maintainer mode
on that one). And there's the mode merging revert to make my g33 work
again still pending for drm core. For that one I don't have any more clue
(and it looks like no one else has a good idea either). And apparently the
locking WARN fix in here also needs to be replicated for boot, still
confirming that one though.

* tag 'drm-intel-fixes-2013-12-02' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Pin pages whilst allocating for dma-buf vmap()
  drm/i915: MI_PREDICATE_RESULT_2 is HSW only
  drm/i915: Make the DERRMR SRM target global GTT
  drm/i915: use the correct force_wake function at the PC8 code
  drm/i915: Fix pipe CSC post offset calculation
  drm/i915: Simplify DP vs. eDP detection
  drm/i915: Check VBT for eDP ports on VLV
  drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
  drm/i915: Pin relocations for the duration of constructing the execbuffer
  drm/i915: take mode config lock around crtc disable at suspend
  drm/i915: Prefer setting PTE cache age to 3
  drm/i915/ddi: set sink to power down mode on dp disable
2013-12-05 09:26:20 +10:00
Chris Wilson
0d1430a3f4 drm/i915: Hold mutex across i915_gem_release
Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.

Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-04 16:57:02 +01:00
Ville Syrjälä
5ae68b4132 drm/i915: Skip clock checks on BDW
We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-03 23:15:47 +01:00
Chris Wilson
edd5b13313 drm/i915: Do not clobber config status after a forced restore of hw state
We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.

In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.

v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.

This regression has been introduced in

commit 2e9388923e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 11 20:08:24 2012 +0200

    drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org (v3.8 and later)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-03 23:15:46 +01:00
Ville Syrjälä
0274766428 drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.

Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-03 23:14:26 +01:00
Chris Wilson
993fc6ebaf drm/i915: Pin pages whilst allocating for dma-buf vmap()
During the vmap() routine for the dma-buf, we first grab the pages and
then try to allocate a temporary array to pass to the vmap(). However,
the shrinker can and will reap any object that is unbound if the
allocation for the array first fails. This includes the object which we
are attempting to vmap(). The solution is to mark the object's pages as
pinned whilst we try the allocation to prevent the use-after-free
introduced by the potential shrinkage.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29 15:51:20 +01:00
Ville Syrjälä
0bf2134780 drm/i915: MI_PREDICATE_RESULT_2 is HSW only
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is either reserved, or contains some
other register. So write the register only on HSW.

This regression has been introduced in

commit 9435373ef8
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Wed Aug 28 16:45:46 2013 -0300

    drm/i915: Report enabled slices on Haswell GT3

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29 15:00:03 +01:00
Ville Syrjälä
22613c96b4 drm/i915: Make the DERRMR SRM target global GTT
The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM
should target the global GTT instead.

v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29 14:56:44 +01:00
Paulo Zanoni
a121644428 drm/i915: use the correct force_wake function at the PC8 code
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.

I was able to notice the problem when running the
debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29 14:23:10 +01:00
Ville Syrjälä
32cf0cb029 drm/i915: Fix pipe CSC post offset calculation
We were miscalculating the pipe CSC post offset for the full->limited
range conversion. The resulting post offset was double what it was
supposed to be, which caused blacks to come out grey when using
limited range output on HSW+.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769
Cc: stable@vger.kernel.org
Tested-by: Lauri Mylläri <lauri.myllari@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28 22:47:41 +01:00
Ville Syrjälä
3b32a35b31 drm/i915: Simplify DP vs. eDP detection
Reduce the eDP detection to just checking if it's port A, or if
the VBT tells us that the port is eDP for the other ports.

Suggested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28 13:42:25 +01:00
Ville Syrjälä
5d8a77529b drm/i915: Check VBT for eDP ports on VLV
VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.

So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051
Tested-by: Robert Hooker <robert.hooker@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28 13:42:12 +01:00
Jesse Barnes
fec8cba306 drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
This value is more correct, and matches what we read out in the fastboot
code.  Without this, the watermark code will panic after the first mode
setting activity after a fastboot.

v2: fix up HSW ->clock usage too (Ville)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-27 20:34:48 +01:00
Chris Wilson
a415d35564 drm/i915: Pin relocations for the duration of constructing the execbuffer
As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively simple as we can just keep the objects pinned for not just
the relocation but until we are finished.

One such example is the possibility of the context switch causing an
eviction or hitting the shrinker in order to fit its object into the
aperture.

Link: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036166.html
Reported-by: "Siluvery, Arun" <arun.siluvery@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add the additional explanations from Chris to the commit
message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-27 09:04:36 +01:00
Jesse Barnes
7c063c7259 drm/i915: take mode config lock around crtc disable at suspend
This is just a theoretical issue, but we need to do this to prevent the
WARN in pipe_from_connector at suspend time.

This regression has been introduce in

commit 7bd688cd66
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Nov 8 16:48:56 2013 +0200

    drm/i915: handle backlight through chip specific functions

https://bugs.freedesktop.org/show_bug.cgi?id=71978
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26 19:09:14 +01:00
Chris Wilson
c51e9701c4 drm/i915: Prefer setting PTE cache age to 3
We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
age 0

(commit 0d8ff15e9a
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Thu Jul 4 11:02:03 2013 -0700

    drm/i915/hsw: Set correct Haswell PTE encodings)

actually seems to prefer the default PTE encoding as age 3. Presumably,
this is in part due to the use of MOCS to override the PTE encodings
when appropriate.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69870
Tested-by: mengmeng.meng@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eric Anholt <eric@anholt.net
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-25 09:50:15 +01:00
Jani Nikula
76bb80ed30 drm/i915/ddi: set sink to power down mode on dp disable
Similar to
commit fdbc3b1f63
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Nov 12 17:10:13 2013 +0200

    drm/i915/dp: set sink to power down mode on dp disable

but for DDI, where we've never done this.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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>
2013-11-21 15:11:15 +01:00
Dave Airlie
cf96967794 Merge tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Just a small pile of fixes for bugs and a few regressions. I'm still
trying to track down a driver load hang on my g33 (which infuriatingly
doesn't happen when loading the module manually after boot), somehow
bisecting loves to go astray on this one :( And there's a (harmless)
locking WARN in the suspend code due to one of Jesse's vlv backlight
rework patches. Otherwise nothing outstanding afaik.

* tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Fix gen3 self-refresh watermarks
  drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
  drm/i915: Do not enable package C8 on unsupported hardware
  drm/i915: Hold pc8 lock around toggling pc8.gpu_idle
  drm/i915: encoder->get_config is no longer optional
  drm/i915/tv: add ->get_config callback
  drm/i915: restore the early forcewake cleanup
  Partially revert "drm/i915: tune the RC6 threshold for stability"
  drm/i915: flush cursors harder
  i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7
  x86/early quirk: use gen6 stolen detection for VLV
  drm/i915/dp: set sink to power down mode on dp disable
2013-11-21 18:45:51 +10:00
Linus Torvalds
82023bb7f7 More ACPI and power management updates for 3.13-rc1
- ACPI-based device hotplug fixes for issues introduced recently and
   a fix for an older error code path bug in the ACPI PCI host bridge
   driver.
 
 - Fix for recently broken OMAP cpufreq build from Viresh Kumar.
 
 - Fix for a recent hibernation regression related to s2disk.
 
 - Fix for a locking-related regression in the ACPI EC driver from
   Puneet Kumar.
 
 - System suspend error code path fix related to runtime PM and
   runtime PM documentation update from Ulf Hansson.
 
 - cpufreq's conservative governor fix from Xiaoguang Chen.
 
 - New processor IDs for intel_idle and turbostat and removal of
   an obsolete Kconfig option from Len Brown.
 
 - New device IDs for the ACPI LPSS (Low-Power Subsystem) driver and
   ACPI-based PCI hotplug (ACPIPHP) cleanup from Mika Westerberg.
 
 - Removal of several ACPI video DMI blacklist entries that are not
   necessary any more from Aaron Lu.
 
 - Rework of the ACPI companion representation in struct device and
   code cleanup related to that change from Rafael J Wysocki,
   Lan Tianyu and Jarkko Nikula.
 
 - Fixes for assigning names to ACPI-enumerated I2C and SPI devices
   from Jarkko Nikula.
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQIcBAABCAAGBQJSjLYNAAoJEILEb/54YlRxkEQP/1pmFWNwSsxLtTHd+PEs0Xbo
 QccqvjQrnw/c8GcmK4eZrz6/xyuepmmjy9kfRKj2ENZniy0NEsSFqkTdSO3vYlva
 8HKWUj7MV3evhFERXAF6Tu0b4Enx4jOP7VMtmYxJo3qrSnKRUcUzc6DGv/ACsUT1
 Nkj0Lhdsg053Z+YzIXrl50w0tCDEMhVmWlMHBtYgr+dMNVnkfPBGkqMblMkKCXT2
 w/yHvauZlxQHtI+8bVqTuGgNN0CPzdlpFGiuUF+5mDf6dRX8zlSn56Ia+Wyw1k9X
 dQp4jYQOgPRo03rNKqQPDiPxUdc7T0RAHRvDB51Ncweuh5PfZGguQe71p6/LKY2W
 i6zblZ0f/vc13hTiMrP+qzKcwZvgPB5DH7SfnHr61JKV7GNFCdYAqoceS5hYMzR9
 d2Fd+txgm763IHWewXfDS/G2cU492R5qr4jpmUIACBQKWDZcqmSRDwRj83t56Ltb
 jgFBMbg4vZxG7IARhind74xsALxdhsgmFjPmx+0qPWjYxcU8otQZpXbgGNI9iOuW
 pxIQv5WPQW0tTmwO4HSuVCOwDPLPz5R0jkev7SvSj3Ek3TeD7He4LmnK055CATiC
 puq+6dp1FISPOPJYk+0DI61qN/CB/qNwRp8LU3ctZwudPVhznIE9FFQ3iN1FdBg2
 X8VDcT9t7VvVuxSBjgkj
 =QMp+
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-2-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull more ACPI and power management updates from Rafael Wysocki:

 - ACPI-based device hotplug fixes for issues introduced recently and a
   fix for an older error code path bug in the ACPI PCI host bridge
   driver

 - Fix for recently broken OMAP cpufreq build from Viresh Kumar

 - Fix for a recent hibernation regression related to s2disk

 - Fix for a locking-related regression in the ACPI EC driver from
   Puneet Kumar

 - System suspend error code path fix related to runtime PM and runtime
   PM documentation update from Ulf Hansson

 - cpufreq's conservative governor fix from Xiaoguang Chen

 - New processor IDs for intel_idle and turbostat and removal of an
   obsolete Kconfig option from Len Brown

 - New device IDs for the ACPI LPSS (Low-Power Subsystem) driver and
   ACPI-based PCI hotplug (ACPIPHP) cleanup from Mika Westerberg

 - Removal of several ACPI video DMI blacklist entries that are not
   necessary any more from Aaron Lu

 - Rework of the ACPI companion representation in struct device and code
   cleanup related to that change from Rafael J Wysocki, Lan Tianyu and
   Jarkko Nikula

 - Fixes for assigning names to ACPI-enumerated I2C and SPI devices from
   Jarkko Nikula

* tag 'pm+acpi-2-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (24 commits)
  PCI / hotplug / ACPI: Drop unused acpiphp_debug declaration
  ACPI / scan: Set flags.match_driver in acpi_bus_scan_fixed()
  ACPI / PCI root: Clear driver_data before failing enumeration
  ACPI / hotplug: Fix PCI host bridge hot removal
  ACPI / hotplug: Fix acpi_bus_get_device() return value check
  cpufreq: governor: Remove fossil comment in the cpufreq_governor_dbs()
  ACPI / video: clean up DMI table for initial black screen problem
  ACPI / EC: Ensure lock is acquired before accessing ec struct members
  PM / Hibernate: Do not crash kernel in free_basic_memory_bitmaps()
  ACPI / AC: Remove struct acpi_device pointer from struct acpi_ac
  spi: Use stable dev_name for ACPI enumerated SPI slaves
  i2c: Use stable dev_name for ACPI enumerated I2C slaves
  ACPI: Provide acpi_dev_name accessor for struct acpi_device device name
  ACPI / bind: Use (put|get)_device() on ACPI device objects too
  ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro
  ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
  cpufreq: OMAP: Fix compilation error 'r & ret undeclared'
  PM / Runtime: Fix error path for prepare
  PM / Runtime: Update documentation around probe|remove|suspend
  cpufreq: conservative: set requested_freq to policy max when it is over policy max
  ...
2013-11-20 13:25:04 -08:00
Daniel Vetter
f727b490ef drm/i915: Fix gen3 self-refresh watermarks
This regression has been introduced in

commit 4fe8590a92
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Sep 4 18:25:22 2013 +0300

    drm/i915: Use adjusted_mode appropriately when computing watermarks

I guess we should renable the enabled local variable into something a
notch more descriptive, but that's something for -next.

The effect on my i945gme netbook is pretty severe amounts of underruns
- usually the very first pixel gets used for the entire screeen.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-20 15:52:52 +01:00
Daniel Vetter
1021442098 drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
Haswell's DDI encoders have their own ->get_config callback and in

commit c6cd2ee2d5
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 21 10:52:07 2013 +0300

    drm/i915/dp: workaround BIOS eDP bpp clamping issue

we've forgotten to replicate this hack. So let's do it that.

Note for backporters: The above commit and all it's depencies need to
be backported first.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Cc: stable@vger.kernel.org
Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-19 16:59:39 +01:00
Chris Wilson
7c6c2652ba drm/i915: Do not enable package C8 on unsupported hardware
If the hardware does not support package C8, then do not even schedule
work to enable it. Thereby we can eliminate a bunch of dangerous work.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-19 13:05:09 +01:00
Chris Wilson
be1c1fe21b drm/i915: Hold pc8 lock around toggling pc8.gpu_idle
We need to hold the pc8 lock around toggling the value of gpu_idle.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-19 13:03:38 +01:00
Daniel Vetter
1d37b689b1 drm/i915: encoder->get_config is no longer optional
We must have one to fill out the adjusted_mode.crtc_clock. And with
the tv encoder fixed up every encoder we have has a ->get_config
callback. So we can drop the checks.

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>
2013-11-18 22:24:49 +01:00
Daniel Vetter
7a495cfd9b drm/i915/tv: add ->get_config callback
We need this to properly fill in adjusted_mode.crtc_clock, otherwise
the state checker gets unhappy. This seems to have been forgotten in
the big clock rework in

commit 18442d0878
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 13 16:00:08 2013 +0300

    drm/i915: Fix port_clock and adjusted_mode.clock readout all over

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-18 22:24:33 +01:00
Daniel Vetter
ef46e0d247 drm/i915: restore the early forcewake cleanup
Some BIOS just leak the forcewak bits, which we clean up.
Unfortunately this has been broken in

commit 521198a2e7
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Aug 23 16:52:30 2013 +0300

    drm/i915: sanitize forcewake registers on reset

To make this work both for resets and for BIOS takeover just add the
forcewake clearing call back to intel_uncore_early_sanitize.

We need to clear the forcewake in early sanitize so that the forcewak
dance in intel_uncore_init (to figure out whether we have mt or legacy
forcewake on ivb) works. That cleanup fits in nicely with the general
topic of early_sanitize to prepare for the very first mmio ops.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jörg Otte <jrg.otte@gmail.com>
Cc: Jörg Otte <jrg.otte@gmail.com>
References: https://lkml.org/lkml/2013/11/16/40
Cc: stable@vger.kernel.org (for 3.12 only)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-17 20:39:51 +01:00
Daniel Vetter
29c78f609e Partially revert "drm/i915: tune the RC6 threshold for stability"
This reverts commit 351aa5666d.

It breaks rc6 on at least one snb machine. Since we don't yet have a
report for ivb let's keep it there for now.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71656
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: erik@vontaene.de
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-16 16:05:41 +01:00
Daniel Vetter
b2ea8ef559 drm/i915: flush cursors harder
Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.

I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update mechanism works differently, and there's some
additional rules about what can be updated in which order.

Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Cc: stable@vger.kernel.org
Cc:  Thomas Richter <thor@math.tu-berlin.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-15 20:22:34 +01:00
Linus Torvalds
049ffa8ab3 Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
Pull drm updates from Dave Airlie:
 "This is a combo of -next and some -fixes that came in in the
  intervening time.

  Highlights:

  New drivers:
    ARM Armada driver for Marvell Armada 510 SOCs

  Intel:
    Broadwell initial support under a default off switch,
    Stereo/3D HDMI mode support
    Valleyview improvements
    Displayport improvements
    Haswell fixes
    initial mipi dsi panel support
    CRC support for debugging
    build with CONFIG_FB=n

  Radeon:
    enable DPM on a number of GPUs by default
    secondary GPU powerdown support
    enable HDMI audio by default
    Hawaii support

  Nouveau:
    dynamic pm code infrastructure reworked, does nothing major yet
    GK208 modesetting support
    MSI fixes, on by default again
    PMPEG improvements
    pageflipping fixes

  GMA500:
    minnowboard SDVO support

  VMware:
    misc fixes

  MSM:
    prime, plane and rendernodes support

  Tegra:
    rearchitected to put the drm driver into the drm subsystem.
    HDMI and gr2d support for tegra 114 SoC

  QXL:
    oops fix, and multi-head fixes

  DRM core:
    sysfs lifetime fixes
    client capability ioctl
    further cleanups to device midlayer
    more vblank timestamp fixes"

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (789 commits)
  drm/nouveau: do not map evicted vram buffers in nouveau_bo_vma_add
  drm/nvc0-/gr: shift wrapping bug in nvc0_grctx_generate_r406800
  drm/nouveau/pwr: fix missing mutex unlock in a failure path
  drm/nv40/therm: fix slowing down fan when pstate undefined
  drm/nv11-: synchronise flips to vblank, unless async flip requested
  drm/nvc0-: remove nasty fifo swmthd hack for flip completion method
  drm/nv10-: we no longer need to create nvsw object on user channels
  drm/nouveau: always queue flips relative to kernel channel activity
  drm/nouveau: there is no need to reserve/fence the new fb when flipping
  drm/nouveau: when bailing out of a pushbuf ioctl, do not remove previous fence
  drm/nouveau: allow nouveau_fence_ref() to be a noop
  drm/nvc8/mc: msi rearm is via the nvc0 method
  drm/ttm: Fix vma page_prot bit manipulation
  drm/vmwgfx: Fix a couple of compile / sparse warnings and errors
  drm/vmwgfx: Resource evict fixes
  drm/edid: compare actual vrefresh for all modes for quirks
  drm: shmob_drm: Convert to clk_prepare/unprepare
  drm/nouveau: fix 32-bit build
  drm/i915/opregion: fix build error on CONFIG_ACPI=n
  Revert "drm/radeon/audio: don't set speaker allocation on DCE4+"
  ...
2013-11-15 14:19:54 +09:00
Duncan Laurie
f69e515699 i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7
We had been using a DMI table workaround to select the right
frequency for devices, but this is fragile and must be updated
with every new platform.

Instead the default case when VBT is missing is changed to use
120MHz clock for LVDS SSC for these generations.

The docs for 2010-Core, SandyBridge, and IvyBridge all indicate
that the reference frequency for LVDS is 120MHz:

"2010 Core"
http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
page 38
Reference Frequency: 120MHz for CRT and LVDS.  100MHz for the FDI.

"2011 SandyBridge"
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
page 33
Reference Frequency: 120MHz for CRT, HDMI, LVDS.  100MHz for the FDI.

"2012 IvyBridge"
http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf
page 27
Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI.

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
[olof: Fixup for recent base, switched from if/else to single call]
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-15 00:38:44 +01:00
Rafael J. Wysocki
3a83f99249 ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro
Since DEVICE_ACPI_HANDLE() is now literally identical to
ACPI_HANDLE(), replace it with the latter everywhere and drop its
definition from include/acpi.h.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-14 23:17:21 +01:00
Ben Widawsky
596cc11e7a drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell
The pipe B and pipe C interrupt mask and enable registers are now part
of the pipe, so disabling the pipe power wells will lost the contests of
the registers.

Art totally debugged this one!

v2: Use the irq_lock to clarify code, and prevent future bugs (Daniel)

Cc: Art Runyan <arthur.j.runyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Make sparse happy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:12 +01:00
Ben Widawsky
3a2ffb65ee drm/i915/bdw: Limit GTT to 2GB
Because of the way in which we're allocating the pages for the Aliasing
PPGTT, we cannot actually successfully alloc enough space for anything
greater than 2GB.

Instead of a quick hack to fix this, we should defer until we have the
real solution in place (allocating much less contiguous space).

This wasn't found sooner because we didn't not have any systems
supporting more than a 2GB GTT.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:11 +01:00
Ben Widawsky
eb0d4b75d5 drm/i915/bdw: Add comment about gen8 HWS PGA
This confused me some many times that I think it is appropriate to add a
small comment to instruct the reader of the code that it is indeed doing
what it is supposed to do.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:11 +01:00
Ben Widawsky
230f955f73 drm/i915/bdw: Free correct number of ppgtt pages
I am unclear how this got messed up in the shuffle, but it did.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:10 +01:00
Ben Widawsky
935e8de975 drm/i915/bdw: Do gen6 style reset for gen8
This patch existed before, but was lost over time.

Note that reset is still somewhat problematic in my limited testing (ie.
module_reload will not pass) but it can be disabled with a module
parameter, and support should be considered preliminary anyway.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:10 +01:00
Ben Widawsky
f8e100621b drm/i915/bdw: GEN8 backlight support
Prior to Haswell the CPU control register for backlight
(BLC_PWM_CPU_CTL) toggled the PCH baclight pin for us. This made some
sense as there was no pin on the CPU. With Haswell came the introduction
of a CPU backlight pin, but the interface was still controlled by
software with the same mechnism. Behind the scenes, hardware did all the
dirty work for us.

Broadwell no longer provides this for free. If we want to use the PCH
backlight pin [1] then we have to set the override bit BLC_PWM_PCH_CTL1
and program BLC_PWM_PCH_CTL2 for the PWM values.

This patch implements that. This patch is compile tested only, and given
that I rarely if ever touch this code, careful review is welcome.

[1] According to Art, we know of no devices that exist which use the CPU
pin (and remember it has existed already on HSW). If such a device does
exist, we'll have to handle it properly - this is left as TODO until
then.

v2: Drop the abstraction prep patch, as a bigger backlight overhaul is
    in the works, and do just the mimimal bdw enabling now. (by Jani)

CC: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:09 +01:00
Ben Widawsky
5dd8c4c3f1 drm/i915/bdw: Add BDW to ULT macro
For what we care about ULT and ULX are interchangeable. We know of 3
types of pciids for these cases. I am not sure if at some point we will
need to distinguish ULT and ULX.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-14 09:33:08 +01:00