Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable <stable@kernel.org>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prevents code that assumes that the encoder is active when asked to be
disabled from dying a horrible death.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we may try to power down the link at various times, it is not
necessarily still coupled with an encoder and so we must be careful not
to depend upon an operation that is only valid when the link is still
attached to a pipe.
Fixes regression in 5bddd17.
Reported-and-tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org [after applying 5bddd17]
In order for bos to retire eventually, a request must be sent down the
ring. This is expected, for example, by occlusion queries for which mesa
will wait upon (whilst running glean) before issuing more batches and so
the normal activity upon the ring is suspended and we need to emit a
request to clear the idle ring.
Reported-by: Jinjin, Wang <jinjin.wang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30380
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Linus Torvalds pointed out that our code was unbalanced when powering on
the panel with respect to the power off sequence in that we were failing
to restore the panel-fitter. The consequence of this would be that
across a simple DPMS off/on for a non-native mode, without an intervening
modeset, the panel fitter would remain disabled and the output would shift
on the panel.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There's not much we can do here but hope for the best. However the first
failure happens quite frequently and if often remedied by the second
attempt to reset HEAD. So only print the error if that attempt also
fails.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=19802
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Otherwise we can't really fix the abi-braindeadness of forcing
libva to manually wait for rendering when switching rings. Which
in turn makes implementing hw semaphores a pointless exercise
(at least for ironlake).
[Also added the relaxed fencing param to explain the jump in
numbering - relaxed fencing is in -next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes the modesetting on the secondary panel of the Libretto W100 and
presumably many more Ironlake laptops with SDVO LVDS displays.
Reported-and-tested-by: Matthew Willoughby <mattfredwill@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Use the hardware DDA to calculate the ratio with as much accuracy as is
possible.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
If we leave the registers in a conflicting state then when we attempt
to teardown the active mode, we will not disable the pipes and planes
in the correct order -- leaving a plane reading from a disabled pipe and
possibly leading to undefined behaviour.
Reported-and-tested-by: Andy Whitcroft <apw@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32078
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
This workaround only applies to Ironlake.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
The pipe is always set to 8BPC, but here we were leaving whatever
previous bits were set by the BIOS in place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
6xx/7xx was hitting the wrong BUS_CNTL reg and bits.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
Revert "drm/i915/dp: use VBT provided eDP params if available"
drm/i915: Clear pfit registers when not used by any outputs
drm/i915: fix regression due to ba3d8d749b
This reverts commit 869184a675.
This is required for the Sony Vaio Jesse was working on at the time, but
breaks most other eDP machines - machines that were working in earlier
kernels.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31188
Tested-by: Zhao Jian <jian.j.zhao@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... otherwise the panel-fitter may be left enabled with random settings
and cause unintended filtering (i.e. blurring of native modes on external
panels).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942
Reported-and-tested-by: Ben Kohler <bkohler@gmail.com>
Tested-by: Ciprian Docan <docan@eden.rutgers.edu>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector->status
value instead of being discarded.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't track gpu flush request in any special way. So even with
obj->write_domain == 0, a gpu flush might be outstanding but no
yet executed. Even worse, the latest request might use the object
only for reading. So and unconditional call to object_wait_rendering
is needed for !pipelined.
Hence revert that patch fully and untangle the flushing from the
synchronization again.
Reported-by: Keith Packard <keithp@keithp.com>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'intel/drm-intel-fixes' of /ssd/git/drm-next:
drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliable
MAINTAINERS: INTEL DRM DRIVERS list (intel-gfx) is subscribers-only
drm/i915/sdvo: Always fallback to querying the shared DDC line
drm/i915: Handle pagefaults in execbuffer user relocations
drm/i915/sdvo: Only enable HDMI encodings only if the commandset is supported
drm/i915: Only save/restore cursor regs if !KMS
drm/i915: Prevent integer overflow when validating the execbuffer
This reverts commit d33ef52d9d.
This change seems to expose a bug in the 3D driver tiggered by
certain apps, so revert it to keep userspace working.
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit d09c23de intended to add a 30ms delay to give the ADD time to
detect any TVs connected. However, it used the sdvo->is_tv flag to do so
which is dependent upon the previous detection result and not whether the
output supports TVs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
On a few devices, like the Mac Mini, the CRT DDC pins are shared between
the analog connector and the digital connector. In this scenario, rely
on the EDID to determine if a digital panel is connected to the digital
connector.
Reported-and-tested-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently if we hit a pagefault when applying a user relocation for the
execbuffer, we bail and return EFAULT to the application. Instead, we
need to unwind, drop the dev->struct_mutex, copy all the relocation
entries to a vmalloc array (to avoid any potential circular deadlocks
when resolving the pagefault), retake the mutex and then apply the
relocations. Afterwards, we need to again drop the lock and copy the
vmalloc array back to userspace.
v2: Incorporate feedback from Daniel Vetter.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we conflated intel_sdvo->is_hdmi with both having HDMI support on the
ADD along with having HDMI support on the monitor, we would attempt to
use HDMI encodings even if the interface did not support those commands.
Reported-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
I had removed this when I switched the atom indirect io methods
to use the io bar rather than the mmio bar, but it appears it's
still needed.
Reported-by: Mark Lord <kernel@teksavvy.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Under KMS, restoring the cursor is handled upon modeswitch in order to
avoid enabling an undefined set of registers. At the moment, the cursor
is restored before the aperture and modes are fully setup causing some
invalid access during resume, such as:
PGTBL_ER: 0x00040000
Invalid GTT entry during Cursor Fetch
Fix this by only performing cursor register save/restore under UMS where
it is done in the correct sequence.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Commit 2549d6c2 removed the vmalloc used for temporary storage of the
relocation lists used during execbuffer. However, our use of vmalloc was
being protected by an integer overflow check which we do want to
preserve!
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915: Disable FBC on Ironlake to save 1W
drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware
drm/i915/crt: Introduce struct intel_crt
drm/i915: Do not hold mutex when faulting in user addresses
drm: radeon: fix error value sign
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
drm/i915: Retire any pending operations on the old scanout when switching
drm/i915: Fix I2C adapter registration
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (40 commits)
drm/radeon/kms: i2c s/sprintf/snprintf/g for safety
drm/radeon/kms: fix i2c pad masks on rs4xx
drm/ttm: Fix up a theoretical deadlock
drm/radeon/kms: fix tiling info on evergreen
drm/radeon/kms: fix alignment when allocating buffers
drm/vmwgfx: Fix up an error path during bo creation
drm/radeon/kms: register an i2c adapter name for the dp aux bus
drm/radeon/kms/atom: add proper external encoders support
drm/radeon/kms/atom: cleanup and unify DVO handling
drm/radeon/kms: properly power up/down the eDP panel as needed (v4)
drm/radeon/kms/atom: set sane defaults in atombios_get_encoder_mode()
drm/radeon/kms: turn the backlight off explicitly for dpms
drm/radeon/kms: fix typo in r600 cs checker
drm: radeon: fix error value sign
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
nouveau: Acknowledge HPD irq in handler, not bottom half
drm/nouveau: Fix a few confusions between "chipset" and "card_type".
drm/nouveau: don't expose backlight control when available through ACPI
drm/nouveau/pm: improve memtiming mappings
drm/nouveau: Make PCIE GART size depend on the available RAMIN space.
...
Frame buffer compression is broken on Ironlake due to buggy hardware.
Currently it is disabled through chicken bits, but it still consumes
over 1W more than if we simply never attempt to enable the FBC code
paths.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough
that we can dispense with the manual force hotplug trigger stuff. This means that
hotplug detection is as simple as reading the current hotplug register values.
The first time the hotplug detection is activated, the code synchronously waits for a hotplug
sequence in case the hardware hasn't bothered to do a detection cycle since being initialized.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We will use this structure in future patches to store CRT specific
information on the encoder.
Split out and tweaked from a patch by Keith Packard.
Signed-off-by: Keith Packard <keithp@kithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Linus Torvalds found that it was rather trivial to trigger a system
freeze:
In fact, with lockdep, I don't even need to do the sysrq-d thing: it
shows the bug as it happens. It's the X server taking the same lock
recursively.
Here's the problem:
=============================================
[ INFO: possible recursive locking detected ]
2.6.37-rc2-00012-gbdbd01a #7
---------------------------------------------
Xorg/2816 is trying to acquire lock:
(&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e
but task is already holding lock:
(&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
other info that might help us debug this:
2 locks held by Xorg/2816:
#0: (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
#1: (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b
This recursion was introduced by rearranging the locking to avoid the
double locking on the fast path (4f27b5d and fbd5a26d) and the
introduction of the prefault to encourage the fast paths (b5e4f2b). In
order to undo the problem, we rearrange the code to perform the access
validation upfront, attempt to prefault and then fight for control of the
mutex. the best case scenario where the mutex is uncontended the
prefaulting is not wasted.
Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As per advice from Jean Delvare.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A process suspended waiting for a higher sequence or no sequence to unreserve,
a bo may be beaten to the reservation by a process with a lower sequence.
In that case the first process should give up trying to reserve and
return -EAGAIN. In order for that to happen, we must wake waiting processes
when we change sequence, so that they have a chance to detect the new
sequence.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next: (25 commits)
nouveau: Acknowledge HPD irq in handler, not bottom half
drm/nouveau: Fix a few confusions between "chipset" and "card_type".
drm/nouveau: don't expose backlight control when available through ACPI
drm/nouveau/pm: improve memtiming mappings
drm/nouveau: Make PCIE GART size depend on the available RAMIN space.
drm/nouveau: Return error from nouveau_gpuobj_new if we're out of RAMIN.
drm/nouveau: Fix compilation issues in nouveau_pm when CONFIG_HWMON is not set
drm/nouveau: Don't use load detection for connector polling.
drm/nv10-nv20: Fix instability after MPLL changes.
drm/nv50: implement possible workaround for NV86 PGRAPH TLB flush hang
drm/nouveau: Don't poll LVDS outputs.
drm/nouveau: Use "force" to decide if analog load detection is ok or not.
drm/nv04: Fix scanout over the 16MB mark.
drm/nouveau: fix nv40 pcie gart size
drm/nva3: fix overflow in fixed point math used for pll calculation
drm/nv10: Balance RTs expected to be accessed simultaneously by the 3d engine.
drm/nouveau: Expose some BO usage flags to userspace.
drm/nouveau: Reduce severity of the unknown getparam error.
drm/nouveau: Avoid lock dependency between ramht and ramin spinlocks.
drm/nouveau: Some random cleanups.
...
We aren't currently using tiling in userspace on evergreen,
but the info we currently return for the tiling info query
(gb_addr_config) is no adequate for userspace tiling alignment
calculations. It does not contain the bank info. Create a custom
tiling info dword with all the necessary info (num channels,
num banks, group size, row size).
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were previously dropping alignment requests on the floor
when allocating buffers so we always ended up page aligned.
Certain tiling modes on 6xx+ require larger alignment which
wasn't happening before.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This causes the connector to not be added since i2c init fails
for the adapter. Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31688
Noticed by Ari Savolainen.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Ari Savolainen <ari.m.savolainen@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie