Adam Hill reported that his Arrandale system required a much longer, up
to 200x500us, wait for the panel to initialise or else modesetting would
fail.
References:
https://bugs.freedesktop.org/show_bug.cgi?id=29141
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Adam Hill <sidepipeuk@yahoo.co.uk>
i965 uses the Display Registers to compute the offset from the display
base so the new base does not need adjusting when flipping. The older
chipsets use a fence to access the display and so do perceive the
surface as linear and have a single base register which is reprogrammed
using the flip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: Marty Jack <martyj19@comcast.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
copy_to_user() returns the number of bytes remaining to be copied and
I'm pretty sure we want to return a negative error code here.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
copy_to_user returns the number of bytes remaining to be copied, but we
want to return a negative error code here. These are returned to
userspace.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
So set the coherent dma mask accordingly. This dma mask is only used
for physical objects, so it won't really matter allocation-wise.
Now this never really surfaced because sane 32bit kernels only have 1G
of lowmem. But some eager testers (distros?) still carry around the patch
to adjust lowmem via a kconfig option. And the kernel seems to favour
high allocations on boot-up, hence the overlay blowing up reliably.
Because the patch is tiny and nicely shows how broken gen2 is it's imho
worth to merge despite the fact that mucking around with the lowmem/
highmem division is (no longer) supported.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28318
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The vblank status bit is a sticky bit that must be cleared with a write
of '1' prior to polling for the next vblank.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
jbarnes: I'd still rather see a lock, but I think you're right that
we don't generally wait in code that needs not to miss an interrupt.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Partial revert of 9d0498a2bf.
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Tested-by: Hugh Dickins <hughd@google.com>
Tested-by: Sven Joachim <svenjoac@gmx.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This fixes blur-like screen corruption on the following card:
VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller [8086:29c2] (rev 10)
intel_sdvo_mode_set() should not return prematurely just because some
features are not supported.
https://bugzilla.kernel.org/show_bug.cgi?id=17151
Signed-off-by: Pavel Roskin <proski@gnu.org>
Reported-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: Relax a couple more checks for failing LVDS modesetting]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 86f100b136.
The kref API requires the handlecount to be initialised to one on object
creation (so that kref_get() doesn't complain upon first use) so the
dalliance in the drivers is required in order to sink the initial
floating reference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
drivers/gpu/drm/i915/intel_overlay.c: In function 'intel_overlay_print_error_state':
drivers/gpu/drm/i915/intel_overlay.c:1467: error: implicit declaration of function 'seq_printf'
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16811
Reported-by: Martin Ziegler <ziegler@uni-freiburg.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Andre Muller <andremuellerster@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When converting this to the new wait_for macro I inverted the wait
condition, which causes all sorts of problems. So correct it to fix
several failures caused by the bad wait (flickering, bad output
detection, tearing, etc.).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (33 commits)
drm/radeon/kms: fix typo in radeon_compute_pll_gain
drm/radeon/kms: try to detect tv vs monitor for underscan
drm/radeon/kms: fix sideport detection on newer rs880 boards
drm/radeon: fix passing wrong type to gem object create.
drm/radeon/kms: set encoder type to DVI for HDMI on evergreen
drm/radeon/kms: add back missing break in info ioctl
drm/radeon/kms: don't enable MSIs on AGP boards
drm/radeon/kms: fix agp mode setup on cards that use pcie bridges
drm: move dereference below check
drm: fix end of loop test
drm/radeon/kms: rework radeon_dp_detect() logic
drm/radeon/kms: add missing asic callback assignment for evergreen
drm/radeon/kms/DCE3+: switch pads to ddc mode when going i2c
drm/radeon/kms/pm: bail early if nothing's changing
drm/radeon/kms/atom: clean up dig atom handling
drm/radeon/kms: DCE3/4 transmitter fixes
drm/radeon/kms: rework encoder handling
drm/radeon/kms: DCE3/4 AdjustPixelPll updates
drm/radeon: Fix stack data leak
drm/radeon/kms: fix GTT/VRAM overlapping test
...
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (58 commits)
drm/i915,intel_agp: Add support for Sandybridge D0
drm/i915: fix render pipe control notify on sandybridge
agp/intel: set 40-bit dma mask on Sandybridge
drm/i915: Remove the conflicting BUG_ON()
drm/i915/suspend: s/IS_IRONLAKE/HAS_PCH_SPLIT/
drm/i915/suspend: Flush register writes before busy-waiting.
i915: disable DAC on Ironlake also when doing CRT load detection.
drm/i915: wait for actual vblank, not just 20ms
drm/i915: make sure eDP PLL is enabled at the right time
drm/i915: fix VGA plane disable for Ironlake+
drm/i915: eDP mode set sequence corrections
drm/i915: add panel reset workaround
drm/i915: Enable RC6 on Ironlake.
drm/i915/sdvo: Only set is_lvds if we have a valid fixed mode.
drm/i915: Set up a render context on Ironlake
drm/i915 invalidate indirect state pointers at end of ring exec
drm/i915: Wake-up wait_request() from elapsed hang-check (v2)
drm/i915: Apply i830 errata for cursor alignment
drm/i915: Only update i845/i865 CURBASE when disabled (v2)
drm/i915: FBC is updated within set_base() so remove second call in mode_set()
...
This one is missed in last pipe control fix for sandybridge,
that really unmask interrupt bit for notify in render engine IMR.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
We now attempt to free "active" objects following a GPU hang as either
the GPU will be reset or the hang is permenant. In either case, the GPU
writes will not be flushed to main memory and it should be safe to
return that memory back to the system.
The BUG_ON(active) is thus overkill and can erroneously fire after a
EIO.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
For the shared paths on the next generation chipsets.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Like on Sandybridge, disabling the DAC here when doing CRT load detect
avoids forever hangs waiting on the hardware.
test procedure on HP 2740p:
boot with no VGA plugged in, start X,
plug in VGA monitor (1280x1024)
chvt 3
machine hangs waiting forever.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Waiting for a hard coded 20ms isn't always enough to make sure a vblank
period has actually occurred, so add code to make sure we really have
passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to
fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
on an HP 8440p instead. Hopefully also fixes
https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
We need to make sure the eDP PLL is enabled before the pipes or planes,
so do it as part of the DP prepare mode set function.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We need to use I/O port instructions to access VGA registers on
Ironlake+, and it doesn't hurt on other platforms, so switch the VGA
plane disable function over to using them. Move it to init time as well
while we're at it, no need to repeatedly disable the VGA plane with
every mode set and DPMS event.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We should disable the panel first when shutting down an eDP link. And
when turning one on, the panel needs to be enabled before link training
or eDP I/O won't be enabled.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Ironlake requires that we clear the reset panel bit during power
sequences and restore it afterwards. Uncondtionally add code to do that
since it should be harmless on SNB+.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.
This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.
Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.
v2:
fix nouveau pushbuf arg (thanks to Ben for pointing it out)
Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* git://git.infradead.org/~dwmw2/ideapad-2.6:
Call acpi_video_register() in intel_opregion_init() failure path
ideapad: Only allow camera state to be set to 0 or 1
ideapad: Stop using global variables
Add Lenovo ideapad driver
If i915 opregion is present, the acpi_video driver doesn't register
itself immediately; it defers that until the i915 opregion code is done.
But if that *fails*, the acpi_video driver was never getting registered.
And thus I have no backlight support on my Lenovo IdeaPad S10-3.
Call acpi_video_register() on the failure path, and it works again.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Matthew Garrett <mjg@redhat.com>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (55 commits)
io-mapping: move asm include inside the config option
vgaarb: drop vga.h include
drm/radeon: Add probing of clocks from device-tree
drm/radeon: drop old and broken mesa warning
drm/radeon: Fix pci_map_page() error checking
drm: Remove count_lock for calling lastclose() after 58474713 (v2)
drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx
drm/radeon/kms: another r6xx/r7xx CS checker fix
DRM: Replace kmalloc/memset combos with kzalloc
drm: expand gamma_set
drm/edid: Split mode lists out to their own header for readability
drm/edid: Rewrite mode parse to use the generic detailed block walk
drm/edid: Add detailed block walk for VTB extensions
drm/edid: Add detailed block walk for CEA extensions
drm: Remove unused fields from drm_display_info
drm: Use ENOENT consistently for the error return for an unmatched handle.
drm/radeon/kms: mark 3D power states as performance
drm: Only set DPMS once on the CRTC not after every encoder.
drm/radeon/kms: add additional quirk for Acer rv620 laptop
drm: Propagate error code from fb_create()
...
Fix up trivial conflicts in drivers/gpu/drm/drm_edid.c
Jesse's initial patch commit said:
"At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context."
I've enhanced this to add a flag to the vc that console layer can set to
indicate they want this behaviour to occur. This also adds support to
fbcon for that flag and adds an fb flag for drivers to indicate they want
to use the support. It enables this for KMS drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: James Simmons <jsimmons@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Expand the crtc_gamma_set function to accept a starting offset. The
reason for this is to eventually use this function for setcolreg from
drm_fb_helper.c. The fbdev colormap function can start at any offset in
the color map.
Signed-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is consistent with trying to access a filename that not exist
within a directory which is a good analogy here. The main reason for the
change is that it is easy to confuse the error code of EBADF as an
performing an ioctl on an invalid file descriptor (rather than an
unknown object).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change the interface to expect a PTR_ERR specifing the real error code
as opposed to assuming a NULL return => -EINVAL. Just once the user may
not be at fault!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
RC6 allows the GPU to enter a lower power state when the GPU is idle.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
[anholt: Fixed the !renderctx error path to actually not enable RC6.]
Signed-off-by: Eric Anholt <eric@anholt.net>
If we have failed to ascertain the fixed mode for the LVDS panel, then
trust the pixel clock ranges reported for the connection when determing
valid modes. This makes intel_sdvo_mode_valid() consistent with
intel_lvds_mode_valid() which is also a no-op is there is no fixed mode
defined. (Since the mode is both validated by SDVO and LVDS, why are
checking against an LVDS fixed mode in SDVO...)
By only defining is_lvds to be true when we actually have an LVDS output
with a fixed mode, we avoid various potential NULL deferences where the
assumption is made that all LVDS outputs have a fixed mode.
References:
Bug 29449 - [Q35] failure to read EDID/vbios for LVDS, no mode => no output
https://bugs.freedesktop.org/show_bug.cgi?id=29449
The primary failure in this bug is not finding the EDID and determining
the correct fixed panel mode. However, this patch should fix the
secondary issue of not enabling any of the standard modes for the panel
either.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
RC6 power state requires a logical render context in place for saving
render context.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This is required by the spec, and without this some 3D programs will
hang after resume from RC6 we enable that.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
If our watchdog fires and we see that the GPU is idle, but that we
are still waiting on an interrupt, forcibly wake-up the waiter.
i915_do_wait_request() should not be racy, yet there are persistent
reports that 945GM hangs whilst the GPU is idle. This implies that the
hardware is not quite as coherent as the documentation claims - a write
followed by a flush is supposed to be coherent in main memory before the
flush is retired and the irq is emitted. This seems to be a sensible and
elegant guard to force the wait to timeout.
v2: Daniel Vetter pointed out that a warning would be useful to explain
why the machine appeared to stall.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
i830 requires 32bpp cursors to be aligned to 16KB, so we have to expose
the alignment parameter to i915_gem_attach_phys_object().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
The i845 and i865 have a peculiarlity in that CURBASE is not the trigger
for the vsync update of the cursor registers but instead the
modification of that register is prohibited whilst the cursor is
enabled. Reorder the write sequence for CURPOS, CURCNTR and CURBASE on
i845 to i865 to match.
v2: Remove the checks for i845/i865 from within i9xx_cursor_update()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
The FBC is dependent upon a few details of the framebuffer so it is
required to be updated within set_base(), so remove the redundant call
from mode_set().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Add a new macro, wait_for, to simplify the act of waiting on a register
to change state. wait_for() takes three arguments, the condition to
inspect on every loop, the maximum amount of time to wait and whether to
yield the cpu for a length of time after each check.
v2: Upgrade failure messages to DRM_ERROR on the suggestion of
Eric Anholt. We do not expect to hit these conditions as they reflect
programming errors, so if we do we want to be notified.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
The cleanup path for early abort failed to nullify the gem_buffer. The
likely consequence of this is zero, since a failure here should mean
aborting the module load.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Previously, we only remembered to update the watermarks for i9xx, and
incorrectly assumed that the crtc->enabled flag was valid at that point
in the dpms cycle.
Note that on my x201s this makes a SR bug on pipe 1 much easier to hit.
(Since before this patch when disabling pipe 0, we either didn't update
the watermarks at all, or when we did we still thought we had two pipes
enabled and so disabled SR.)
References:
Bug 28969 - [Arrandale] Screen flickers, suspect Self-Refresh
https://bugs.freedesktop.org/show_bug.cgi?id=28969
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Within i915_opregion.c there are two blocks of semantically identical
ASLE response codes defined. Only one of those matches the ACPI IGD
OpRegion Specification 0.1, use those.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
shmfs doesn't actually implement i_ops->truncate() so we were not
immedatiately releasing the backing pages when shrinking the gfx cache
under OOM. Instead use a combination of truncate_inode_pages() and
i_ops->truncate_range() as is used by shmem_delete_inode().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Writing to the DSPBASE register triggers the double-buffered update to
all the control registers, so always write it last in the update
sequence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
