Commit Graph

14026 Commits

Author SHA1 Message Date
Daniel Vetter
38aecea0cc drm/i915: reverse dp link param selection, prefer fast over wide again
... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.

This reverts

commit 2514bc510d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs

I'm pretty sure I'll regret this patch, but otoh I expect we won't
make progress here without poking the devil occasionally.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
Cc: peter@colberg.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Itai BEN YAACOV <candeb@free.fr>
Tested-by: David En <d.engraf@arcor.de>
Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:42 +01:00
Mika Kuoppala
5babf0fc26 drm/i915: No need to put forcewake after a reset
As we now have intel_uncore_forcewake_reset() no need
to do explicit put after reset.

v2: rebase

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:41 +01:00
Damien Lespiau
96a6f0f1db drm/i915: Fix i915_switch_context() argument name in kerneldoc
While reading some code, out of boredom, stumbled on a tiny tiny fix.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:41 +01:00
Damien Lespiau
9ad6ce5102 drm/i915: Remove unused to_gem_object() macro
That macro was only ever used to convert ring->private into a gem object
(hence the forceful cast). ring->private doesn't even exist anymore as
it was transmogrified by Chris in:

  commit 0d1aacac36
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Mon Aug 26 20:58:11 2013 +0100

      drm/i915: Embed the ring->private within the struct intel_ring_buffer

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:40 +01:00
Damien Lespiau
cb216aa844 drm/i915: Make i915_gem_retire_requests_ring() static
Its last usage outside of i915_gem.c was removed in:

  commit 1f70999f90
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Mon Jan 27 22:43:07 2014 +0000

     drm/i915: Prevent recursion by retiring requests when the ring is full

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:39 +01:00
Patrik Jakobsson
b3064154df drm/i915: Don't just say it, actually force edp vdd
This patch fixes the blank screen bug introduced in 3.14-rc1 on the
MacBook Air 6,2. The comments state that we need to force edp vdd so
lets put it back.

The regression was introduced by the following commit:

commit dff392dbd2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 6 17:32:41 2013 -0200

    drm/i915: don't touch the VDD when disabling the panel

v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:38 +01:00
Damien Lespiau
d615a16622 drm/i915: Make num_sprites a per-pipe value
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:38 +01:00
Damien Lespiau
1fe477856e drm/i915: Add a for_each_sprite() macro
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:37 +01:00
Damien Lespiau
07d27e20bc drm/i915: Replace a few for_each_pipe(i) by for_each_pipe(pipe)
Consistency throughout the code base is good and remove some room for
mistakes (as explained in the "drm/i915: Use a pipe variable to cycle
through the pipes" commit)

So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe)
when it's reasonable and practical to do so (eg. when there isn't another
pipe variable already).

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:36 +01:00
Damien Lespiau
e3d5128534 drm/i915: Don't declare unnecessary shadowing variable
'i' is already defined in the function scope and used elsewhere. Let's
use it instead.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:36 +01:00
Damien Lespiau
8cc87b7549 drm/i915: Use a pipe variable to cycle through the pipes
I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.

This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time around.

It's all a lame excuse, but it does make it harder to redo the same
mistake.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:35 +01:00
Ville Syrjälä
8285222c48 drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:34 +01:00
Ville Syrjälä
4f1ca9e940 drm/i915: Implement WaDisableSDEUnitClockGating:bdw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:33 +01:00
Ville Syrjälä
295e8bb73a drm/i915: Disable semaphore wait event idle message on BDW
According to BSpec we need to always set this magic bit in ring buffer
mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:33 +01:00
Ville Syrjälä
619d4d0472 drm/i915: Use DIV_ROUND_UP() when calculating number of required FDI lanes
If we need precisely N lanes to satisfy the FDI bandwidth requirement,
the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP()
to get a more accurate answer.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:32 +01:00
Ville Syrjälä
8f7abfd822 drm/i915: Fix DDI port_clock for VGA output
On DDI there's no PLL as such to generate the pixel clock for VGA.
Instead we derive the pixel clock from the FDI link frequency. So
to make .compute_config match what .get_config does, we need to
set the port_clock based on the FDI link frequency.

Note that we don't even check the port_clock when selecting the
PLL for VGA output. We just assume SPLL at 1.35GHz is what we want,
and that does match with the asumption of FDI frequency of 2.7Ghz
we have in intel_fdi_link_freq().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74955
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:31 +01:00
Mika Kuoppala
6a68735a9d drm/i915: Don't access fifodbg registers on gen8
as they don't exists.

v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called
    with gen6 (Chris)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:31 +01:00
Mika Kuoppala
0a089e3355 drm/i915: Do forcewake reset on gen8
When we get control from BIOS there might be mt forcewake
bits already set. This causes us to do double mt get
without proper clear/ack sequence.

Fix this by clearing mt forcewake register on init,
like we do with older gens.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:30 +01:00
Jani Nikula
c923facd53 drm/i915: don't flood the logs about bdw semaphores
BDW is no longer flagged as preliminary hw, but without
i915.preliminary_hw_support module param set the logs are filled with
WARNs about it.

Just make semaphores off the BDW per-chip default for now.

CC: Ben Widawsky <ben@bwidawsk.net>
Reported-by: Sebastien Dufour <sebastien.dufour@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:29 +01:00
Kenneth Graunke
1411e6a57a drm/i915: Add thread stall DOP clock gating workaround on Broadwell.
Ben and I believe this will be necessary on production hardware.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Shuffle lines to group all ROW_CHICKEN writes and add a
cautious comment that this might not be needed on production hw.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:29 +01:00
Kenneth Graunke
c8966e1058 drm/i915: Add a partial instruction shootdown workaround on Broadwell.
I believe this will be necessary on production hardware.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Fix whitespace fail spotted by checkpatch. Also add missing
:bdw w/a tag that Ville spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:28 +01:00
Mika Kuoppala
62d5d69b49 drm/i915: Add suspend count to error state
For example if we get bug reports with similar error states and
suspend count is always 1, that might lead the Sherlocks to
right general direction.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:27 +01:00
Mika Kuoppala
48b031e30d drm/i915: Add reset count to error state
By default we keep only the error state from first hang. However
some sneaky user might have cleared the first error state and we
assume mistakenly that it is from first hang. As sometimes this
matters, it is better to explicitly store the reset count.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:26 +01:00
Mika Kuoppala
581744626d drm/i915: Add reason for capture in error state
We capture error state not only when the GPU hangs but also on
other situations as in interrupt errors and in situations where
we can kick things forward without GPU reset. There will be log
entry on most of these cases. But as error state capture might be
only thing we have, if dmesg was not captured. Or as in GEN4 case,
interrupt error can trigger error state capture without log entry,
the exact reason why capture was made is hard to decipher.

v2: Split out the the error code stuff to separate patch (Ben)

References: https://bugs.freedesktop.org/show_bug.cgi?id=74193
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:26 +01:00
Mika Kuoppala
cb38300215 drm/i915: Add error code into error state
commit 011cf577b2
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Tue Feb 4 12:18:55 2014 +0000

    drm/i915: Generate a hang error code

added error code debug into dmesg. Store this also
with error state to make matching dmesg logs and error
states easier.

As we need to have full ring state for error code generation,
do full capture always, print hang message into log and then
decide if we need to keep the error state.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:25 +01:00
Chris Wilson
ab0e7ff9f2 drm/i915: Record pid/comm of hanging task
After finding the guilty batch and request, we can use it to find the
process that submitted the batch and then add the culprit into the error
state.

This is a slightly different approach from Ben's in that instead of
adding the extra information into the struct i915_hw_context, we use the
information already captured in struct drm_file which is then referenced
from the request.

v2: Also capture the workaround buffer for gen2, so that we can compare
    its contents against the intended batch for the active request.

v3: Rebase (Mika)
v4: Check for null context (Chris)
    checkpatch warnings fixed

Link: http://lists.freedesktop.org/archives/intel-gfx/2013-August/032280.html
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v4)
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:24 +01:00
Chris Wilson
8d9fc7fd2d drm/i915: Rely on accurate request tracking for finding hung batches
In the past, it was possible to have multiple batches per request due to
a stray signal or ENOMEM. As a result we had to scan each active object
(filtered by those having the COMMAND domain) for the one that contained
the ACTHD pointer. This was then made more complicated by the
introduction of ppgtt, whereby ACTHD then pointed into the address space
of the context and so also needed to be taken into account.

This is a fairly robust approach (though the implementation is a little
fragile and depends upon the per-generation setup, registers and
parameters). However, due to the requirements for hangstats, we needed a
robust method for associating batches with a particular request and
having that we can rely upon it for finding the associated batch object
for error capture.

If the batch buffer tracking is not robust enough, that should become
apparent quite quickly through an erroneous error capture. That should
also help to make sure that the runtime reporting to userspace is
robust. It also means that we then report the oldest incomplete batch on
each ring, which can be useful for determining the state of userspace at
the time of a hang.

v2: Use i915_gem_find_active_request (Mika)

v3: remove check for ring->get_seqno, split long lines (Ben)

v4: check that context is available (Chris)
    checkpatch warnings fixed

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:24 +01:00
Chris Wilson
64bf930379 drm/i915: Reset vma->mm_list after unbinding
In place of true activity counting, we walk the list of vma associated
with an object managing each on the vm's active/inactive list everytime
we call move-to-inactive. This depends upon the vma->mm_list being
cleared after unbinding, or else we run into difficulty when tracking
the object in multiple vm's - we see a use-after free and corruption of
the mm_list.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:23 +01:00
Ville Syrjälä
6fe7286530 drm/i915: Streamline VLV forcewake handling
It occured to me that when we're trying to wake up both render
and media wells on VLV, we might end up calling the low level
force_wake_get/put two times even though one call would be
enough. Make that happen by figuring out which wells really
need to be woken up based on the forcewake counts.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by:Deepak S <deepak.s@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:22 +01:00
Ville Syrjälä
fc9d83f747 drm/i915: Drop the forcewake count inc/dec around register read on VLV
VLV is the only platform where we increment/decrement the forcewake
count around register access. Drop the inc/dec on VLV to make the
forcewake code a bit more unified.

The inc/dec are not necessary since we hold the uncore lock around
the whole operation.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:22 +01:00
Ville Syrjälä
ee7fa12ce4 drm/i915: Fix VLV forcewake after reset
Use the render/media specific forcewake counts to properly restore the
forcewake status after a GPU reset on VLV.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:21 +01:00
Chris Wilson
f900db4758 drm/i915: Perform pageflip using mmio if the GPU is terminally wedged
After a hang and failed reset, we cannot use the GPU to execute the page
flip instructions. Instead we can force a synchronous mmio flip. (Later,
we can reduce the synchronicity of the mmio flip by moving some of the
delays off to a worker, like the current page flip code; see vblank
tasks.)

References: https://bugs.freedesktop.org/show_bug.cgi?id=72631
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:20 +01:00
Paulo Zanoni
6f0ea9e212 drm/i915: assert we're not runtime suspended when accessing registers
I could swear this was already happening in the current code...

Also, put the reads and writes in a generic place, so we don't forget
it again when we add runtime PM support to new platforms.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:19 +01:00
Paulo Zanoni
e998c40fed drm/i915: assert force wake is disabled when we runtime suspend
Just to be sure...

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:19 +01:00
Paulo Zanoni
b2ec142cb0 drm/i915: call assert_device_not_suspended at gen6_force_wake_work
Because we shouldn't be runtime suspended when forcewake is supposed
to be enabled.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Update commit message - no WARN expected since the bugfix for
issues hit with this assert is already in. And resolve conflicts with
the change from worker to timer for the delayed fw release.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:18 +01:00
Paulo Zanoni
86c4ec0d32 drm/i915: kill dev_priv->pc8.gpu_idle
Since the addition of dev_priv->mm.busy, there's no more need for
dev_priv->pc8.gpu_idle, so kill it.

Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and
hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and
hsw_disable_package_c8, so just use them.

Also, when we boot the machine, dev_priv->mm.busy initially considers
the machine as idle. This is opposed to dev_priv->pc8.gpu_idle, which
considered it busy. So dev_priv->pc8.disable_count has to be
initalized to 1 now.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:17 +01:00
Paulo Zanoni
36623ef837 drm/i915: get/put runtime PM in more places at i915_debugfs.c
These are places where we read (not write) registers while we're
runtime suspended.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:17 +01:00
Paulo Zanoni
c19a0df2ac drm/i915: get runtime PM while trying to detect CRT
Otherwise we'll read registers that return 0xffffffff, trigger some
WARNs, think CRT is actually connected (because certain bits are 1),
and fail the drm-resources-equal testcase!

Tested on a SNB machine with runtime PM support (which is not upstream
yet, but is already on my public tree at freedesktop.org, and will
hopefully eventually become upstream).

Testcase: igt/pm_pc8/drm-resources-equal
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:16 +01:00
Paulo Zanoni
6d88064edc drm/i915: put runtime PM only when we actually release force_wake
When we call gen6_gt_force_wake_put we don't actually put force_wake,
we just schedule gen6_force_wake_work through mod_delayed_work, and
that will eventually release force_wake.

The problem is that we call intel_runtime_pm_put directly at
gen6_gt_force_wake_put, so most of the times we put our runtime PM
reference before the delayed work happens, so we may runtime suspend
while force_wake is still supposed to be enabled if the graphics
autosuspend_delay_ms is too small.

Now the nice thing about the current code is that after it triggers
the delayed work function it gets a refcount, and it only triggers the
delayed work function if refcount is zero. This guarantees that when
we schedule the funciton, it will run before we try to schedule it
again, which simplifies the problem and allows for the current
solution to work properly (hopefully!).

v2: - Keep the VLV refcounts balanced (Jesse)

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:15 +01:00
Paulo Zanoni
bb4cdd5345 drm/i915: put runtime PM only at the end of intel_mark_idle
Because intel_mark_idle still touches some registers: it needs the
machine to be awake. If you set both the autosuspend and PC8 delays to
zero, you can get a "Device suspended" WARN when gen6_rps_idle touches
registers.

This is not easy to reproduce, but happens once in a while when
running pm_pc8.

Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:14 +01:00
Ville Syrjälä
ccc7bed05e drm/i915: Don't ban default context when stop_rings!=0
If we've explicitly stopped the rings for testing purposes, don't ban
the default context. Fixes kms_flip hang tests.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:14 +01:00
Jesse Barnes
f103fc7db7 drm/i915: print connector mode list in display_info
Useful for bug reports.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:13 +01:00
Shobhit Kumar
ea9a6bafcf drm/i915: Update VBT data structures to have MIPI block enhancements
MIPI Block #52 which provides configuration details for the MIPI panel
including dphy settings as per panel and tcon specs

Block #53 gives information on panel enable sequences

v2: Address review comemnts from Jani
    - Move panel ids from intel_dsi.h to intel_bios.h
    - bdb_mipi_config structure improvements for cleaner code
    - Adding units for the pps delays, all in ms
    - change data structure to be more cleaner and simple

v3: Corrected the unit for pps delays as 100us

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:12 +01:00
Chris Wilson
8232644ccf drm/i915: Convert the forcewake worker into a timer func
We don't want to suffer scheduling delay when turning off the GPU after
waking it up to touch registers. Ideally, we only want to keep the GPU
awake for the register access sequence, with a single forcewake dance on
the first access and release immediately after the last. We set a timer
on the first access so that we only dance once and on the next scheduler
tick, we drop the forcewake again.

This moves the cleanup routine from the common i915 workqueue to a timer
func so that we don't anger powertop, and drop the forcewake again
quicker.

v2: Enable the deferred force_wake_put for regular register reads as
    well.
v3: Beautification and make sure we disable forcewake when shutting
    down.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
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-03-05 21:30:12 +01:00
Ben Widawsky
8f94d24b7b drm/i915/bdw: Add FBC support
This got lost when we shuffled around our internal branch and
GEN7_FEATURES macro. There were no HW changes to support FBC, so we just
need to set the flag.

v2: Don't allow FBC for any pipe but A on platforms with DDI. (Paulo)

Cc: Daisy Sun <daisy.sun@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:11 +01:00
Chris Wilson
f62a007603 drm/i915: Accurately track when we mark the hardware as idle/busy
We currently call intel_mark_idle() too often, as we do so as a
side-effect of processing the request queue. However, we the calls to
intel_mark_idle() are expected to be paired with a call to
intel_mark_busy() (or else we try to idle the hardware by accessing
registers that are already disabled). Make the idle/busy tracking
explicit to prevent the multiple calls.

v2: We can drop some of the complexity in __i915_add_request() as
queue_delayed_work() already behaves as we want (not requeuing the item
if it is already in the queue) and mark_busy/mark_idle imply that the
idle task is inactive.

v3: We do still need to cancel the pending idle task so that it is sent
again after the current busy load completes (not in the middle of it).

Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
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>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:10 +01:00
Mika Kuoppala
e9dbd2b202 drm/i915: Fix forcewake counts for gen8
Sometimes generic driver code gets forcewake explicitly by
gen6_gt_force_wake_get(), which check forcewake_count before accessing
hardware. However the register access with gen8_write function access
low level hw accessors directly, ignoring the forcewake_count. This
leads to nested forcewake get from hardware, in ring init and possibly
elsewhere, causing forcewake ack clear errors and/or hangs.

Fix this by checking the forcewake count also in gen8_write

v2: Read side doesn't care about shadowed registers,
    Remove __needs_put funkiness from gen8_write. (Ville)
    Improved commit message.

References: https://bugs.freedesktop.org/show_bug.cgi?id=74007
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: 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-03-05 21:30:09 +01:00
Imre Deak
93c73e8c6e drm/i915: move hsw power domain comment to its right place
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:09 +01:00
Imre Deak
0409875394 drm/i915: use power domain api to check vga power state
This way we can reuse the check on other platforms too. Also factor out
a version of the function that doesn't check if the power is on, we'll
need to call this from within the power domain framework.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:08 +01:00
Imre Deak
e13192f6c1 drm/i915: switch order of power domain init wrt. irq install
On VLV at least the display IRQ register access and functionality
depends on its power well to be on, so move the power domain HW init
before we install the IRQs.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:07 +01:00
Imre Deak
da7e29bd5b drm/i915: use drm_i915_private everywhere in the power domain api
The power domains framework is internal to the i915 driver, so pass
drm_i915_private instead of drm_device to its functions.

Also remove a dangling intel_set_power_well() declaration.

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:07 +01:00
Daniel Vetter
7e696e4cad drm/i915: ignore bios output config if not all outputs are on
Both Ville and QA rather immediately complained that with the new
initial_config logic from Jesse not all outputs get enabled. Since the
fbdev emulation pretty much tries to always enable as many outputs as
possible (it even has hotplug handling and all that) fall back if more
outputs could have been enabled.

v2: Fix up my confusion about what enabled means - it's passed from
the fbdev helper, we need to check for a non-zero connector->encoder
link. Spotted by Ville.

v3: Add some debug output as requested by Jesse for debugging fallback
issues.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75552
Tested-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>
2014-03-05 21:30:06 +01:00
Daniel Vetter
7c2bb53110 drm/i915: s/any_enabled/!fallback/ in fbdev_initial_config
It started as a simple check whether anything is lit up, but now is't
used to driver the general fallback logic to the default output
configuration selector in the helper library. So rename it for more
clarity.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:05 +01:00
Chris Wilson
7d5e379989 drm/i915: Reject changes of fb base when we have a flip pending
This should be impossible due to the wait for outstanding flips that the
caller is meant to perform prior to updating the scanout base. Paranoia
tells me to check anyway.

References: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:05 +01:00
Chris Wilson
227213438a Revert "drm/i915: enable HiZ Raw Stall Optimization on IVB"
This reverts commit 116f2b6da8.

This optimization causes widespread corruption in games, and even in
glxgears, on my ivb:gt1. The corruption appears like z-fighting of
overlapping polygons in the HiZ buffer.

The observation ties in very closely with the description of the
optimization disabled by default on IVB:

"The Hierarchical Z RAW Stall Optimization allows non-overlapping
polygons in the same 8x4 pixel/sample area to be processed without
stalling waiting for the earlier ones to write to Hierarchical Z
buffer."

No reason is given for why it is disabled by default, usually for such
optimizations it is that it is incomplete. However, there is no
indication whether this a gt1 only issue either. Before considering
reenabling this optimization, I would first suggest reproducing the
corruption in piglit.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75623
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chia-I Wu <olv@lunarg.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:04 +01:00
Jesse Barnes
8b687df4c3 drm/i915: re-add locking around hw state readout
To silence locking complaints.  This was a rebase failure on my part in

commit fa9fa083d0
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Feb 11 15:28:56 2014 -0800

    drm/i915: read out hw state earlier v2

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
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>
2014-03-05 21:30:03 +01:00
Jesse Barnes
ef34ab894e drm/i915: honor forced connector modes v2
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off.  Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config.

v2: don't deref connector state for disabled connectors (Jesse)

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:02 +01:00
Chris Wilson
1af8452f16 drm/i915: Revert workaround for disabling L3 cache aging on IVB
In commit e4e0c058a1
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Wed Feb 8 12:53:50 2012 -0800

    drm/i915: gen7: Implement an L3 caching workaround.

the L3 cache aging was disabled. This was part of a shotgun response
to a number of GPU hang bugs, but there appears to be no documentation
to suggest that disabling the L3 cache age was ever required (to prevent
the GPU hangs).

Restoring the L3 cache age is a minor performance win of around 2%
on IVB:GT2. (Note that this value seems to be consistent across a number
of tests and so appears to be above the usual noise.)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:02 +01:00
Sinclair Yeh
47e74f0fd1 drm/i915: Revert workaround for disabling L3 cache aging on BYT
V2:  edit the commit message to contain more info
The W/A spreadsheet says this is still required, but the b-spec says
it's not for BYT-T.  So the documentation is not clear.  However,
our experience with the other SKUs of BYT-I/M on Android and Linux
suggests that setting this bit actually causes GPU hang for certain
OGL benchmark applications.

Removing this bit completely resolves the GPU hangs.

Signed-off-by: Sinclair Yeh <sinclair.yeh@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:01 +01:00
Ben Widawsky
5abbcca30d drm/i915/bdw: Kill ppgtt->num_pt_pages
With the original PPGTT implementation if the number of PDPs was not a
power of two, the number of pages for the page tables would end up being
rounded up. The code actually had a bug here afaict, but this is a
theoretical bug as I don't believe this can actually occur with the
current code/HW..

With the rework of the page table allocations, there is no longer a
distinction between number of page table pages, and number of page
directory entries. To avoid confusion, kill the redundant (and newer)
struct member.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:00 +01:00
Ben Widawsky
b146520ff9 drm/i915: Split GEN6 PPGTT initialization up
Simply to match the GEN8 style of PPGTT initialization, split up the
allocations and mappings. Unlike GEN8, we skip a separate dma_addr_t
allocation function, as it is much simpler pre-gen8.

With this code it would be easy to make a more general PPGTT
initialization function with per GEN alloc/map/etc. or use a common
helper, similar to the ringbuffer code. I don't see a benefit to doing
this just yet, but who knows...

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:30:00 +01:00
Ben Widawsky
a00d825de9 drm/i915: Split GEN6 PPGTT cleanup
This cleanup is similar to the GEN8 cleanup (though less necessary).
Having everything split will make cleaning the initialization path error
paths easier to understand.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:29:59 +01:00
Ben Widawsky
c4ac524c15 drm/i915: Update i915_gem_gtt.c copyright
I keep meaning to do this... by now almost the entire file has been
written by an Intel employee (including Daniel post-2010).

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:29:58 +01:00
Ben Widawsky
7907f45bf9 Revert "drm/i915/bdw: Limit GTT to 2GB"
This reverts commit 3a2ffb65ee.

Now that the code is fixed to use smaller allocations, it should be safe
to let the full GGTT be used on BDW.

The testcase for this is anything which uses more than half of the GTT,
thus eclipsing the old limit.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:29:57 +01:00
Ben Widawsky
7ad47cf252 drm/i915/bdw: Reorganize PT allocations
The previous allocation mechanism would get 2 contiguous allocations,
one for the page directories, and one for the page tables. As each page
table is 1 page, and there are 512 of these per page directory, this
goes to 2MB. An unfriendly request at best. Worse still, our HW now
supports 4 page directories, and a 2MB allocation is not allowed.

In order to fix this, this patch attempts to split up each page table
allocation into a single, discrete allocation. There is nothing really
fancy about the patch itself, it just has to manage an extra pointer
indirection, and have a fancier bit of logic to free up the pages.

To accommodate some of the added complexity, two new helpers are
introduced to allocate, and free the page table pages.

NOTE: I really wanted to split the way we do allocations, and the way in
which we identify the page table/page directory being used. I found
splitting this functionality up to be too unwieldy. I apologize in
advance to the reviewer. I'd recommend looking at the result, rather
than the diff.

v2/NOTE2: This patch predated commit:
6f1cc99351
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Dec 31 15:50:31 2013 +0000

    drm/i915: Avoid dereference past end of page arr

It fixed the same issue as that patch, but because of the limbo state of
PPGTT, Chris patch was merged instead. The excess churn is a result of
my using my original patch, which has my preferred naming. Primarily
act_* is changed to which_*, but it's mostly the same otherwise. I've
kept the convention Chris used for the pte wrap (I had something
slightly different, and broken - but fixable)

v3: Rename which_p[..]e to drop which_ (Chris)
Remove BUG_ON in inner loop (Chris)
Redo the pde/pdpe wrap logic (Chris)

v4: s/1MB/2MB in commit message (Imre)
Plug leaking gen8_pt_pages in both the error path, as well as general
free case (Imre)

v5: Rename leftover "which_" variables (Imre)
Add the pde = 0 wrap that was missed from v3 (Imre)

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Squash in fixup from Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05 21:29:41 +01:00
Ben Widawsky
782f149523 drm/i915: Make clear/insert vfuncs args absolute
This patch converts insert_entries and clear_range, both functions which
are specific to the VM. These functions tend to encapsulate the gen
specific PTE writes. Passing absolute addresses to the insert_entries,
and clear_range will help make the logic clearer within the functions as
to what's going on. Currently, all callers simply do the appropriate
page shift, which IMO, ends up looking weird with an upcoming change for
the gen8 page table allocations.

Up until now, the PPGTT was a funky 2 level page table. GEN8 changes
this to look more like a 3 level page table, and to that extent we need
a significant amount more memory simply for the page tables. To address
this, the allocations will be split up in finer amounts.

v2: Replace size_t with uint64_t (Chris, Imre)

v3: Fix size in gen8_ppgtt_init (Ben)
Fix Size in i915_gem_suspend_gtt_mappings/restore (Imre)

Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:57:52 +01:00
Ben Widawsky
bf2b4ed291 drm/i915/bdw: Split ppgtt initialization up
Like cleanup in an earlier patch, the code becomes much more readable,
and easier to extend if we extract out helper functions for the various
stages of init.

Note that with this patch it becomes really simple, and tempting to begin
using the 'goto out' idiom with explicit free/fini semantics. I've
kept the error path as similar as possible to the cleanup() function to
make sure cleanup is as robust as possible

v2: Remove comment "NB:From here on, ppgtt->base.cleanup() should
function properly"
Update commit message to reflect above

v3: Rebased on top of bugfixes found in the previous patch by Imre
Moved number of pd pages assertion to the proper place (Imre)

v4:
Allocate dma address space for num_pd_pages, not num_pd_entries (Ben)
Don't use gen8_pt_dma_addr after free on error path (Imre)
With new fix from v4 of the previous patch.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:54:59 +01:00
Ben Widawsky
f3a964b96d drm/i915/bdw: Reorganize PPGTT init
Create 3 clear stages in PPGTT init. This will help with upcoming
changes be more readable. The 3 stages are, allocation, dma mapping, and
writing the P[DT]Es

One nice benefit to the patches is that it makes 2 very clear error
points, allocation, and mapping, and avoids having to do any handling
after writing PTEs (something which was likely buggy before). This
simplified error handling I suspect will be helpful when we move to
deferred/dynamic page table allocation and mapping.

The patches also attempts to break up some of the steps into more
logical reviewable chunks, particularly when we free.

v2: Don't call cleanup on the error path since that takes down the
drm_mm and list entry, which aren't setup at this point.

v3: Fixes addressing Imre's comments from:
<1392821989.19792.13.camel@intelbox>

Don't do dynamic allocation for the page table DMA addresses. I can't
remember why I did it in the first place. This addresses one of Imre's
other issues.

Fix error path leak of page tables.

v4: Fix the fix of the error path leak. Original fix still leaked page
tables. (Imre)

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:54:31 +01:00
Ben Widawsky
b18b6bde30 drm/i915/bdw: Free PPGTT struct
GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the
leak is small and only found on a module reload. ie. I don't think this
needs to go to stable.

v2: The very naive, kfree in gen8 ppgtt cleanup, is subject to a double
free on PPGTT initialization failure. (Spotted by Imre). Instead this
patch pulls the ppgtt struct freeing out of the cleanup and leaves it to
the allocators/callers or the one doing the last kref_put as in standard
convention

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:53:58 +01:00
Ben Widawsky
321f2ada91 drm/i915: Move ppgtt_release out of the header
At one time it was expected to be called in multiple places by kref_put.
At the current time however, it is all contained within
i915_gem_context.c.

This patch makes an upcoming required addition a bit nicer since it too
doesn't need to be defined in a header file.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:52:15 +01:00
Ville Syrjälä
c5c98a5899 drm/i915: Add a comment about WIZ hashing vs. thread counts
Add a comment next to our WIZ hashing setup to remind people about the
link between WIZ hashing disable bit and PS/WM thread counts.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:39:35 +01:00
Ville Syrjälä
36075a4cad drm/i915: Change BDW WIZ hashing mode to 16x4
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:39:24 +01:00
Ville Syrjälä
a12c4967c9 drm/i915: Change HSW WIZ hashing mode to 16x4
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:39:15 +01:00
Ville Syrjälä
a607c1a41d drm/i915: Change IVB WIZ hashing mode to 16x4
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:39:05 +01:00
Ville Syrjälä
743b57d830 drm/i915: There's no need to mask all 3D_CHICKEN bits on SNB
The need to set all of the mask bits for 3D_CHICKEN3 was required
only for pre-production hardware.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:37:11 +01:00
Ville Syrjälä
5eb146dd0b drm/i915: Assume we implement WaStripsFansDisableFastClipPerformanceFix:snb
Based on the name, the workaround we implement is
WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no
description in the w/a database, so this is just a guess.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:36:22 +01:00
Ville Syrjälä
8d85d27281 drm/i915: Fix SNB GT_MODE register setup
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register.
However later we go and disable all the bits in the same register. And
then we go on to set some other bit. So apparently we never actually
implemented this workaround since the "disable all bits" part was there
already before the w/a got supposedly implemented.

These are the relevant commits:

 commit 6547fbdbff
 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date:   Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch

 commit f8f2ac9a76
 Author: Ben Widawsky <ben@bwidawsk.net>
 Date:   Wed Oct 3 19:34:24 2012 -0700

    drm/i915: Fix GT_MODE default value

So, let's drop the "disable all bits" part, move both writes to
closer proxomity to each other, and name the WIZ hashing bits
appropriately. BSpec is still a bit confused how the bits should
actually be interpreted, but I took the the description for the
high bit since the low bit part only lists values for a single bit.

Also add a comment about our choice of WIZ hashing mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:35:52 +01:00
Paulo Zanoni
5bfa0199e9 drm/i915: get/put runtime PM without holding rps.hw_lock
We'll need this when we merge PC8 and Runtime PM: the PC8
enable/disable functions need that lock.

Also, it's good practice to not hold a lock for longer than strictly
needed.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:13:04 +01:00
Paulo Zanoni
da7235692c drm/i915: rename modeset_update_power_wells
To modeset_update_crtc_power_domains, since this function is
responsible for updating all the power domains of all CRTCs after a
modeset. In the future we should also run this function on all
platforms, not just Haswell.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 15:11:28 +01:00
Thierry Reding
d4d5be6192 drm/i915: Remove dead code
The i915 driver sets DRIVER_GEM unconditionally, so testing for the
feature will always fail.

Signed-off-by: Thierry Reding <treding@nvidia.com>
[danvet: Fix up conflicts.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-04 09:56:48 +01:00
Russell King
d13c46c67e DRM: armada: fix use of kfifo_put()
The kfifo_put() API changed in 498d319bb5 (kfifo API type safety)
which now results in the wrong pointer being added to the kfifo ring,
which then causes an oops.  Fix this.

Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-03-03 17:47:22 +00:00
Ville Syrjälä
6375b768a9 drm/i915: Reject >165MHz modes w/ DVI monitors
Single-link DVI max dotclock is 165MHz. Filter out modes with higher
dotclock when the monitor doesn't support HDMI.

Modes higher than 165 MHz were allowed in

commit 7d148ef51a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jul 22 18:02:39 2013 +0200

    drm/i915: fix hdmi portclock limits

Also don't attempt to use 12bpc mode with DVI monitors.

Cc: Adam Nielsen <a.nielsen@shikadi.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331
Tested-by: Ralf Jung <post+kernel@ralfj.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 19:08:08 +02:00
Paulo Zanoni
d9d820810d drm/i915: fix assert_cursor on BDW
We need to read the correct register, not a register that doesn't exist
and will trigger "Unclaimed register" messages when we touch it.

Also rearrange the checks in an attempt to prevent this error from
happening again.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: dropped an extra empty line introduced.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 19:07:40 +02:00
Imre Deak
17b0c1f786 drm/i915: vlv: reserve GT power context early
We reserve the space for the power context in stolen memory at a fixed
address from a delayed work. This races with the subsequent driver
init/resume code which could allocate something at that address, so the
reservation for the power context fails. Reserve the space up-front, so
this can't happen. This also adds a missing struct_mutex lock around the
stolen allocation, which wasn't taken in the delayed work path.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 19:06:40 +02:00
Imre Deak
bcdb72ac7c drm/i915: fix pch pci device enumeration
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
starting with the WARN below.

Regression introduced in

commit 6a9c4b35e6
Author: Rui Guo <firemeteor@users.sourceforge.net>
Date:   Wed Jun 19 21:10:23 2013 +0800

    drm/i915: Fix PCH detect with multiple ISA bridges in VM

[  164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110()
[  164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G           O 3.13.0-imre+ #354
[  164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013
[  164.368796] Call Trace:
[  164.371609]  [<ffffffff816a32a6>] dump_stack+0x4e/0x7a
[  164.377447]  [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0
[  164.384238]  [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20
[  164.390851]  [<ffffffff8169aeae>] klist_next+0xae/0x110
[  164.396777]  [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70
[  164.403286]  [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0
[  164.409719]  [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0
[  164.416238]  [<ffffffff8130a4e4>] pci_get_class+0x44/0x50
[  164.422433]  [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915]
[  164.429801]  [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915]
[  164.437831]  [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915]
[  164.445126]  [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110
[  164.452340]  [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm]
[  164.459462]  [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm]
[  164.466554]  [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[  164.474287]  [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915]
[  164.481185]  [<ffffffff8130a028>] pci_device_probe+0x78/0xf0
[  164.487603]  [<ffffffff813cd495>] driver_probe_device+0x155/0x350
[  164.494505]  [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0
[  164.500826]  [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50
[  164.507333]  [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0
[  164.513752]  [<ffffffff813ccefe>] driver_attach+0x1e/0x20
[  164.519870]  [<ffffffff813cc958>] bus_add_driver+0x138/0x260
[  164.526289]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
[  164.532116]  [<ffffffff813cde78>] driver_register+0x98/0xe0
[  164.538558]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
[  164.544389]  [<ffffffff813087b0>] __pci_register_driver+0x60/0x70
[  164.551336]  [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm]
[  164.558040]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
[  164.563928]  [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915]
[  164.570363]  [<ffffffff810002da>] do_one_initcall+0xaa/0x160
[  164.576783]  [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50
[  164.583100]  [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550
[  164.589410]  [<ffffffff810caab0>] ? store_uevent+0x40/0x40
[  164.595628]  [<ffffffff810cee7d>] SyS_init_module+0xed/0x100
[  164.602048]  [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b

v2: simplify the loop further (Chris)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 11:51:16 +02:00
Akash Goel
3617dc9675 drm/i915: Resolving the memory region conflict for Stolen area
There is a conflict seen when requesting the kernel to reserve
the physical space used for the stolen area. This is because
some BIOS are wrapping the stolen area in the root PCI bus, but have
an off-by-one error. As a workaround we retry the reservation with an
offset of 1 instead of 0.

v2: updated commit message & the comment in source file (Daniel)

Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 11:51:15 +02:00
Jani Nikula
b6ab66aa5d drm/i915: use backlight legacy combination mode also for i915gm/i945gm
i915gm and i945gm also seem to use and need the legacy combination mode
bit in BLC_PWM_CTL.

v2: Also do this for i915gm (Ville).

Reported-and-tested-by: Luis Ortega <luiorpe1@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-03 11:51:15 +02:00
Linus Torvalds
c59224d132 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
 "Not a huge amount happening, some MAINTAINERS updates, radeon, vmwgfx
  and tegra fixes"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/vmwgfx: avoid null pointer dereference at failure paths
  drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date.
  drm/vmwgfx: Remove some unused surface formats
  drm/radeon: enable speaker allocation setup on dce3.2
  drm/radeon: change audio enable logic
  drm/radeon: fix audio disable on dce6+
  drm/radeon: free uvd ring on unload
  drm/radeon: disable pll sharing for DP on DCE4.1
  drm/radeon: fix missing bo reservation
  drm/radeon: print the supported atpx function mask
  MAINTAINERS: update drm git tree entry
  MAINTAINERS: add entry for drm radeon driver
  drm/tegra: Add guard to avoid double disable/enable of RGB outputs
  gpu: host1x: do not check previously handled gathers
  drm/tegra: fix typo 'CONFIG_TEGRA_DRM_FBDEV'
2014-03-02 15:25:45 -08:00
Dave Airlie
d668ca1cc6 Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
more radeon fixes

* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: enable speaker allocation setup on dce3.2
  drm/radeon: change audio enable logic
  drm/radeon: fix audio disable on dce6+
  drm/radeon: free uvd ring on unload
  drm/radeon: disable pll sharing for DP on DCE4.1
  drm/radeon: fix missing bo reservation
  drm/radeon: print the supported atpx function mask
2014-03-03 09:04:41 +10:00
Daniel Vetter
b5ea642a76 drm/i915: sprinkle static
Apparently we've missed a few more than what Fengguang's 0-day tester
recently reported in i915_irq.c ... Makes sparse happy again (ignore
some spurious stuff about ksyms of exported functions).

Cc: kbuild test robot <fengguang.wu@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-02 21:19:51 +01:00
Alexey Khoroshilov
6950e23e54 drm/vmwgfx: avoid null pointer dereference at failure paths
vmw_takedown_otable_base() and vmw_mob_unbind() check for
potential vmw_fifo_reserve() failure and print error message,
but then immediately dereference NULL pointer.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
2014-03-02 09:49:59 +01:00
Thomas Hellstrom
a34417f6be drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date.
Backing mob contents is propagated to user-space, so make sure backing
mobs are cleared when allocated. This also accidently fix rendering errors
with celestia when emulating legacy mode.

Also update driver date.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
2014-03-02 09:43:40 +01:00
Thomas Hellstrom
ae2045694b drm/vmwgfx: Remove some unused surface formats
These formats are deprecated.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
2014-03-02 09:42:53 +01:00
Alex Deucher
3803c8e5b5 drm/radeon: enable speaker allocation setup on dce3.2
Now that we disable audio while setting up the audio
hw, we should be able to set this up without hangs.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2014-02-27 14:21:37 -05:00
Alex Deucher
832eafaf34 drm/radeon: change audio enable logic
Disable audio around audio hw setup.  This may avoid
hangs on certain asics.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2014-02-27 14:21:31 -05:00
Alex Deucher
d7eb0a0940 drm/radeon: fix audio disable on dce6+
Properly clear the enable bit when audio disable is requested.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
2014-02-27 14:13:06 -05:00
Jerome Glisse
d965441342 drm/radeon: free uvd ring on unload
Need to free the uvd ring. Also reshuffle gart tear down to
happen after uvd tear down.

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-02-27 14:10:35 -05:00
Alex Deucher
9ef4e1d000 drm/radeon: disable pll sharing for DP on DCE4.1
Causes display problems.  We had already disabled
sharing for non-DP displays.

Based on a patch from:
Niels Ole Salscheider <niels_ole@salscheider-online.de>

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58121

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2014-02-27 14:10:34 -05:00
Christian König
5e386b574c drm/radeon: fix missing bo reservation
Otherwise we might get a crash here.

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-02-27 14:05:28 -05:00
Alex Deucher
9f050c7f97 drm/radeon: print the supported atpx function mask
Print the supported functions mask in addition to
the version.  This is useful in debugging PX
problems since we can see what functions are available.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2014-02-27 14:05:27 -05:00