Instead of sleeping for an arbitrary length of time (the documentation
fails to specify how long to wait for) wait until the load detection has
changed state (or at most the 20ms as before).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With the extra intel_wait_for_vblank added in commit
9d0498a2bf periodic stalls were being
triggered (which were detected by i915_hangcheck_elapsed). Partially
revert this change for now.
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix a minor confusion between intel_page_flip_finish(pipe) and
intel_page_flip_finish_plane(plane) -- should have no effect as
currently we map pipe 0 to plane 0 (and pipe 1 to plane 1).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
addin-offset. With the check in place, the panel was declared absent.
v2: Only trust BIOS writers that have graduated to writing OpRegions.
(We are all doomed.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Cc: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It is recommended that we use the Video BIOS tables that were copied
into the OpRegion during POST when initialising the driver. This saves
us from having to furtle around inside the ROM ourselves and possibly
allows the vBIOS to adjust the tables prior to initialisation.
On some systems, such as the Samsung N210, there is no accessible VBIOS
and the only means of finding the VBT is through the OpRegion.
v2: Rearrange the code so that ASLE is enabled along with ACPI
v3: Enable OpRegion parsing even without ACPI
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
It's part of the generic Intel driver infrastructure so rename it in
prepreparation for using it for VBT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we don't flush the write then we can not be sure that the border
colour will have taken effect by the time we try to read it back.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
wait_for() uses msleep() to yield the cpu whilst spinning waiting for a
register to change. kdb asserts that mode changes are atomic and so
prohibits msleep. The alternative would be to use mdelay or to simply
probe the register more often instead of busy waiting.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Jesse's feedback from using the wait_for() macro was that the msleep
argument was that it was superfluous and made the macro more difficult
to use and to read. As the actually amount of time to sleep is not
critical, the crucial part is to sleep and let the processor schedule
something else whilst we wait for the event, replace the argument with a
hardcoded value.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
ums-gem code correctly cancels the retire work (at lastclose time),
kms does not do so. Fix this by canceling the work right after ideling
the gpu.
While staring at the code I noticed that the work function is not
static. Fix this, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the module unloads, all users should be gone, hence all bo references
held by userspace, too. This should already result in an idle ringbuffer.
Still, be paranoid and idle gem before starting the unload dance.
Also kill the call to i915_gem_lastclose under an if (kms), it's a noop
for kms.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Kill any outstanding unpin_work when destroying the corresponding
crtc. Then flush the workqueue before the gem teardown, in case
any unpin work is still outstanding.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
idle_work wasn't cleaned up at all. It takes &dev->struct_mutex, but
accesss the mode_config crtc list (without any other locking!). Hence
this work needs to be canceled before calling drm_mode_config_cleanup.
As evidenced by the kernel's object debuggin code, the current code
also cleans up the timer to early (it gets rearmed). So move it right
before the final cleanup (it seems to work).
Also unconditionally set up the idle_timer in intel_increase_pllclock.
If we're unlucky the timer might fire right away, rendering the call
in the modesetting teardown pointless.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With kms, interrupts now get disabled in the modesetting cleanup. So
free the error state afterwards, it currently gets allocated in
the interrupt handler.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
hotplug_work is queued by the hotplug interrupt and only either emits
a hotplug uevent or queues a crt poll slow-work. No other locking. So
it's safe to cancel this work _after_ irq's have been turned off. But
before the modesetting objects are destroyed because the hotplug
function accesses them (without locking).
The current code (for kms) only switches irqs off after modesetting
teardown, hence move the irq teardown into the modeset cleanup right
before the crtc cleanup.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is the first patch to clean up module unload races due to
outstanding timers/work. Preparatory step: Thou shalt not destroy
the workqueue when new work might still get enqued.
Now error_work gets queued by the hangcheck timer and only (atomically)
reads the chip wedged status. So cancel it right after the hangcheck
timer is killed. But the hangcheck is armed by interrupts, so move
everything after irqs are disabled.
Also change a del_timer to a del_timer_sync in the ums gem code, the
hangcheck timer is self-rearming.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
struct intel_dp contains both struct intel_encoder at the beginning (as
it's base-class) and an i2c adapater. When initializing, the i2c adapter
gets assigned
intel_encoder->ddc_adaptor = &intel_dp->adapter
and the generic intel_encode_destroy happily calls kfree on this pointer.
Ouch. Fix this by using a dp specific cleanup function.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit b9421ae8f3.
This warning was so prelevant, even for apparently working machines,
that it was just causing fear, anxiety and panic.
The root cause still remains, so we will add some better debugging when
we focus on fixing it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=17021
Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 0f3ee801b3.
Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle
systems due to i915 interrupts. So restrict the LVDS to pipe B once more,
whilst the issue is properly diagnosed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307
Reported-and-tested-by: Enrico Bandiello <enban@postal.uv.es>
Poked-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@kernel.org
This reverts commit ce17178094.
This commit has been independently bisected a few times as being the cause
of a s2ram failure.
Reported-and-tested-by: Kyle McMartin <kyle@mcmartin.ca>
Reported-and-tested-by: Andy Isaacson <adi@hexapodia.org>
Cc: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
New pci ids for GT2 and GT2+ on desktop and mobile sandybridge,
and graphics device ids for server sandybridge. Also rename original
ids string to reflect GT1 version.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
MI_FLUSH is being deprecated, but still available on Sandybridge.
Make sure it's enabled as userspace still uses MI_FLUSH.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sandybridge GTT has new cache control bits in PTE, which controls
graphics page cache in LLC or LLC/MLC, so we need to extend the mask
function to respect the new bits.
And set cache control to always LLC only by default on Gen6.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Arguably this is a bug in drm-core in that we should not be called twice
in succession with DPMS_ON, however this is still occuring and we see
FDI link training failures on the second call leading to the occassional
blank display. For the time being ignore the repeated call.
Original patch by Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
We were passing garbage values into the panel-fitter control register
when disabling it on Ironlake - those values (filter modes and reserved
MBZ bits) would have then be re-used the next time panel-fitting was
enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we miss the flip prepare interrupt, we never get into the
software state needed to restart userspace, resulting in a freeze of a
full-screen OpenGL application (such as a compositor).
Work around this by checking DSPxSURF/DSPxBASE to see if the page flip
has actually happened. If it has, do the work we would have done when
the flip prepare interrupt comes in.
Also, add debugfs information to tell us what's going on (based on the
patch from Chris Wilson attached to bugs.fdo bug #29798).
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We reset intel_encoder for every matching encoder whilst iterating over
the encoders attached to this crtc when changing mode. As such in a
cloned configuration intel_encoder may not correspond to the correct
is_edp encoder.
By scoping intel_encoder to the loop, not only is the compiler able to
spot this mistake, we also improve readiability for ourselves.
[It might not be a mistake, within this function it is unclear as to
whether it is permissable for eDP to be cloned...]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were failing when trying to allocate the resource for MMIO of the
MCHBAR because we forgot to specify what type of resource we wanted.
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>
Only stop trying if the aux channel sucessfully reports that the
transmission was completed, otherwise try again. On the 5th failure,
bail and report that something is amiss.
This fixes a sporadic failure in reading the EDID for my external panel
over DP.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
If the VBIOS tells us the mapping of the SDVO device onto the DDC bus,
use it. However, if there is no VBIOS available that mapping is
uninitialised and we should fallback to our earlier guess.
Fix regression introduced in b1083333 (which in turn is a fix for the
regression caused by the introduction of this guess, 14571b4).
References:
Bug 29499 - [945GM] Screen disconnected because of missing VBIOS
https://bugs.freedesktop.org/show_bug.cgi?id=29499
Bug 15109 - i945GM fails to detect EDID on DVI port
https://bugzilla.kernel.org/show_bug.cgi?id=15109
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
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>
Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The information supplied by userspace through these ioctls is only
accessible by dev->drw_idr. But there's no in-tree user of that.
Also userspace does not really care about return values of these ioctls,
either. Only hw/xfree86/dri/dri.c from the xserver actually checks the
return from adddraw and keeps on trying to create a kernel drawable
every time somebody creates a dri drawable. But since that's now a noop,
who cares.
Therefore it's safe to replace these three ioctls with noops and rip
out the implementation.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers happily copy&pasted the default implementation without
checking whether this callback is used at all. It's not. Sigh.
Kill it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's not used by any driver. The destructor callback is unfortunately
used by the via driver in a rather convoluted piece of code used
to reimplement something resembling broken futexes. I didn't dare
to touch this code. But at least kill the needless NULL assignemt
in the sis driver.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's not used internally by any driver, only by some generic ioctls.
So don't export it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
vgaarb: Wrap vga_(get|put) in CONFIG_VGA_ARB
drm/radeon/kms: add missing scratch update in dp_detect
drm/modes: Fix CVT-R modeline generation
drm: fix regression in drm locking since BKL removal.
drm/radeon/kms: remove stray radeon_i2c_destroy
drm: mm: fix range restricted allocations
drm/nouveau: drop drm_global_mutex before sleeping in submission path
drm: export drm_global_mutex for drivers to use
drm/nv20: Don't use pushbuf calls on the original nv20.
drm/nouveau: Fix TMDS on some DCB1.5 boards.
drm/nouveau: Fix backlight control on PPC machines with an internal TMDS panel.
drm/nv30: Apply modesetting to the correct slave encoder
drm/nouveau: Use a helper function to match PCI device/subsystem IDs.
drm/nv50: add dcb type 14 to enum to prevent compiler complaint
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Adam Serbinski <adam@serbinksi.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This locking path needs proper auditing but probably too late for changes at this point for 2.6.36, so lets go with the quick fix, which is to drop the lock around schedule.
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I missed this one in the i2c unification patch. This
is handled in the core radeon i2c code now.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the code cleanup in
7a6b2896f2 is the first bad commit
commit 7a6b2896f2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 2 15:02:15 2010 +0100
drm_mm: extract check_free_mm_node
I've botched up the range-restriction checks. The result is usually
an X server dying with SIGBUS in libpixman (software fallback rendering).
Change the code to adjust the start and end for range restricted
allocations. IMHO this even makes the code a bit clearer.
Fixes regression bug: https://bugs.freedesktop.org/show_bug.cgi?id=29738
Reported-by-Tested-by: Till MAtthiesen <entropy@everymail.net>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next:
drm/nouveau: drop drm_global_mutex before sleeping in submission path
drm: export drm_global_mutex for drivers to use
drm/nv20: Don't use pushbuf calls on the original nv20.
drm/nouveau: Fix TMDS on some DCB1.5 boards.
drm/nouveau: Fix backlight control on PPC machines with an internal TMDS panel.
drm/nv30: Apply modesetting to the correct slave encoder
drm/nouveau: Use a helper function to match PCI device/subsystem IDs.
drm/nv50: add dcb type 14 to enum to prevent compiler complaint
If we keep hold of the mutex here, the process which currently holds the
buffer object will never be able to release it, causing a deadlock.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The "return" command is buggy on the original nv20, it jumps back to
the caller address as expected, but it doesn't clear the subroutine
active bit making the subsequent pushbuf calls fail with a "stack"
overflow.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The TMDS output of an nv11 was being detected as LVDS, because it uses
DCB type 2 for TMDS instead of type 4.
Reported-by: Bertrand VIEILLE <Vieille.Bertrand@free.fr>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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
...
* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next:
drm/nouveau: fix earlier mistake when fixing merge conflict
drm/nvc0: fix thinko in instmem suspend/resume
drm/nouveau: Workaround missing GPIO tables on an Apple iMac G4 NV18.
drm/nouveau: Add TV-out quirk for an MSI nForce2 IGP.
drm/nv50-nvc0: ramht_size is meant to be in bytes, not entries
drm/nouveau: punt some more log messages to debug level
drm/nouveau: remove warning about unknown tmds table revisions
drm/nouveau: check for error when allocating/mapping dummy page
drm/nouveau: fix race condition when under memory pressure
drm/nv50: fix minor thinko from nvc0 changes
drm/nouveau: Don't try DDC on the dummy I2C channel.
Looks like this got copied from the ddx wrong.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
When enabling underscan for hdmi monitors, attempt to detect
whether we are driving a TV or a monitor. The should hopefully
prevent underscan from being enabled on monitors attached via
hdmi that do not overscan the image. Only enable underscan
if the mode is a common hdtv mode (480p, 720p, etc.).
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The meaning of ucMemoryType changed on recent boards, however,
ulBootUpSidePortClock should be set properly across all boards.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We are passing a ttm type when we want to pass true/false.
Reported-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* '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>
Fixes the pink line that shows up with some hdmi monitors. This
will need to be revisited when audio support is added.
Fixes:
http://bugs.freedesktop.org/show_bug.cgi?id=27452
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noone is using tty argument so let's get rid of it.
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This seems to have gotten lost in the hyper-z merge.
Noticed by legume on IRC.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Asics that use an AGP to PCIE bridge don't have the AGP_STATUS
register so just use whatever mode the host side setup.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
"fb_helper_conn" is dereferenced before the check for NULL. It's never
actually NULL here, so this is mostly to keep the static checkers happy.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
"agpmem" is never NULL here because it is the list cursor of a
list_for_each_entry() list.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the connector is eDP, it can only be DP, not TMDS.
Always set the detected sink type. If the sink is
detected as non-DP, but there is no EDID, you can still
manually force the port on. If the sink type is DP
and there's no DPCD, there's no way to force the monitor
on since you need both ends to train the link.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
