- 02 Aug, 2010 40 commits
-
-
Jesse Barnes authored
Some BIOSes will claim a large chunk of stolen space. Unless we reclaim it, our aperture for remapping buffer objects will be constrained. So clamp the stolen space to 32M and ignore the rest. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others. Adding the ignored stolen memory back into the general pool using the memory hotplug code is left as an exercise for the reader. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Simon Farnsworth <simon.farnsworth@onelan.com> Tested-by:
Artem S. Tashkinov <t.artem@mailcity.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
The docs warn that to position the cursor such that no part of it is visible on the pipe is an undefined operation. Avoid such circumstances upon changing the mode, or at any other time, by unsetting the cursor if it moves out of bounds. "For normal high resolution display modes, the cursor must have at least a single pixel positioned over the active screen.” (p143, p148 of the hardware registers docs). Fixes: Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS enabled https://bugs.freedesktop.org/show_bug.cgi?id=24748 v2: Only update the cursor registers if they change. v3: Fix the unsigned comparision of x,y against width,height. v4: Always set CUR.BASE or else the cursor may become corrupt. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Christian Eggers <ceggers@gmx.de> Cc: Christopher James Halse Rogers <chalserogers@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
Chris Wilson authored
When creating an object, we create the handle by which it is known to the process and which own the reference to the object. That reference to the new handle is what we want to transfer to the process, not the lost reference to the object; so free the local object reference *not* the process's handle reference. This brings i915_gem_object_create_ioctl() into line with drm_gem_open_ioctl() Signed-off-by:
-
Chris Wilson authored
If we fail to flush outstanding GPU writes but return the memory to the system, we risk corrupting memory should the GPU recovery and complete those writes. On the other hand, if we bail early and free the object then we have a definite use-after-free and real memory corruption. Choose the lesser of two evils, since in order to recover from the hung GPU we need to completely reset it, those pending writes should never happen. Signed-off-by:
-
Chris Wilson authored
If during the freeing of an object the unbind is interrupted by a system call, which is quite possible if we have outstanding GPU writes that must be flushed, the unbind is silently aborted. This still leaves the AGP region and backing pages allocated, and perhaps more importantly, the object remains upon the various lists exposing us to memory corruption. I think this is the cause behind the use-after-free, such as Bug 15664 - Graphics hang and kernel backtrace when starting Azureus with Compiz enabled https://bugzilla.kernel.org/show_bug.cgi?id=15664 v2: Daniel Vetter reminded me that kernel space programming is never easy. We cannot simply spin to clear the pending signal and so must deferred the freeing of the object until later. v3: Run from the top level retire requests. v4: Tested with P(return -ERESTARTSYS)=.5 from i915_gem_do_wait_request() v5: Rebase against Eric's for-linus tree. v6: Refactor, split and add a comment about avoiding unbounded recursion. Signed-off-by: -
Chris Wilson authored
Combine the iteration over active render rings into a common function. This is in preparation for reusing the idle function to also retire deferred free requests. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Even though "we have enough padding that it should be ok", round up the watermark entries to the next unit to be on the safe side... v2: Use the DIV_ROUND_UP macro v3: Spotted a few more missing round-ups. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Apparently i830 and i845 cannot handle any stride that is not a multiple of 256, unlike their brethren which do support 64 byte aligned strides. Signed-off-by:
-
Zhao Yakui authored
Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
-
Zhao Yakui authored
Signed-off-by:
-
Zhao Yakui authored
When trying to set other display mode besides the fixed panel mode, the panel fitting should be enabled. This is similar to LVDS. Signed-off-by:
-
Zhao Yakui authored
Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
-
Adam Jackson authored
This makes them sort to the front in X, which makes them likely to be the primary outputs if you haven't specified a preference in your DE, which is likely to be what you want. Signed-off-by:
-
Adam Jackson authored
Do this for both real eDP and for PCH_DP_D when used as the eDP connection. Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
-
Chris Wilson authored
Move the common routines into separate functions to not only increase readability, but also throwaway surplus code. In doing so, we review the calculation of the aspect preserving scaling and avoid the use of fixed-point until we need to calculate the accurate scale factor. v2: Improve comments as suggested by Jesse. 1 files changed, 105 insertions(+), 194 deletions(-) Signed-off-by:
-
Chris Wilson authored
We already checked just a couple of lines above that we have found a fixed_panel_mode for the LVDS, so remove the surplus check. Signed-off-by:
-
Jesse Barnes authored
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141 though the workaround itself is still a bit of a mystery. Tested-by:
Adam Hill <sidepipeuk@yahoo.co.uk> Signed-off-by:
-
Chris Wilson authored
A side-effect of being able to use custom page allocations with the sg_table is that it cannot reap the partially constructed scatterlist if fails to allocate a page. So we need to call sg_free_table() ourselves if sg_alloc_table() fails. Signed-off-by:
-
Eric Anholt authored
This resolves the conflict in the EDP code, which has been rather popular to hack on recently. Conflicts: drivers/gpu/drm/i915/intel_dp.c
-
Zhenyu Wang authored
-
Zhenyu Wang authored
Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> [anholt: Split this patch out of a larger patch for Sandybridge fixes] Signed-off-by:
-
Chris Wilson authored
When trying to keep track of features between the kernel, the 2D driver, mesa and the specs, it helps to list any other name by which the device is referred to. Signed-off-by:
-
Chris Wilson authored
The original i965, including the revised G35 and Q35, requires an alignment of 128K for the display surface with linear memory, so increase the requirement from 64k for these chipsets. For the later chipsets in the i965 family, only a 4k alignment is required. (So long as we do not start performing asynchronous flips.) Note the impact of this should be slight as on i965 we should be using a tiled frontbuffer for anything up to a 4096x4096 display. v2: compilation fixes and note that the docs do not exclude the G35 from the extra alignment. Signed-off-by:
-
Adam Jackson authored
Unmask the bits for link training reporting before starting link training. If stage 1 training finished before we unmask them, then we'd spin around in a loop a few times until smashing on through. Which is harmless, since training _did_ succeed, it just looks ugly in dmesg. Signed-off-by:
-
Dan Carpenter authored
NUM_TV_MODES is the same as ARRAY_SIZE(tv_modes). In the end, I decided it was cleaner to remove NUM_TV_MODES and just use ARRAY_SIZE(tv_modes) through out. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Chris Wilson authored
References: Bug 26691 - Spurious hangcheck whilst executing a long shader over a large vertex buffer https://bugs.freedesktop.org/show_bug.cgi?id=26691Signed-off-by: -
Chris Wilson authored
We generally issue an error message at the point of failure, and so this warning with a fairly pointless stacktrace is superfluous and ugly. Needless to say, the common trigger for this WARN happens to be EIO where this is pure noise. Signed-off-by:
-
Jesse Barnes authored
Since mode->clock is in kHz we should be checking against 2700000 instead of just 27000. This patch gets my x201s working again (well working as well as it ever was anyway). When looking for this I also noticed we set link_bw to 270000, but the calculation is different. Does it also need to use kHz or we using 10kHz internally? Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_tv.c|479 col 16| warning: cast truncates bits from constant value (8 becomes 0) Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_drv.c|485 col 25| warning: symbol 'i915_pm_ops' was not declared. Should it be static? Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_drv.c|100 col 18| warning: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c|101 col 3| also defined here drivers/gpu/drm/i915/i915_drv.c|117 col 18| warning: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c|118 col 3| also defined here Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_drv.h|676 col 19| warning: dubious bitfield without explicit `signed' or `unsigned' drivers/gpu/drm/i915/i915_drv.h|712 col 19| warning: dubious bitfield without explicit `signed' or `unsigned' Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
