Cross Reference: /drivers/gpu/drm/i915/i915

History log of /drivers/gpu/drm/i915/i915_dma.c
Revision	Date	Author	Comments (<<< Hide modified files) (Show modified files >>>)
e90f3b61f4432e3c5bb6b57f4b3e8d8cba747541	30-Apr-2012	Chris Wilson <chris@chris-wilson.co.uk>	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> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
e02f14cd48a5da0ebaecf88c93dbd54a81e0dead	02-Apr-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: don't leak struct_mutex lock on ppgtt init failures Reported-by: Konstantin Belousov <kostikbel@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
650dc07ec3b0eba8ff21da706d2b1876ada59fc3	02-Apr-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: disable ppgtt on snb when dmar is enabled 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: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
ff5f4b0585620e5c158ecaad84d91c5bf3c5d0a1	23-Feb-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	Merge remote-tracking branch 'airlied/drm-next' into for-airlied Manually resolve the conflict between the new enum drm property helpers in drm-next and the new "force-dvi" option that the "audio" output property gained in drm-intel-next. While resolving this conflict, switch the new drm_prop_enum_list to use the newly introduced enum defines instead of magic values. Conflicts: drivers/gpu/drm/i915/intel_modes.c Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
466e69b8b03b8c1987367912782bc12988ad8794	19-Dec-2011	Dave Airlie <airlied@redhat.com>	drm: move pci bus master enable into driver. 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> /drivers/gpu/drm/i915/i915_dma.c
cdbe8b5426e71d09882212073c27c9dcf25a71b6	14-Feb-2012	Dave Airlie <airlied@redhat.com>	Merge tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next * tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits) drm/i915: Handle unmappable buffers during error state capture drm/i915: rewrite shmem_pread_slow to use copy_to_user drm/i915: rewrite shmem_pwrite_slow to use copy_from_user drm/i915: fall through pwrite_gtt_slow to the shmem slow path drm/i915: add debugfs file for swizzling information drm/i915: fix swizzle detection for gen3 drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain drm/i915: add per-ring fault reg to error_state drm/i915: reject GTT domain in relocations drm/i915: remove the i915_batchbuffer_info debugfs file drm/i915: capture error_state also for stuck rings drm/i915: refactor debugfs create functions drm/i915: refactor debugfs open function drm/i915: don't trash the gtt when running out of fences drm/i915: Separate fence pin counting from normal bind pin counting drm/i915/ringbuffer: kill snb blt workaround drm/i915: collect more per ring error state drm/i915: refactor ring error state capture to use arrays drm/i915: switch ring->id to be a real id drm/i915: set AUD_CONFIG N_value_index for DisplayPort ...
d3ae08109d628d26615d7f7f4d8d53cdd8d71fd0	26-Jan-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: fix up locking inconsistency around gem_do_init 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: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
9edd576d89a5b6d3e136d7dcab654d887c0d25b7	10-Feb-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	Merge remote-tracking branch 'airlied/drm-fixes' into drm-intel-next-queued Back-merge from drm-fixes into drm-intel-next to sort out two things: - interlaced support: -fixes contains a bugfix to correctly clear interlaced configuration bits in case the bios sets up an interlaced mode and we want to set up the progressive mode (current kernels don't support interlaced). The actual feature work to support interlaced depends upon (and conflicts with) this bugfix. - forcewake voodoo to workaround missed IRQ issues: -fixes only enabled this for ivybridge, but some recent bug reports indicate that we need this on Sandybridge, too. But in a slightly different flavour and with other fixes and reworks on top. Additionally there are some forcewake cleanup patches heading to -next that would conflict with currrent -fixes. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e21af88d39796c907c38648c824be3d646ffbe35	09-Feb-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: enable ppgtt 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: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
1d2a314c97ceaf383de8e23cdde46729927d433c	09-Feb-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: initialization/teardown for the aliasing ppgtt 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: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
f691e2f4cec334e906f971471b3bf1460c6256d4	02-Feb-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: swizzling support for snb/ivb 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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
198ceac091049003ffcc4b7cda76785510fc3b59	07-Feb-2012	Dave Airlie <airlied@redhat.com>	Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: add a LLC feature flag in device description drm/i915: kill i915_mem.c drm/i915: Use kcalloc instead of kzalloc to allocate array drm/i915/dp: Check for AUXCH error before checking for success drm/i915/dp: Use auxch precharge value of 5 everywhere drm/i915/dp: Tweak auxch clock divider for PCH drm/i915: Remove a comment about PCH from the non-PCH path drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) drm/i915: Implement plane-disabled assertion for PCH too drivers: i915: Fix BLC PWM register setup drm/i915: Check that plane/pipe is disabled before removing the fb drm/i915: fix typo in function name drm/i915: split out pll divider code drm/i915: split 9xx refclk & sdvo tv code out agp/intel: Add pci id for hostbridge from has/qemu drm/i915: there is no pipe CxSR on ironlake drm/i915: Only look for matching clocks for LVDS downclock drm/i915: Silence _DSM errors
b93f9cf14e714c20ce9a544ed1a6070ee7604588	26-Jan-2012	Ben Widawsky <ben@bwidawsk.net>	drm/i915: argument to control retiring behavior Sometimes it may be the case when we idle the gpu or wait on something we don't actually want to process the retiring list. This patch allows callers to choose the behavior. Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
9f1f46a45a681d357d1ceedecec3671a5ae957f4	14-Dec-2011	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: protect force_wake_(get\|put) with the gt_lock The problem this patch solves is that the forcewake accounting necessary for register reads is protected by dev->struct_mutex. But the hangcheck and error_capture code need to access registers without grabbing this mutex because we hold it while waiting for the gpu. So a new lock is required. Because currently the error_state capture is called from the error irq handler and the hangcheck code runs from a timer, it needs to be an irqsafe spinlock (note that the registers used by the irq handler (neglecting the error handling part) only uses registers that don't need the forcewake dance). We could tune this down to a normal spinlock when we rework the error_state capture and hangcheck code to run from a workqueue. But we don't have any read in a fastpath that needs forcewake, so I've decided to not care much about overhead. This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my snb on recent kernels - something must have slightly changed the timings. On previous kernels it only trigger a WARN about the broken locking. v2: Drop the previous patch for the register writes. v3: Improve the commit message per Chris Wilson's suggestions. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
3d29b842e58fbca2c13a9f458fddbaa535c6e578	17-Jan-2012	Eugeni Dodonov <eugeni.dodonov@intel.com>	drm/i915: add a LLC feature flag in device description LLC is not SNB/IVB-specific, so we should check for it in a more generic way. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
b2c606fe1defd1fb79612b48b528b2568c97def7	17-Jan-2012	Daniel Vetter <daniel.vetter@ffwll.ch>	drm/i915: kill i915_mem.c Some decent history digging indicates that this was to be used for the GLX_MESA_allocate_memory extension but never actually implemented for any released i915 userspace code. So just rip it out. v2: Fixup the Makefile. Acked-by: Dave Airlie <airlied@gmail.com> Cc: Keith Whitwell <keithw@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> /drivers/gpu/drm/i915/i915_dma.c
ae662d31264979e52581bd2573bf0b82812f52ab	03-Jan-2012	Eric Anholt <eric@anholt.net>	drm/i915: Add support for resetting the SO write pointers on gen7. These registers are automatically incremented by the hardware during transform feedback to track where the next streamed vertex output should go. Unlike the previous generation, which had a packet for setting the corresponding registers to a defined value, gen7 only has MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads an arbitrary register), so we need to do it from the kernel, and it needs to be settable atomically with the batchbuffer execution so that two clients doing transform feedback don't stomp on each others' state. Instead of building a more complicated interface involcing setting the registers to a specific value, just set them to 0 when asked and userland can tweak its pointers accordingly. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
8ea30864229e54b01ac0e9fe88c4b733a940ec4e	03-Jan-2012	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: add color key support v4 Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. v2: remove unnecessary mutex acquire/release around reg accesses v3: add support for full color key management v4: fix copy & paste bug in snb_get_colorkey don't bother checking min/max values against docs as the docs are likely wrong (how could we handle 10bpc surface formats?) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> /drivers/gpu/drm/i915/i915_dma.c
4ed0b577457eb6aeb7cdc7e7316576e63d15abb2	10-Nov-2011	Eugeni Dodonov <eugeni.dodonov@intel.com>	drm/i915: prevent division by zero when asking for chipset power This prevents an in-kernel division by zero which happens when we are asking for i915_chipset_val too quickly, or within a race condition between the power monitoring thread and userspace accesses via debugfs. The issue can be reproduced easily via the following command: while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done This is particularly dangerous because it can be triggered by a non-privileged user by just reading the debugfs entry. This issue was also found independently by Konstantin Belousov <kostikbel@gmail.com>, who proposed a similar patch. Reported-by: Konstantin Belousov <kostikbel@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
e0cd3608135b2ed8eddbe3fdf048d22e0593d836	30-Aug-2011	Paul Gortmaker <paul.gortmaker@windriver.com>	gpu: add module.h to drivers/gpu files as required. So that we don't get build failures once the implicit module.h presence is removed. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> /drivers/gpu/drm/i915/i915_dma.c
27f8227b1e2b326a9a0995dd9c1f14893c61ee01	02-Sep-2011	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: support 3 pipes on IVB+ Well almost anyway. IVB has 3 planes, pipes, transcoders, and FDI interfaces, but only 2 pipe PLLs. So two of the pipes must use the same pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode and one other, etc.). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
0206e353a0416ad63ce07f53c807c2c725633b87	16-Aug-2011	Akshay Joshi <me@akshayjoshi.com>	Drivers: i915: Fix all space related issues. Various issues involved with the space character were generating warnings in the checkpatch.pl file. This patch removes most of those warnings. Signed-off-by: Akshay Joshi <me@akshayjoshi.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
df7976797fa9af161690dbf4dee81ed92cdc150f	22-Jul-2011	Keith Packard <keithp@keithp.com>	Merge branch 'drm-intel-fixes' into drm-intel-next
f3234706a77bd6e1592ae71fb3268e04cb030dba	22-Jul-2011	Keith Packard <keithp@keithp.com>	drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring->status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard <keithp@keithp.com> Cc: stable@kernel.org /drivers/gpu/drm/i915/i915_dma.c
9aa73a51c91cb0d0af4caaa9823969c1a1179a12	12-Jul-2011	Keith Packard <keithp@keithp.com>	Merge branch 'drm-intel-fixes' into drm-intel-next
a7b85d2aa63ed09cd5a4a640772b3272f5ac7caa	10-Jul-2011	Keith Packard <keithp@keithp.com>	drm/i915: Clean up i915_driver_load failure path i915_driver_load adds a write-combining MTRR region for the GTT aperture to improve memory speeds through the aperture. If i915_driver_load fails after this, it would not have cleaned up the MTRR. This shouldn't cause any problems, except for consuming an MTRR register. Still, it's best to clean up completely in the failure path, which is easily done by calling mtrr_del if the mtrr was successfully allocated. i915_driver_load calls i915_gem_load which register i915_gem_inactive_shrink. If i915_driver_load fails after calling i915_gem_load, the shrinker will be left registered. When called, it will access freed memory and crash. The fix is to unregister the shrinker in the failure path using code duplicated from i915_driver_unload. i915_driver_load also has some incorrect gotos in the error cleanup paths: * After failing to initialize the GTT (which cannot happen, btw, intel_gtt_get returns a fixed (non-NULL) value), it tries to free the uninitialized WC IO mapping. Fixed this by changing the target from out_iomapfree to out_rmmap Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Lin Ming <ming.m.lin@intel.com> /drivers/gpu/drm/i915/i915_dma.c
43a9539fa9e780f16c0d1e4bc91a2701f1ce178f	08-Jul-2011	Chris Wilson <chris@chris-wilson.co.uk>	drm/i915: Only export the generic intel_disable_fbc() interface As the enable/disable routines will be gain additional complexity in future patches, it is necessary that all callers do not bypass the generic interface by calling into the chipset routines directly. to do this we make the chipset routines static, so there is no choice. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
f71d4af4cd475aced6d9ec9730b03885ac80b833	28-Jun-2011	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: move IRQ function table init to i915_irq.c This lets us make the various IRQ functions static and helps avoid problems like the one fixed in "drm/i915: Use chipset-specific irq installers" where one of the exported functions was called rather than the chipset specific version. This also fixes a UMS-mode bug -- the correct irq functions for IRL and later chips were only getting loaded in the KMS path. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
ecbec53b1d00ba582f71b210ed96cafc05ebd189	28-Jun-2011	Hugh Dickins <hughd@google.com>	drm/i915: more struct_mutex locking When auditing the locking in i915_gem.c (for a prospective change which I then abandoned), I noticed two places where struct_mutex is not held across GEM object manipulations that would usually require it. Since one is in initial setup and the other in driver unload, I'm guessing the mutex is not required for either; but post a patch in case it is. Signed-off-by: Hugh Dickins <hughd@google.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> /drivers/gpu/drm/i915/i915_dma.c
b1f14ad01ab09f5e22fb1240a6a158a23527ff14	06-Apr-2011	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: interrupt & vblank support for Ivy Bridge Add new interrupt handling functions for Ivy Bridge. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
f796cf8f517f13826bb691432b03c7b5da13e530	07-Apr-2011	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: split enable/disable vblank code into chipset specific functions This makes the Ironlake+ code trivial and generally simplifies things. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
4697995b98417c6da9ab2708a36f5e2bc926c8ac	07-Apr-2011	Jesse Barnes <jbarnes@virtuousgeek.org>	drm/i915: split irq handling into per-chipset functions Set the IRQ handling functions in driver load so they'll just be used directly, rather than branching over most of the code in the chipset functions. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
4912d04193733a825216b926ffd290fada88ab07	25-Apr-2011	Ben Widawsky <ben@bwidawsk.net>	drm/i915: move gen6 rps handling to workqueue The render P-state handling code requires reading from a GT register. This means that FORCEWAKE must be written to, a resource which is shared and should be protected by struct_mutex. Hence we can not manipulate that register from within the interrupt handling and so must delegate the task to a workqueue. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com> /drivers/gpu/drm/i915/i915_dma.c
2c7111dbaec72b01c804afb8ad77c6c7523986fd	29-Mar-2011	Chris Wilson <chris@chris-wilson.co.uk>	drm/i915: Disable all outputs early, before KMS takeover If the outputs are active and continuing to access the GATT when we teardown the PTEs, then there is a potential for us to hang the GPU. The hang tends to be a PGTBL_ER with either an invalid host access or an invalid display plane fetch. v2: Reorder IRQ initialisation to defer until after GEM is setup. Reported-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM) Tested-by: Pekka Enberg <penberg@kernel.org> # note that this doesn't fix the underlying problem of the PGTBL_ER and pipe underruns being reported immediately upon init on his 965GM MacBook Reported-and-tested-by: Rick Bramley <richard.bramley@hp.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35635 Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36048 Reviewed-by: Ben Widawsky <ben@bwidawsk.net> /drivers/gpu/drm/i915/i915_dma.c
96f298aa9c9fc9b7c8a2ebaf8c195d178f570e09	20-Mar-2011	Ben Widawsky <ben@bwidawsk.net>	drm/1915: ringbuffer wait for idle function Added a new function which waits for the ringbuffer space to be equal to (total - 8). This is the empty condition of the ringbuffer, and equivalent to head==tail. Also modified two users of this functionality elsewhere in the code. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> /drivers/gpu/drm/i915/i915_dma.c
e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316	21-Apr-2011	Dave Airlie <airlied@redhat.com>	drm/i915: restore only the mode of this driver on lastclose (v2) i915 calls the panic handler function on last close to reset the modes, however this is a really bad idea for multi-gpu machines, esp shareable gpus machines. So add a new entry point for the driver to just restore its own fbcon mode. v2: move code into fb helper, fix panic code to block mode change on powered off GPUs. [airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx so really I signed it off twice ;-).] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> /drivers/gpu/drm/i915/i915_dma.c
4cbf74ccf8362e99b2bdf1e66112a480c79ecacf	25-Feb-2011	Chris Wilson <chris@chris-wilson.co.uk>	drm/i915: don't store the reg value for HWS_PGA It is trivially computable from the real physical address so no need to store both. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> /drivers/gpu/drm/i915/i915_dma.c
8d3c3ddfa85837e24fad6fa39318617cbb59e843	02-Mar-2011	Chris Wilson <chris@chris-wilson.co.uk>	Merge branch 'drm-intel-fixes' into drm-intel-next
6927faf30920b8c03dfa007e732642a1f1f20089	01-Mar-2011	Jan Niehusmann <jan@gondor.com>	drm/i915: fix memory corruption with GM965 and >4GB RAM On a Thinkpad x61s, I noticed some memory corruption when plugging/unplugging the external VGA connection. The symptoms are that 4 bytes at the beginning of a page get overwritten by zeroes. The address of the corruption varies when rebooting the machine, but stays constant while it's running (so it's possible to repeatedly write some data and then corrupt it again by plugging the cable). Further investigation revealed that the corrupted address is (dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of the hardware status page of the i965 graphics card, cut to 32 bits. So it seems that for some memory access, the hardware uses only 32 bit addressing. If the hardware status page is located >4GB, this corrupts unrelated memory. Signed-off-by: Jan Niehusmann <jan@gondor.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org /drivers/gpu/drm/i915/i915_dma.c
271d81b84171d84723357ae6d172ec16b0d8139c	01-Mar-2011	Chris Wilson <chris@chris-wilson.co.uk>	drm/i915: Allow relocation deltas outside of target bo Userspace has a legitimate requirement to use a delta that points to outside of the target bo, and so we need to enable this. (As this is an abi break, albeit a relaxation of the current restrictions, mark the change with a new flag.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> /drivers/gpu/drm/i915/i915_dma.c