- 03 May, 2012 40 commits
-
-
Daniel Vetter authored
Because this is the place where we actually use the results of them. Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
We kzalloc dev_priv, and we never use hws_map in intel_ringbuffer.c. Reviewed-by:
-
Daniel Vetter authored
They're now in intel_pm.c, so group them a bit better. Acked-by:
-
Daniel Vetter authored
We now have a nice home for power management code, so let's use it! v2: Resolve conflict agains "Only enable IPS polling for gen5" Acked-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
... 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:
-
Daniel Vetter authored
Let's just get this out of the way. v2: Rebase against ENODEV changes. Reviewed-by:
-
Daniel Vetter authored
We never supported dri1 on gen5+. VLV never had that code, so no need to remove it. Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
Assigned in setparam, used never. I didn't bother to dig through the archives to figure out what this was supposed to do. Acked-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
... and shove allow_batchbuffer in there. More dragons will follow suit. There's the curious case that we allow this for KMS ... Acked-by:
-
Daniel Vetter authored
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:
-
Chris Wilson authored
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 authored
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 authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-Off-by:
-
Ben Widawsky authored
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 authored
It's about to go away anyway. Just here to help bisection. Signed-off-by:
-
Ben Widawsky authored
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 authored
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 authored
The waiting_seqno is not terribly useful, and as such we can remove it so that we'll be able to extract lockless code. v2: Keep the information for error_state (Chris) Check if ring is initialized in hangcheck (Chris) Capture the waiting ring (Chris) Signed-off-by:
-
Ben Widawsky authored
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 authored
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:
-
Daniel Vetter authored
I've missed this one. v2: Chris Wilson noticed another register. v3: Color choice improvements. Reviewed-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
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 authored
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=41882Signed-off-by:
-
Chris Wilson authored
Bring the for-each-pipe loops together so that the code is easier on the eyes. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
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 authored
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 authored
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 authored
In preparation for rewriting the gen3 irq handler. Signed-off-by:
-
Chris Wilson authored
And remove the cargo-culted copy from the valleyview irq handler. Signed-off-by:
-
Chris Wilson authored
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 authored
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:
-
