This is required should we ever attempt to use an io-mapping where
KM_USER0 is verboten, such as inside an IRQ context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
R4xx also uses the atom add connector function, but underscan is only
supported on avivo chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v2: Userspace (notably xf86-video-{intel,ati}) became confused when
drmSetInterfaceVersion() started returning -EBUSY as they used a second
call (the first done in drmOpen()) to check their master credentials.
Since userspace wants to be able to repeatedly call
drmSetInterfaceVersion() allow them to do so.
v3: Rebase to drm-core-next.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This connector attribute allows you to enable or disable underscan
on a digital output to compensate for panels that automatically
overscan (e.g., many HDMI TVs). Valid values for the attribute are:
off - forces underscan off
on - forces underscan on
auto - enables underscan if an HDMI TV is connected, off otherwise
default value is auto.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prior to this patch the code was dividing the src_v by the dst_h
and vice versa, rather than src_v/dst_v and src_h/dst_h.
This could lead to problems in the calculation of the display
watermarks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-next' of /ssd/git/drm-next: (230 commits)
drm/i915: Clear the Ironlake dithering flags when the pipe doesn't want it.
drm/agp/i915: trim stolen space to 32M
drm/i915: Unset cursor if out-of-bounds upon mode change (v4)
drm/i915: Unreference object not handle on creation
drm/i915: Attempt to uncouple object after catastrophic failure in unbind
drm/i915: Repeat unbinding during free if interrupted (v6)
drm/i915: Refactor i915_gem_retire_requests()
drm/i915: Warn if we run out of FIFO space for a mode
drm/i915: Round up the watermark entries (v3)
drm/i915: Typo in (unused) register mask for overlay.
drm/i915: Check overlay stride errata for i830 and i845
drm/i915: Validate the mode for eDP by using fixed panel size
drm/i915: Always use the fixed panel timing for eDP
drm/i915: Enable panel fitting for eDP
drm/i915: Add fixed panel mode parsed from EDID for eDP without fixed mode in VBT
drm/i915/sdvo: Set sync polarity based on actual mode
drm/i915/hdmi: Set sync polarity based on actual mode
drm/i915/pch: Set transcoder sync polarity for DP based on actual mode
drm/i915: Initialize LVDS and eDP outputs before anything else
drm/i915/dp: Correctly report eDP in the core connector type
...
Intel variants don't support it.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Logic was:
if (mode0 && mode1)
else if (mode0)
else
Should be:
if (mode0 && mode1)
else if (mode0)
else if (mode1)
Otherwise we may end up calculating the priority regs with
unitialized values.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16492
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
I wrote this for the prime sharing work, but I also noticed other external
non-upstream drivers from a large company carrying a similiar patch, so I
may as well ship it in master.
Signed-off-by: Dave Airlie <airlied@redhat.com>
My fine DisplayPort output was getting ST dithering forever after
having had the LVDS enabled at one point.
Signed-off-by: Eric Anholt <eric@anholt.net>
If we were not able to map the io bar in device init, don't attempt
to unmap it in device fini. All radeons should have a io bar, so
I doubt this would ever trigger, but just to be on the safe side...
Pointed out by: Alberto Milone <alberto.milone@canonical.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
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: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <yakui.zhao@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Do this for both real eDP and for PCH_DP_D when used as the eDP
connection.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Split this patch out of a larger patch for Sandybridge fixes]
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Eric Anholt <eric@anholt.net>
References:
Bug 26691 - Spurious hangcheck whilst executing a long shader over a
large vertex buffer
https://bugs.freedesktop.org/show_bug.cgi?id=26691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
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: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
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 <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
