Chris Wilson [Thu, 26 Apr 2012 10:28:42 +0000 (11:28 +0100)]
drm/i915: Periodically sanity check power management
Every time we use the device after a period of idleness, check that the
power management setup is still sane. This is to workaround a bug
whereby it seems that we begin suppressing power management interrupts,
preventing SandyBridge+ from going into turbo mode.
This patch does have a side-effect. It removes the mark-busy for just
moving the cursor - we don't want to increase the render clock just for
the sprite, though we may want to bump the display frequency. I'd argue
that we do not, and certainly don't want to take the struct_mutex here
due to the large latencies that introduces.
References: https://bugs.freedesktop.org/show_bug.cgi?id=44006 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Thu, 3 May 2012 01:55:43 +0000 (22:55 -0300)]
drm/i915: enable dip before writing data on gen4
While testing with the intel_infoframes tool on gen4, I see that when
video DIP is disabled, what we write to the DATA memory is not exactly
what we read back later.
Paulo Zanoni [Fri, 13 Apr 2012 19:31:41 +0000 (16:31 -0300)]
drm/i915: make DBLCLK modes work
They require an AVI InfoFrame with a proper Pixel Repetition field.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 13 Apr 2012 19:31:40 +0000 (16:31 -0300)]
drm/i915: rename AVI InfoFrame field 'PR' to 'YQ_CN_PR'
To keep the consistency with the other fields.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 2 May 2012 19:43:56 +0000 (20:43 +0100)]
drm/i915: Wait for the clocks to stabilise before updating PLLs
When initialising the PLL registers we may have to clear existing state
from the BIOS - that is the PLL may already be enabled. So we need to
disable it, wait for the clocks to settle and then rewrite it.
and found that booting into a VGA monitor was no longer working. Closer
inspection suggests that it was a pre-existing bug now being hit by the
rearranged code. Perhaps Ben was not even the first person to stumble
upon this bug, https://bugs.freedesktop.org/show_bug.cgi?id=37029.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-Tested-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 2 May 2012 09:06:23 +0000 (11:06 +0200)]
drm/i915: rip out intel_dpio_write again
Unfortunately it looks like further vlv patches are still stalled due
to fried hw, and too many people are a bit annoyed about the unused
function warning.
So let's just rip it out, we can easily put it back in again.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:16 +0000 (23:28 +0200)]
drm/i915: fixup __iomem mixups in ringbuffer.c
Two things:
- ring->virtual start is an __iomem pointer, treat it accordingly.
- dev_priv->status_page.page_addr is now always a cpu addr, no pointer
casting needed for that.
Take the opportunity to remove the unnecessary drm indirection when
setting up the ringbuffer iomapping.
v2: Add a compiler barrier before reading the hw status page.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:15 +0000 (23:28 +0200)]
drm/i915: rework legacy GFX HWS handling
To get the fun stuff out of the way, the legacy hws is allocated by
userspace when the gpu needs a gfx hws. And there's no reference-counting
going on, so userspace can simply screw everyone over.
At least it's not as horrible as i810, where the ringbuffer is allocated
by userspace ...
We can't fix this disaster, but we can at least tidy up the code a
bit to make things clearer:
- Drop the drm ioremap indirection.
- Add a new new read_legacy_status_page to paper over the differences
between the legacy gfx hws and the physical hws shared with the
new ringbuffer code.
- Add a pointer in dev_priv->dri1 for the cpu addresses - that one is
an iomem remapping as opposed to all other hw status pages. This is
just prep work to make sparse happy.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:14 +0000 (23:28 +0200)]
drm/i915: kill pointless clearing of dev_priv->hws_map
We kzalloc dev_priv, and we never use hws_map in intel_ringbuffer.c.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:11 +0000 (23:28 +0200)]
drm/i915: disallow clip rects on gen5+
Unfortunately there has been dri1 userspace that used gem to manage
the gtt and hence also needed cliprects in the execbuf ioctl. So
we can't ever remove that code without breaking the ioctl abi.
But at least we can disable it on gen5+, because these horrible
versions of mesa have not supported these chips.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:10 +0000 (23:28 +0200)]
drm/i915: move LP_RING&friends to i915_dma.c
Wohoo!
Now we only need to move all the gem/kms stuff that accidentally
landed in i915_dma.c out of it, and this will be our legacy dri1
grave-yard.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:09 +0000 (23:28 +0200)]
drm/i915: extract dri1 breadcrumb update from irq handler
... and hide it in i915_dma.c.
This way all the legacy stuff dealing with READ_BREADCRUMB and
LP_RING and friends is in i915_dma.c.
v2: Rebase on top of Chris Wilson's rework irq handling code.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:08 +0000 (23:28 +0200)]
drm/i915: move dri1 irq ioctl code to i915_dma.c
Let's just get this out of the way.
v2: Rebase against ENODEV changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:07 +0000 (23:28 +0200)]
drm/i915: rip out dri1 breadcrumb updates from gen5+ irq handlers
We never supported dri1 on gen5+.
VLV never had that code, so no need to remove it.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:06 +0000 (23:28 +0200)]
drm/i915: kill intel_clear_scanline_wait
This is a pretty racy way to close these races, and we have
much better means to cope with these races meanwhile: For
non-broken userspace we correctly wait for any outstanding
rendering, for broken userspace the hangcheck will save the
day.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:05 +0000 (23:28 +0200)]
drm/i915: remove LP_RING&friends from modeset code
The LP refers to 'low priority' as opposed to the high priority
ring on gen2/3. So lets constrain its use to the code of that era.
Unfortunately we can't yet completely remove the associated
macros from common headers and shove them into i915_dma.c to
the other dri1 legacy support code, a few cleanups are still
missing for that.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:03 +0000 (23:28 +0200)]
drm/i915 disallow physical batchbuffers for KMS
Even the horrible gen3 XvMC code has learned to do this
right by the time xf86-video-intel releases learned to do
kernel modesetting. So we can just disallow this.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 26 Apr 2012 21:28:01 +0000 (23:28 +0200)]
drm/i915: move dri1 vblank stubs to i915_dma.c
i915_dma.c contains most of the old dri1 horror-show, so move
the remaining bits there, too. The code has been removed and
the only thing left are some stubs to ensure that userspace
doesn't try to use this stuff. vblank_pipe_set only returns 0
without any side-effects, so we can even stub it out with
the canonical drm_noop.
v2: Rebase against ENODEV changes.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 30 Apr 2012 18:17:35 +0000 (19:17 +0100)]
drm/i915: Remove unused dev_priv->vblank_pipe
vblank_pipe was intended to be used for tracking DRI1 state. However,
the vblank_pipe reported to DRI1 is fixed to umask both pipes, and the
dev_priv->vblank_pipe unused and superfluous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 30 Apr 2012 18:35:02 +0000 (19:35 +0100)]
drm/i915: Only enable IPS polling for gen5
On SandyBridge IPS was entirely implemented in hardware and not reliant
on the driver monitoring power consumption and feeding back desired run
states, so the hardware is able to adapt quicker and more flexibly. Which
is a huge relief for us as we no longer have to carry empirically
derived magic algorithms.
Yet despite the advance in technology, the driver was still doing its
IPS polling on all machines. Restrict it to the only supported hardware,
Clarkdale/Arrandale.
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>
Chris Wilson [Sat, 28 Apr 2012 08:00:03 +0000 (09:00 +0100)]
drm/i915: Remove unused ring->irq_seqno
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 26 Apr 2012 23:03:05 +0000 (16:03 -0700)]
drm/i915: use __wait_seqno for ring throttle
It turns out throttle had an almost identical bit of code to do the
wait. Now we can call the new helper directly. This is just a bonus,
and not needed for the overall series.
v2: remove irq_get/put which is now in __wait_seqno (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 26 Apr 2012 23:03:03 +0000 (16:03 -0700)]
drm/i915: extract __wait_seqno from i915_wait_request
i915_wait_request is actually a fairly large function encapsulating
quite a few different operations. Because being able to wait on seqnos
in various conditions is useful, extracting that bit of code to a helper
function seems useful
v2: pull the irq_get/put as well (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 26 Apr 2012 23:03:02 +0000 (16:03 -0700)]
drm/i915: drop polled waits from i915_wait_request
The only time irq_get should fail is during unload or suspend. Both of
these points should try to quiesce the GPU before disabling interrupts
and so the atomic polling should never occur.
This was recommended by Chris Wilson as a way of reducing added
complexity to the polled wait which I introduced in an RFC patch.
09:57 < ickle_> it's only there as a fudge for waiting after irqs
after uninstalled during s&r, we aren't actually meant to hit it
09:57 < ickle_> so maybe we should just kill the code there and fix the breakage
v2: return -ENODEV instead of -EBUSY when irq_get fails
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 26 Apr 2012 23:03:00 +0000 (16:03 -0700)]
drm/i915: move vbetool invoked ier stuff
This extra bit of interrupt enabling code doesn't belong in the wait
seqno function. If anything we should pull it out to a helper so the
throttle code can also use it. The history is a bit vague, but I am
going to attempt to just dump it, unless someone can argue otherwise.
Removing this allows for a shared lock free wait seqno function. To keep
tabs on this issue though, the IER value is stored on error capture
(recommended by Chris Wilson)
v2: fixed typo EIR->IER (Ben)
Fix some white space (Ben)
Move IER capture to globally instead of per ring (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: ier is a 16 bit reg on gen2!] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 26 Apr 2012 23:02:58 +0000 (16:02 -0700)]
drm/i915: remove do_retire from i915_wait_request
This originates from a hack by me to quickly fix a bug in an earlier
patch where we needed control over whether or not waiting on a seqno
actually did any retire list processing. Since the two operations aren't
clearly related, we should pull the parameter out of the wait function,
and make the caller responsible for retiring if the action is desired.
The only function call site which did not get an explicit retire_request call
(on purpose) is i915_gem_inactive_shrink(). That code was already calling
retire_request a second time.
v2: don't modify any behavior excepit i915_gem_inactive_shrink(Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 21:59:52 +0000 (22:59 +0100)]
drm/i915: Remove unused and unloved vblank macros
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:51 +0000 (22:59 +0100)]
drm/i915: Inline I915_INTERRUPT_ENABLE_FIX
Since there is only one remaining user of I915_INTERRUPT_ENABLE_FIX,
expand it at the callsite. Quoting Jesse Barnes:
"I'd really like to get rid of these defines at the top of i915_irq.c.
Some are unused and the others just make you check for the right bits
everytime your read the code."
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add bikeshed suggested by Jesse.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 21:59:50 +0000 (22:59 +0100)]
drm/i915: Handle PendingFlip on gen3 robustly
We appear to allow too many pending pageflips as evidenced by an
apparent pin-leak. So borrow the pageflip completion logic from i8xx for
handling PendingFlip in a robust manner.
v2: Address Jesse's reminders about the nuances of gen3 IRQ handling.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41882 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>
Chris Wilson [Tue, 24 Apr 2012 21:59:49 +0000 (22:59 +0100)]
drm/i915: Cleanup gen3 irq uninstall
Bring the for-each-pipe loops together so that the code is easier on the
eyes.
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:48 +0000 (22:59 +0100)]
drm/i915: HWSTAM is only 16-bit on gen3
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:47 +0000 (22:59 +0100)]
drm/i915: Remove gen4 irq code from gen3 irq routine
A couple of miscellaneous cleanups as well to move per-loop condition
variables within the scope of the loop and the update of the DRI1
breadcrumb to the tail of the function.
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:46 +0000 (22:59 +0100)]
drm/i915: Remove gen3 irq code from gen4 irq routine
And a couple of miscellaneous cleanups to the main body of the IRQ loop;
move per-loop condition variables within the scope of the loop and move
the old DRI1 breadcrumb to the tail of the function and so only execute
it once.
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:45 +0000 (22:59 +0100)]
drm/i915: Clear FlipDone semantics change for pageflipping on gen3
On later gen3, you are able to select the meaning of the FlipPending
status bit in IIR and change it to FlipDone. This was sometimes done by
the BIOS leading to confusion on just how pageflipping worked on gen3.
Simplify the implementation by using the legacy meaning for all gen3
machines.
Note: this makes all gen3 machines equally broken...
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:43 +0000 (22:59 +0100)]
drm/i915: pending_flip_is_done is gen3, name it so
And remove the cargo-culted copy from the valleyview irq handler.
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:42 +0000 (22:59 +0100)]
drm/i915: Remove redundant initialisation of per-ring IRQ waitqueues
The waitqueues are already initialised during ring initialisation so
kill the redundant and duplicated code to do so in each generations IRQ
installer.
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>
Chris Wilson [Tue, 24 Apr 2012 21:59:41 +0000 (22:59 +0100)]
drm/i915: Unconditionally initialise the interrupt workers
Rather than duplicate similar code across the IRQ installers, perform
the initialisation of the workers upfront. This will lead to simpler
teardown and quiescent code as we can assume that the workers have
been initialised.
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>
Daniel Vetter [Mon, 23 Apr 2012 14:50:50 +0000 (16:50 +0200)]
drm/i915: rip out GEM drm feature checks
We always set it so there's no point in checking. We could
instead add a bit that tells us whether gem is actually
initialized (i.e. either kms or gem_init_ioctl called), but
that's imho not worth it.
So just rip it out.
There's a little change in the wait_ring timeout, but we've never
run with anything else than the 60 second timeout, even on dri1
userspace.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 24 Apr 2012 07:55:08 +0000 (09:55 +0200)]
drm/i915: properly check for MODESET for kms driver ioctls
Also ditch the cargo-culted dev_priv checks - either we have a
giant hole in our setup code or this is useless. Plainly bogus
to check for it in either case.
v2: Chris Wilson noticed that I've missed one bogus dev_priv check.
v3: The check in the overlay code is redundant (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 13:51:43 +0000 (14:51 +0100)]
drm/i915: CR clock gating is recommend to be set on PineView
The specs recommend that this bit be set on PineView. No reason is
given, but it sounds like a powersaving bit that we should expect the
BIOS to be setting...
v2: Rebase on top of _MASKED_ENABLE_BIT
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 14:47:39 +0000 (15:47 +0100)]
drm/i915: Split the stolen handling for GEM out of i915_dma.c
We slightly modify the initialisation sequence to move the
initialisation of the memory managers earlier and in particular before
probing outputs and detecting any existing output configuration. This is
essential if we wish to track preallocated objects and preserve them
whilst initialising GEM.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 14:47:31 +0000 (15:47 +0100)]
drm/i915: Remove the deferred-free list
The use of the mm_list by deferred-free breaks the following patches to
extend the range of objects tracked. We can simplify things if we just
make the unbind during free uninterrutible.
Note that unbinding should never fail, because we hold an additional
reference on every active object. Only the ilk vt-d workaround breaks
this, but already takes care of not failing by waiting for the gpu to
quiescent non-interruptible. But the existence of the deferred free
list casted some doubts on this theory, hence WARN if the unbind fails
and only then retry non-interruptible.
We can kill this additional code after a release in case the theory is
indeed right and no one has hit that WARN.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 14:47:30 +0000 (15:47 +0100)]
drm/i915: Remove the list of pinned inactive objects
Simplify object tracking by removing the inactive but pinned list. The
only place where this was used is for counting the available memory,
which is just as easy performed by checking all objects on the rare
occasions it is required (application startup). For ease of debugging,
we keep the reporting of pinned objects through the error-state and
debugfs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 14:52:35 +0000 (15:52 +0100)]
drm/i915: Bump the inactive LRU on set-to-GTT-domain
Currently, we only bump the inactive LRU of an object when we bind
into the GTT for a page-fault. As the object may be used many times
before its mapping is zapped, we do not mark it as active as
frequently as we should. Userspace should be calling set-to-GTT-domain
before each pointer deference (for synchronous access) and so is a
good place to mark the buffer as active.
Marking the buffer as recently used places it at the end of the
inactive eviction queue, though still before anything with outstanding
rendering. This reduces the likelihood of evicting a buffer that is
going to be used again by the CPU in the near future. This way we can
hopefully avoid to kick out upload buffers right before we use them on
the gpu.
Note that we need to check that the object is not active or pinned,
for otherwise we create havoc on the active/pinned lists, which also
use obj->mm_list.
The active lists are sorted by and evicted in last GPU rendering
order, access by the CPU to a still active buffer therefore does not
affect its eviction ordering. Pinned objects are currently excluded
from eviction, therefore the only list that we need to bump for GTT
access by the CPU is the inactive list.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added further explanations to the commit message as discussed
on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 24 Apr 2012 15:36:50 +0000 (16:36 +0100)]
drm/i915: Remove too early plane enable on pre-PCH hardware
Enabling the plane before we have assigned valid address means that it
will access random PTE (often with conflicting memory types) and cause
GPU lockups. However, enabling the plane too early appears to workaround
a number of bugs in our modesetting code.
Cc: Franz Melchior <melchior.franz@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=39947
References: https://bugs.freedesktop.org/show_bug.cgi?id=41091
References: https://bugs.freedesktop.org/show_bug.cgi?id=49041 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 24 Apr 2012 12:04:12 +0000 (14:04 +0200)]
drm/i915: create macros to handle masked bits
... and put them to so good use.
Note that there's functional change in vlv clock gating code, we now
no longer spuriously read back the current value of the bit. According
to Bspec the high bits should always read zero, so ORing this in
should have no effect.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll field to dev_priv (Daniel)
don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
put register offsets in pll struct (Chris)
v3: Decouple enable/disable of PLLs from get/put.
v4: Track temporary PLL disabling during modeset
v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni)
v6: Avoid mishandling allocation failure by embedding the small array of
PLLs into the device struct
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+) Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 22 Apr 2012 20:13:57 +0000 (21:13 +0100)]
drm/i915: i8xx interrupt handler
gen2 hardware has some significant differences from the other interrupt
routines that were glossed over and then forgotten about in the
transition to KMS. Such as
- 16bit IIR
- PendingFlip status bit
This patch reintroduces a handler specifically for gen2 for the purpose
of handling pageflips correctly, simplifying code in the process.
v2: Also fixup ring get/put irq to only access 16bit registers (Daniel)
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24202
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41793 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: use posting_read16 in intel_ringbuffer.c and kill _driver
from the function names.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 21 Apr 2012 15:23:24 +0000 (16:23 +0100)]
drm/i915: Only the zap the VMA after updating the tiling parameters
If we fail to unbind and so abort the change in tiling, we will have
removed the VMA for the object for no reason. The likelihood of unbind
failing is slim (other than ERESTARTSYS which will cause userspace to
try again), so the change is mostly for the principle.
Also improve the slightly stale comment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 21 Apr 2012 15:23:23 +0000 (16:23 +0100)]
drm/i915: Clarify the semantics of tiling_changed
Rename obj->tiling_changed to obj->fence_dirty so that it is clear that
it flags when the parameters for an active fence (including the
no-fence) register are changed.
Also, do not set this flag when the object does not have a fence
register allocated currently and the gpu does not depend upon the
unfence. This case works exactly like when a tiled object lost its
fence and hence does not need additional handling for the tiling
change in the code.
v2: Use fence_dirty to better express what the flag tracks and add a few
more details to the comments to serve as a reminder of how the GPU also
uses the unfenced register slot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add some bikeshed to the commit message about the stricter
use of fence_dirty.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 20 Apr 2012 19:25:04 +0000 (21:25 +0200)]
drm/i915: fixup tv load-detect on enabled but not active crtc
When fixing up the crt load detect code I've failed to notice the same
problem in the tv load detect code. Again, unconditionally use the
load detect pipe infrastructure, it gets things right.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Mon, 16 Apr 2012 21:07:47 +0000 (14:07 -0700)]
drm/i915: [sparse] __iomem fixes for gem
As with one of the earlier patches in the series, we're forced to cast
for copy_[to|from]_user. Again because of the nature of the GEN x86
exclusivity, this should be safe.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: Added some bikeshed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 21 Apr 2012 20:49:10 +0000 (22:49 +0200)]
drm/i915: [sparse] __iomem fixes for debugfs
These were mostly straight forward. No forced casting needed.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: fix conflict with ringbuffer_data removal and drop the hunk
about the status page - that needs more care to fix up.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Mon, 16 Apr 2012 21:07:43 +0000 (14:07 -0700)]
drm/i915: [sparse] __iomem fixes for overlay
With the exception of a forced cast for phys_obj stuff (a problem in
other patches as well) all of these are fairly simple __iomem compliance
fixes.
As with other patches, yank/paste errors may exist.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: Added comment to explain the __iomem cast.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 19 Apr 2012 16:55:23 +0000 (17:55 +0100)]
drm/i915: Remove i915_gem_ringbuffer_(data|info) from debugfs
This was originally used as an attempt to diagnose GPU hangs, but was
never very reliable and superseded by the i915_error_state capture on
hangcheck. It now lies languishing unused and unwanted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 18 Apr 2012 16:12:26 +0000 (17:12 +0100)]
drm/i915/sprite: Avoid incurring extra vblank stall when updating plane on IVB
IvyBridge requires an extra frame between disabling the low power
watermarks and enabling scaling on the sprite plane. If the scaling
is already enabled, then we have already disabled the low power
watermarks and need not incur an extra wait.
Similarly, as we disable the scaling when turning off the sprite plane,
we can update the scaling enabled flag and restore the low power
watermarks.
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>
Michel Dänzer [Wed, 2 May 2012 08:29:56 +0000 (10:29 +0200)]
drm/radeon: Original Radeons had PCI GART, not PCIe GART.
Just a cosmetic fix to make dmesg a little less confusing.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:25 +0000 (15:11 +0200)]
drm/radeon: remove cayman_gpu_is_lockup
Since it is now identical to evergreen_gpu_is_lockup.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:24 +0000 (15:11 +0200)]
drm/radeon: remove r300_gpu_is_lockup
Since it is now identical to r100_gpu_is_lockup.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:23 +0000 (15:11 +0200)]
drm/radeon: make forcing ring activity a common function
Nothing chipset or ring specific with it,
so also move it to radon_ring.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:22 +0000 (15:11 +0200)]
drm/radeon: unlock the ring mutex while waiting for the next fence
Fixing just another deadlock problem with gpu reset tests.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:21 +0000 (15:11 +0200)]
drm/radeon: make lockup timeout a module param
Don't hard code the 10 seconds timeout. Compute jobs
can run much longer.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:20 +0000 (15:11 +0200)]
drm/radeon: move lockup detection code into radeon_ring.c
It isn't chipset specific, so it makes no sense
to have that inside r100.c.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:19 +0000 (15:11 +0200)]
drm/radeon: rework recursive gpu reset handling
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.
v2: Split removal of radeon_mutex into separate patch.
Return -EAGAIN if reset is successful.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:18 +0000 (15:11 +0200)]
drm/radeon: fix a bug with the ring syncing code
Rings need to lock in order, otherwise
the ring subsystem can deadlock.
v2: fix error handling and number of locked doublewords.
v3: stop creating unneeded semaphores.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:17 +0000 (15:11 +0200)]
drm/radeon: don't keep list of created fences.
It's never used and so practically superfluous.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:16 +0000 (15:11 +0200)]
drm/radeon: rename fence_wait_last to fence_wait_empty
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:15 +0000 (15:11 +0200)]
drm/radeon: return -ENOENT in fence_wait_next v2
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:14 +0000 (15:11 +0200)]
drm/radeon: fix a bug in the SA code
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:13 +0000 (15:11 +0200)]
drm/radeon: rework gpu lockup detection and processing
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:12 +0000 (15:11 +0200)]
drm/radeon: use central function for IB testing
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:11 +0000 (15:11 +0200)]
drm/radeon: register ring debugfs handlers on init
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:10 +0000 (15:11 +0200)]
drm/radeon: replace gpu_lockup with ring->ready flag
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König [Wed, 2 May 2012 13:11:09 +0000 (15:11 +0200)]
drm/radeon: make radeon_gpu_is_lockup a per ring function
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit
bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5).
gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting
gp->wake_on_lan to bool. Tested on an iBook G4.
Signed-off-by: Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / karo-tx-linux.git / log