aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAge
* drm/i915/lvds: Only act on lid notify when the device is onAlex Williamson2011-05-09
| | | | | | | | | | | | | | If we're using vga switcheroo, the device may be turned off and poking it can return random state. This provokes an OOPS fixed separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a DP before it is attached). Trying to use and respond to events on a device that has been turned off by the user is in principle a silly thing to do. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"Chris Wilson2011-05-09
| | | | | | | | | | | | | | | Despite the fixes in 548f245ba6a31 (drm/i915: fix per-pipe reads after "cleanup"), we missed one neighbouring read that was mistakenly replaced with the reg value in 9db4a9c (drm/i915: cleanup per-pipe reg usage). This was preventing us from correctly determining the mode the BIOS left the panel in for machines that neither have an OpRegion nor access to the VBT, (e.g. the EeePC 700). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Only enable the plane after setting the fb base (pre-ILK)Chris Wilson2011-05-09
| | | | | | | | | | | | | | | When enabling the plane, it is helpful to have already pointed that plane to valid memory or else we may incur the wrath of a PGTBL_ER. This code preserved the behaviour from the bad old days for unknown reasons... Found by assert_fb_bound_for_plane(). References: https://bugs.freedesktop.org/show_bug.cgi?id=36246 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915/dp: Be paranoid in case we disable a DP before it is attachedChris Wilson2011-05-04
| | | | | | | | | | | | | | | | Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456 Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Release object along create user fb error pathChris Wilson2011-05-04
| | | | | | | Reported-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: restore only the mode of this driver on lastclose (v2)Dave Airlie2011-04-27
| | | | | | | | | | | | | | | 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>
* Merge branch 'drm-intel-fixes' of ↵Linus Torvalds2011-04-21
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: drm/i915: Initialise g4x watermarks for disabled pipes drm/i915: Sanitize the output registers after resume drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3 drm/i915/tv: Only poll for TV connections drm/i915/tv: Remember the detected TV type
| * drm/i915: Initialise g4x watermarks for disabled pipesChris Wilson2011-04-13
| | | | | | | | | | | | | | | | | | | | | | We were using uninitialised watermarks values for disabled pipes which were combined into a single WM register and so corrupting the values for the enabled pipe and upsetting the display hardware. Reported-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Sanitize the output registers after resumeChris Wilson2011-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to booting, we need to inspect the state left by the BIOS and remove any conflicting bits before we take over. The example reported by Seth Forshee is very similar to the bug we encountered with the state left by grub2, that the crtc pipe<->planning mapping was reversed from our expectations and so we failed to turn off the outputs when booting or, in this case, resuming. This may be in fact the same bug, but triggered at resume time. This patch rearranges the code we already have to clear up the conflicting state upon init and calls it from reset (which is called after we have lost control of the hardware, i.e. along both the boot and resume paths) instead. Reported-and-tested-by: Seth Forshee <seth.forshee@canonical.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3Sitsofe Wheeler2011-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tidy ups in 7f58aabc369014fda3a4a33604ba0a1b63b941ac ("drm/i915: cleanup per-pipe reg usage") changed intel_crtc->plane to intel_crtc->pipe in intel_tv_mode_set(). This caused the screen to quickly turn off before returning whenever modesetting/mode probing took place on my 915GM EeePC 900 creating a flickering effect. This patch changes intel_crtc->pipe back to intel_crtc->plane which solves the problem for me. References: https://bugs.freedesktop.org/show_bug.cgi?id=35903 Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Humbly-acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/tv: Only poll for TV connectionsMathew McKernan2011-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | As a probe for a TV connection modifies the TV_CTL register, it causes a loss of sync and a regular glitch on the output. This is highly undesirable when using the TV, so only poll for TV connections and wait for an explicit query for detecting the disconnection event. Reported-by: Mathew McKernan <matmckernan@rauland.com.au> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977 Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/tv: Remember the detected TV typeMathew McKernan2011-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During detect() we would probe the connection bits to determine if there was a TV attached, and what video input type (Component, S-Video, Composite, etc) to use. However, we promptly discarded this vital bit of information and never propagated it to where it was used to determine the correct modes and setup the control registers. Fix it! This fixes a regression from 7b334fcb45b757ffb093696ca3de1b0c8b4a33f1. Reported-and-tested-by: Mathew McKernan <matmckernan@rauland.com.au> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977 Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Acked-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* | Merge branch 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6Linus Torvalds2011-04-07
|\ \ | |/ |/| | | | | * 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6: Fix common misspellings
| * Fix common misspellingsLucas De Marchi2011-03-31
| | | | | | | | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
* | drm/i915/lvds: Remove 0xa0 DDC probe for LVDSChris Wilson2011-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a revert of 428d2e828c0a68206e5158a42451487601dc9194. This is broken in the same manner as for VGA: trying to write to an invalid address on the (currently 7-bit) i2c bus. One notable failure appears to be for MacBooks. The scary part was that it gave the appearance of working (i.e. reporting the absence of the panel) on various all-in-one machines with ghost LVDS panels and not failing for laptops. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915/crt: Remove 0xa0 probe for VGAChris Wilson2011-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a moral revert of 6ec3d0c0e9c0c605696e91048eebaca7b0c36695. Following the fix to reset the GMBUS controller after a NAK, we finally utilize the 0xa0 probe for a CRT connection. And discover that the code is broken. Shock. There are a number of issues, but following a key insight from Dave Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we were to enable 10-bit addressing), and would look like the EDID port 0x50, it is possible to see where the confusion starts. In short, a write to 0xA0 is accepted by the GMBUS controller which we interpreted as meaning the existence of a connection (a slave on the other end of the wire ACKing the write). That was false. During testing with a broken GMBUS implementation, which never reset an earlier NAK, this test always reported a NAK and so we proceeded on to the next test. Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904 Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Reset GMBUS controller after NAKChris Wilson2011-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once a NAK has been asserted by the slave, we need to reset the GMBUS controller in order to continue. This is done by asserting the Software Clear Interrupt bit and then clearing it again to restore operations. If we don't clear the NAK, then all future GMBUS xfers will fail, including DDC probes and EDID retrieval. v2: Add some comments as suggested by Keith Packard. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: "Mengmeng Meng" <mengmeng.meng@intel.com>
* | drm/i915: Busy-spin wait_for condition in atomic contextsChris Wilson2011-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | During modesetting, we need to wait for the hardware to report readiness by polling the registers. Normally, we call msleep() between reads, because some state changes may take a whole vblank or more to complete. However during a panic, we are in an atomic context and cannot sleep. Instead, busy spin polling the termination condition. References: https://bugzilla.kernel.org/show_bug.cgi?id=31772 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | drm/i915/lvds: Always return connected in the absence of better informationChris Wilson2011-03-24
|/ | | | | | | | | | | | | The LVDS connector should default to connected. We tried our best to verify the claims of the BIOS that the hardware exists during init(), and then during detect() we then try to verify that the panel is open. In the event of an unsuccessful query, we should then always report that the LVDS panel is connected. This was only the case for gen2/3, later generations leaked the return value from the panel probe instead. Reported-and-tested-by: Alessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* Revert "drm/i915: Don't save/restore hardware status page address register"Chris Wilson2011-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718. There are two different variations on how Intel hardware addresses the "Hardware Status Page". One as a location in physical memory and the other as an offset into the virtual memory of the GPU, used in more recent chipsets. (The HWS itself is a cacheable region of memory which the GPU can write to without requiring CPU synchronisation, used for updating various details of hardware state, such as the position of the GPU head in the ringbuffer, the last breadcrumb seqno, etc). These two types of addresses were updated in different locations of code - one inline with the ringbuffer initialisation, and the other during device initialisation. (The HWS page is logically associated with the rings, and there is one HWS page per ring.) During resume, only the ringbuffers were being re-initialised along with the virtual HWS page, leaving the older physical address HWS untouched. This then caused a hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried to synchronise the GPU as the breadcrumbs were never being updated. Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Jan Niehusmann <jan@gondor.com> Reported-and-tested-by: Justin P. Mattock <justinmattock@gmail.com> Reported-and-tested-by: Michael "brot" Groh <brot@minad.de> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915: Avoid unmapping pages from a NULL address spaceChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found by gem_stress. As we perform retirement from a workqueue, it is possible for us to free and unbind objects after the last close on the device, and so after the address space has been torn down and reset to NULL: BUG: unable to handle kernel NULL pointer dereference at 00000054 IP: [<c1295a20>] mutex_lock+0xf/0x27 *pde = 00000000 Oops: 0002 [#1] SMP last sysfs file: /sys/module/vt/parameters/default_utf8 Pid: 5, comm: kworker/u:0 Not tainted 2.6.38+ #214 EIP: 0060:[<c1295a20>] EFLAGS: 00010206 CPU: 1 EIP is at mutex_lock+0xf/0x27 EAX: 00000054 EBX: 00000054 ECX: 00000000 EDX: 00012fff ESI: 00000028 EDI: 00000000 EBP: f706fe20 ESP: f706fe18 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process kworker/u:0 (pid: 5, ti=f706e000 task=f7060d00 task.ti=f706e000) Stack: f5aa3c60 00000000 f706fe74 c107e7df 00000246 dea55380 00000054 f5aa3c60 f706fe44 00000061 f70b4000 c13fff84 00000008 f706fe54 00000000 00000000 00012f00 00012fff 00000028 c109e575 f6b36700 00100000 00000000 f706fe90 Call Trace: [<c107e7df>] unmap_mapping_range+0x7d/0x1e6 [<c109e575>] ? mntput_no_expire+0x52/0xb6 [<c11c12f6>] i915_gem_release_mmap+0x49/0x58 [<c11c3449>] i915_gem_object_unbind+0x4c/0x125 [<c11c353f>] i915_gem_free_object_tail+0x1d/0xdb [<c11c55a2>] i915_gem_free_object+0x3d/0x41 [<c11a6be2>] ? drm_gem_object_free+0x0/0x27 [<c11a6c07>] drm_gem_object_free+0x25/0x27 [<c113c3ca>] kref_put+0x39/0x42 [<c11c0a59>] drm_gem_object_unreference+0x16/0x18 [<c11c0b15>] i915_gem_object_move_to_inactive+0xba/0xbe [<c11c0c87>] i915_gem_retire_requests_ring+0x16e/0x1a5 [<c11c3645>] i915_gem_retire_requests+0x48/0x63 [<c11c36ac>] i915_gem_retire_work_handler+0x4c/0x117 [<c10385d1>] process_one_work+0x140/0x21b [<c103734c>] ? __need_more_worker+0x13/0x2a [<c10373b1>] ? need_to_create_worker+0x1c/0x35 [<c11c3660>] ? i915_gem_retire_work_handler+0x0/0x117 [<c1038faf>] worker_thread+0xd4/0x14b [<c1038edb>] ? worker_thread+0x0/0x14b [<c103be1b>] kthread+0x68/0x6d [<c103bdb3>] ? kthread+0x0/0x6d [<c12970f6>] kernel_thread_helper+0x6/0x10 Code: 00 e8 98 fe ff ff 5d c3 55 89 e5 3e 8d 74 26 00 ba 01 00 00 00 e8 84 fe ff ff 5d c3 55 89 e5 53 8d 64 24 fc 3e 8d 74 26 00 89 c3 <f0> ff 08 79 05 e8 ab ff ff ff 89 e0 25 00 e0 ff ff 89 43 10 58 EIP: [<c1295a20>] mutex_lock+0xf/0x27 SS:ESP 0068:f706fe18 CR2: 0000000000000054 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915: Fix use after free within tracepointChris Wilson2011-03-23
| | | | | | | Detected by scripts/coccinelle/free/kfree.cocci. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915: Restore missing command flush before interrupt on BLT ringChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | | | | | We always skipped flushing the BLT ring if the request flush did not include the RENDER domain. However, this neglects that we try to flush the COMMAND domain after every batch and before the breadcrumb interrupt (to make sure the batch is indeed completed prior to the interrupt firing and so insuring CPU coherency). As a result of the missing flush, incoherency did indeed creep in, most notable when using lots of command buffers and so potentially rewritting an active command buffer (i.e. the GPU was still executing from it even though the following interrupt had already fired and the request/buffer retired). As all ring->flush routines now have the same preconditions, de-duplicate and move those checks up into i915_gem_flush_ring(). Fixes gem_linear_blit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: mengmeng.meng@intel.com
* drm/i915: Disable pagefaults along execbuffer relocation fast pathChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | Along the fast path for relocation handling, we attempt to copy directly from the user data structures whilst holding our mutex. This causes lockdep to warn about circular lock dependencies if we need to pagefault the user pages. [Since when handling a page fault on a mmapped bo, we need to acquire the struct mutex whilst already holding the mm semaphore, it is then verboten to acquire the mm semaphore when already holding the struct mutex. The likelihood of the user passing in the relocations contained in a GTT mmaped bo is low, but conceivable for extreme pathology.] In order to force the mm to return EFAULT rather than handle the pagefault, we therefore need to disable pagefaults across the relocation fast path. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix computation of pitch for dumb bo creatorChris Wilson2011-03-23
| | | | | Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: report correct render clock frequencies on SNBJesse Barnes2011-03-23
| | | | | | | | | | | Fix up the debug file to report the right frequencies. On SNB, we program the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU side. But GFX only runs at half that, so report it as such to avoid confusion. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915/dp: Correct the order of deletion for ghost eDP devicesTakashi Iwai2011-03-23
| | | | | | | | | | | | | The order of the calls does matter indeed. Swapping the call order of intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem. This is because i2c_del_adapter unregisters the device which parent is intel_connector, and connectors are removed in intel_dp_destroy(). Thus intel_dp_encoder_destroy() must be called before intel_dp_destroy(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com>
* drm/i915: Fix tiling corruption from pipelined fencingChris Wilson2011-03-23
| | | | | | | | | | | | | | | | | | | ... even though it was disabled. A mistake in the handling of fence reuse caused us to skip the vital delay of waiting for the object to finish rendering before changing the register. This resulted in us changing the fence register whilst the bo was active and so causing the blits to complete using the wrong stride or even the wrong tiling. (Visually the effect is that small blocks of the screen look like they have been interlaced). The fix is to wait for the GPU to finish using the memory region pointed to by the fence before changing it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584 Cc: Andy Whitcroft <apw@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Note for 2.6.38-stable, we need to reintroduce the interruptible passing] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Dave Airlie <airlied@linux.ie>
* drm/i915: Re-enable self-refreshYuanhan Liu2011-03-23
| | | | | | | | | | | | A broken implementation of is_pot() prevented the detection of when a singular pipe was enabled. Eric Anholt pointed out the existence of is_power_of_2() so use that instead of our broken code! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402 Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Tested-by: xunx.fang@intel.com Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Prevent racy removal of request from client listHerton Ronaldo Krzesinski2011-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client, the client_list for that request may already be removed in i915_gem_release. So we may call twice list_del(&request->client_list), resulting in an oops like this report: [126167.230394] BUG: unable to handle kernel paging request at 00100104 [126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000 [126167.231314] Oops: 0002 [#1] SMP [126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now [126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci [126167.232018] [126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U / [126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0 [126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100 [126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0 [126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000) [126167.232018] Stack: [126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85 [126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040 [126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214 [126167.232018] Call Trace: Unfortunately the call trace reported was cut, but looking at debug symbols the crash is at __list_del, when probably list_del is called twice on the same request->client_list, as the dereferenced value is LIST_POISON1 + 4, and by looking more at the debug symbols before list_del call it should have being called by i915_gem_request_remove_from_client And as I can see in the code, it seems we indeed have the possibility to remove a request->client_list twice, which would cause the above, because we do list_del(&request->client_list) on both i915_gem_request_remove_from_client and i915_gem_release As Chris Wilson pointed out, it's indeed the case: "(...) I had thought that the actual insertion/deletion was serialised under the struct mutex and the intention of the spinlock was to protect the unlocked list traversal during throttling. However, I missed that i915_gem_release() is also called without struct mutex and so we do need the double check for i915_gem_request_remove_from_client()." This change does the required check to avoid the duplicate remove of request->client_list. Bugzilla: http://bugs.launchpad.net/bugs/733780 Cc: stable@kernel.org # 2.6.38 Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: skip redundant operations whilst enabling pipes and planesChris Wilson2011-03-23
| | | | | | | | | | | | | | | | If the pipe or plane is already enabled, then we do not need to enable it again and can skip the delay. Similarly if it is already disabled when we want to disable it, we can also skip it. This fixes a regression from b24e717988, which caused the LVDS output on one PineView machine to become corrupt after changing orientation several times. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: mengmeng.meng@intel.com
* drm/i915: Remove surplus POSTING_READs before wait_for_vblankChris Wilson2011-03-23
| | | | | | | | | | | ... as wait_for_vblank (and friends) will do a flush of the MMIO writes anyway. References: https://bugs.freedesktop.org/show_bug.cgi?id=34601 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into drm-core-nextDave Airlie2011-03-15
|\ | | | | | | | | | | | | | | | | | | This commit changed an internal radeon structure, that meant a new driver in -next had to be fixed up, merge in the commit and fix up the driver. Also fixes a trivial nouveau merge. Conflicts: drivers/gpu/drm/nouveau/nouveau_mem.c
| * drm/i915: Revive combination mode for backlight controlTakashi Iwai2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb drm/i915: Do not handle backlight combination mode specially since this commit introduced other regressions due to untouched LBPC register, e.g. the backlight dimmed after resume. In addition to the revert, this patch includes a fix for the original issue (weird backlight levels) by removing the wrong bit shift for computing the current backlight level. Also, including typo fixes (lpbc -> lbpc). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Acked-by: Indan Zupancic <indan@nul.nu> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | drm/i915: disable opregion lid detection for now.Dave Airlie2011-03-14
| | | | | | | | | | | | | | | | At least on my HP 2540p this is wrong at bootup, fine at any other time once a lid event has occured. This is due to _REG vs _INI ordering in the ACPI tables. Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-nextDave Airlie2011-03-14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'intel/drm-intel-next' of ../drm-next: (755 commits) drm/i915: Only wait on a pending flip if we intend to write to the buffer drm/i915/dp: Sanity check eDP existence drm/i915: Rebind the buffer if its alignment constraints changes with tiling drm/i915: Disable GPU semaphores by default drm/i915: Do not overflow the MMADDR write FIFO Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing" drm/i915: Don't save/restore hardware status page address register drm/i915: don't store the reg value for HWS_PGA drm/i915: fix memory corruption with GM965 and >4GB RAM Linux 2.6.38-rc7 Revert "TPM: Long default timeout fix" drm/i915: Re-enable GPU semaphores for SandyBridge mobile drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#" Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU" drm/i915: Allow relocation deltas outside of target bo drm/i915: Silence an innocuous compiler warning for an unused variable fs/block_dev.c: fix new kernel-doc warning ACPI: Fix build for CONFIG_NET unset mm: <asm-generic/pgtable.h> must include <linux/mm_types.h> x86: Use u32 instead of long to set reset vector back to 0 ... Conflicts: drivers/gpu/drm/i915/i915_gem.c
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2011-03-07
| |\| | | | | | | | | | | | | | | | | | | | | | | | | Apply the trivial conflicting regression fixes, but keep GPU semaphores enabled. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_execbuffer.c
| | * drm/i915: Rebind the buffer if its alignment constraints changes with tilingChris Wilson2011-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Early gen3 and gen2 chipset do not have the relaxed per-surface tiling constraints of the later chipsets, so we need to check that the GTT alignment is correct for the new tiling. If it is not, we need to rebind. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915: Disable GPU semaphores by defaultChris Wilson2011-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09 down to the use of GPU semaphores, and we already know that they appear broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling GPU semaphores is simply hiding another bug by the latency and side-effects of the additional device interaction it introduces...) However, use of semaphores is a massive performance improvement... Only as long as the system remains stable. Enable at your peril. Reported-by: Andi Kleen <andi-fd@firstfloor.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915: Do not overflow the MMADDR write FIFOChris Wilson2011-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whilst the GT is powered down (rc6), writes to MMADDR are placed in a FIFO by the System Agent. This is a limited resource, only 64 entries, of which 20 are reserved for Display and PCH writes, and so we must take care not to queue up too many writes. To avoid this, there is counter which we can poll to ensure there are sufficient free entries in the fifo. "Issuing a write to a full FIFO is not supported; at worst it could result in corruption or a system hang." Reported-and-Tested-by: Matt Turner <mattst88@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"Chris Wilson2011-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit c2e0eb167070a6e9dcb49c84c13c79a30d672431. As it turns out, userspace already depends upon being able to enable tiling on existing bo which it promises to be large enough for its purposes i.e. it will not access beyond the end of the last full-tile row. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35016 Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915: Only wait on a pending flip if we intend to write to the bufferChris Wilson2011-03-07
| | | | | | | | | | | | | | | | | | | | | ... as if we are only reading from it, we can do that concurrently with the queue flip. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915/dp: Sanity check eDP existenceChris Wilson2011-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some hardware claims to have both an LVDS panel and an eDP output. Whilst this may be true in a rare case, more often it is just broken hardware. If we see an eDP device we know that it must be connected and so we can confirm its existence with a simple probe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34165 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915: Don't save/restore hardware status page address registerZhenyu Wang2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | It's cleaned before saving and re-initialized after restoring. So don't need to save/restore it. And also new chip has new address for hardware status page register, don't write to old address. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915: don't store the reg value for HWS_PGAChris Wilson2011-03-02
| | | | | | | | | | | | | | | | | | | | | 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>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson2011-03-01
| |\|
| | * drm/i915: fix memory corruption with GM965 and >4GB RAMJan Niehusmann2011-03-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * drm/i915: Fix unintended recursion in ironlake_disable_rc6Chris Wilson2011-02-24
| | | | | | | | | | | | | | | | | | | | | | | | After disabling, we're meant to teardown the bo used for the contexts, not recurse into ourselves again and preventing module unload. Reported-and-tested-by: Ben Widawsky <bwidawsk@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915: fix corruptions on i8xx due to relaxed fencingDaniel Vetter2011-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It looks like gen2 has a peculiar interleaved 2-row inter-tile layout. Probably inherited from i81x which had 2kb tiles (which naturally fit an even-number-of-tile-rows scheme to fit onto 4kb pages). There is no other mention of this in any docs (also not in the Intel internal documention according to Chris Wilson). Problem manifests itself in corruptions in the second half of the last tile row (if the bo has an odd number of tiles). Which can only happen with relaxed tiling (introduced in a00b10c360b35d6431a9). So reject set_tiling calls that don't satisfy this constrain to prevent broken userspace from causing havoc. While at it, also check the size for newer chipsets. LKML: https://lkml.org/lkml/2011/2/19/5 Reported-by: Indan Zupancic <indan@nul.nu> Tested-by: Indan Zupancic <indan@nul.nu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | drm/i915: Re-enable GPU semaphores for SandyBridge mobileChris Wilson2011-03-01
| | | | | | | | | | | | | | | | | | | | | This seems to be running stably on my test laptop, so hopefully the reported hangs where just symptoms of other bugs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-08 07:59:26 -0500