- 06 Jun, 2012 1 commit
-
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 May, 2012 1 commit
-
-
Ben Widawsky authored
This helps implement GL_ARB_sync but stops short of allowing full blown sync objects. Finally we can use the new timed seqno waiting function to allow userspace to wait on a buffer object with a timeout. This implements that interface. The IOCTL will take as input a buffer object handle, and a timeout in nanoseconds (flags is currently optional but will likely be used for permutations of flush operations). Users may specify 0 nanoseconds to instantly check. The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any non-zero timeout parameter the wait ioctl will wait for the given number of nanoseconds on an object becoming unbusy. Since the wait itself does so holding struct_mutex the object may become re-busied before this completes. A similar but shorter race condition exists in the busy ioctl. v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris) Flush the object from the gpu write domain (Chris + Daniel) Fix leaked refcount in good case (Chris) Naturally align ioctl struct (Chris) v3: Drop lock after getting seqno to avoid ugly dance (Chris) v4: check for 0 timeout after olr check to allow polling (Chris) v5: Updated the comment. (Chris) v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel) Fix the commit message comment to be less ugly (Ben) Add a warning to check the return timespec (Ben) v7: Use DRM_AUTH for the ioctl. (Eugeni) Signed-off-by:
-
- 19 May, 2012 1 commit
-
-
Chris Wilson authored
When userspace asks whether the driver supports the BLT or BSD rings for this chip, simply report whether those particular rings are initialised v2: Use intel_ring_initialized() Signed-off-by:
-
- 13 May, 2012 1 commit
-
-
Takashi Iwai authored
This changes the API as a clean-up. Instead of passing multiple function pointers at each time, introduce a new struct holding the whole callback functions and pass it to the registration. The same struct will be used for the upcoming audio client registration, too. Signed-off-by:Takashi Iwai <tiwai@suse.de>
-
- 03 May, 2012 17 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 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:
-
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 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
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
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
... 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
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:
-
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:
-
Chris Wilson authored
And remove the cargo-culted copy from the valleyview irq handler. Signed-off-by:
-
Daniel Vetter authored
Calling these when gem assumes full control of the hw won't end in anything else than tears. So be a bit more paranoid here. Just serves as documentation. v2: Bail out with ENODEV as suggested by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
Always true these days. It has been added originally to work around some issues with the agp layer in 2.6.29: commit ac5c4e76 Author: Dave Airlie <airlied@redhat.com> Date: Fri Dec 19 15:38:34 2008 +1000 drm/i915: GEM on PAE has problems - disable it for now. Reviewed-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
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:
-
- 02 May, 2012 1 commit
-
-
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:
Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by:
-
- 17 Apr, 2012 1 commit
-
-
Eugeni Dodonov authored
They work differently, but the count is the same. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
- 12 Apr, 2012 1 commit
-
-
Ben Widawsky authored
Merge rc6 information into the power group for our device. Until now the i915 driver has not had any sysfs entries (aside from the connector stuff enabled by drm core). Since it seems like we're likely to have more in the future I created a new file for sysfs stubs, as well as the rc6 sysfs functions which don't really belong elsewhere (perhaps i915_suspend, but most of the stuff is in intel_display,c). displays rc6 modes enabled (as a hex mask): cat /sys/class/drm/card0/power/rc6_enable displays #ms GPU has been in rc6 since boot: cat /sys/class/drm/card0/power/rc6_residency_ms displays #ms GPU has been in deep rc6 since boot: cat /sys/class/drm/card0/power/rc6p_residency_ms displays #ms GPU has been in deepest rc6 since boot: cat /sys/class/drm/card0/power/rc6pp_residency_ms Important note: I've seen on SNB that even when RC6 is *not* enabled the rc6 register seems to have a random value in it. I can only guess at the reason reason for this. Those writing tools that utilize this value need to be careful and probably want to scrutinize the value very carefully. v2: use common rc6 residency units to milliseconds for the other RC6 types v3: don't create sysfs files for GEN <= 5 add a rc6_enable to show a mask of enabled rc6 types use unmerge instead of remove for sysfs group squash intel_enable_rc6() extraction into this patch v4: rename sysfs files (Chris) CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch>f CC: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
- 09 Apr, 2012 1 commit
-
-
Daniel Vetter authored
Spurred by an irc discussion, let's start to clear up which parts of our kms + ums/gem + ums/dri1 + vbios/dri1 kernel driver pieces userspace in the wild actually uses. The idea is that we introduce checks at entry-points (module load time, ioctls, ...) first and then reap any obviously dead code in a second step. As a first step refuse to load without kms on chips where userspace never supported ums. Now upstream hasn't supported ums on ilk, ever. But RHEL had the great idea to backport the kms support to their ums driver. Cc: Dave Airlie <airlied@gmail.com> Signed-Off-by:
-
- 03 Apr, 2012 1 commit
-
-
Daniel Vetter authored
Reported-by:
Konstantin Belousov <kostikbel@gmail.com> Reviewed-by:
-
- 02 Apr, 2012 1 commit
-
-
Daniel Vetter authored
Totally unexpected that this regressed. Luckily it sounds like we just need to have dmar disable on the igfx, not the entire system. At least that's what a few days of testing between Tony Vroon and me indicates. Reported-by:
Tony Vroon <tony@linx.net> Cc: Tony Vroon <tony@linx.net> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024 Acked-by:
-
- 28 Mar, 2012 1 commit
-
-
Chris Wilson authored
Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT is enabled) where we left the MTRR as 0 and so tried to free a MTRR we did not own during unload. Reported-and-tested-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
- 27 Mar, 2012 3 commits
-
-
Daniel Vetter authored
We've lost our guard page somewhere in the gtt rewrite, this patch here will restore it. Exercised by i-g-t/tests/gem_cs_prefetch. v2: Substract the guard page from the range we're supposed to manage with gem. Suggested by Chris Wilson to increase the odds of old ums + gem userspace not blowing up. To compensate for the loss of a page, don't substract the guard page in the modeset init code any longer. Tested-by:
-
Daniel Vetter authored
So don't call it like that. Also rip out a confusing comment and instead explain what's really going on. Reviewed-by:
-
Daniel Vetter authored
... because this is what it actually doesn now that we have the global gtt vs. ppgtt split. Also move it to the other global gtt functions in i915_gem_gtt.c Signed-Off-by:
-
- 20 Mar, 2012 1 commit
-
-
Daniel Vetter authored
On Sanybridge a few MI read/write commands only work when ppgtt is enabled. Userspace therefore needs to be able to check whether ppgtt is enabled. For added hilarity, you need to reset the "use global GTT" bit on snb when ppgtt is enabled, otherwise it won't work. Despite what bspec says about automatically using ppgtt ... Luckily PIPE_CONTROL (the only write cmd current userspace uses) is not affected by all this, as tested by tests/gem_pipe_control_store_loop. Reviewed-and-tested-by:
-
- 18 Mar, 2012 3 commits
-
-
Joe Perches authored
Use a more current logging style. Ensure that appropriate logging messages are prefixed with "i915: ". Convert printks to pr_<level>. Align arguments. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Adam Jackson authored
Some newer BIOSes are shipping with all MTRRs already populated. These BIOSes are all on machines with sufficiently new CPUs that the referenced errata doesn't apply anyway, so just don't try to claim the MTRR. Signed-off-by:
-
Adam Jackson authored
No functional change here, just clarifying code flow. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
- 16 Feb, 2012 1 commit
-
-
Dave Airlie authored
The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback mechanism can cause these sorts of issues. This patch doesn't fix the problem, but it moves the bus master enable under the individual drivers control so they can move enabling it until later in their load cycle and close the race. Fix for radeon kms driver will be in a follow-up patch. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
- 13 Feb, 2012 1 commit
-
-
Daniel Vetter authored
The locking in our setup and teardown paths is rather arbitrary, but generally we try to protect gem stuff with dev->struct_mutex. Further, the ums/gem ioctl to setup gem _does_ take the look. So fix up this benign inconsistency. Notice while reading through code. v2: Rebased on top of the ppgtt code. Reviewed-by:
-
- 09 Feb, 2012 2 commits
-
-
Daniel Vetter authored
We want to unconditionally enable ppgtt for two reasons: - Windows uses this on snb and later. - We need the basic hw support to work before we can think about real per-process address spaces and other cool features we want. But Chris Wilson was complaining all over irc and intel-gfx that this will blow up if we don't have a module option to disable it. Hence add one, to prevent this. ppgtt support seems to slightly change the timings and make crashy things slightly more or less crashy. Now in my testing and the testing this got on troublesome snb machines, it seems to have improved things only. But on ivb it makes quite a few crashes happen much more often, see https://bugs.freedesktop.org/show_bug.cgi?id=41353 Luckily Eugeni Dodonov seems to have a set of workarounds that fix this issue. v2: Don't try to enable ppgtt on pre-snb. v3: Pimp commit message and make Chris Wilson less grumpy by adding a module option. v4: New try at making Chris Wilson happy. Reviewed-by:
-
Daniel Vetter authored
This just adds the setup and teardown code for the ppgtt PDE and the last-level pagetables, which are fixed for the entire lifetime, at least for the moment. v2: Kill the stray debug printk noted by and improve the pte definitions as suggested by Chris Wilson. v3: Clean up the aperture stealing code as noted by Ben Widawsky. v4: Paint the init code in a more pleasing colour as suggest by Chris Wilson. v5: Explain the magic numbers noticed by Ben Widawsky. Reviewed-by:
-
- 08 Feb, 2012 1 commit
-
-
Daniel Vetter authored
We have to do this manually. Somebody had a Great Idea. I've measured speed-ups just a few percent above the noise level (below 5% for the best case), but no slowdows. Chris Wilson measured quite a bit more (10-20% above the usual snb variance) on a more recent and better tuned version of sna, but also recorded a few slow-downs on benchmarks know for uglier amounts of snb-induced variance. v2: Incorporate Ben Widawsky's preliminary review comments and elaborate a bit about the performance impact in the changelog. v3: Add a comment as to why we don't need to check the 3rd memory channel. v4: Fixup whitespace. Acked-by:
Eric Anholt <eric@anholt.net> Signed-Off-by:
-
