there might be a nicer way to fix this but this is the simplest for now.
Signed-off-by: NPierre Willenbrock <pierre@pirsoft.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

[airlied - taken from mailing list posting]
Signed-off-by: NDave Airlie <airlied@redhat.com>

The object is dereferenced before the NULL check. Oops.

Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20235Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This ensures that the user gets the latest information from the hardware
on whether the buffer is busy, potentially reducing the working set of objects
that the user chooses.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In the KMS case, we need to suspend/resume GEM as well.  So on suspend, make
sure we idle GEM and stop any new rendering from coming in, and on resume,
re-init the framebuffer and clear the suspended flag.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The problem was that object_set_to_gpu_domain would set the new write_domains
that are getting set by this batchbuffer, then the accumulated flushes required
for all the objects in preparation for this batchbuffer were posted, and the
brand new write domain would get cleared by the flush being posted.  Instead,
hang on to the new (or old if we're not changing it) value and set it after
the flush is queued.

Results from this noticably included conformance test failures from reads
shortly after writes (where the new write domain had been lost and thus not
flushed and waited on), but is a suspected cause of hangs in some apps when
a write domain is lost on a buffer that gets reused for instruction or
commmand state.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

While not strictly required, it helped while thinking about the following
change.  This change should be invariant.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a regression reported in bug #12613.

[airlied: not I tweaked the patch slightly and fixed it by etienne did
all the hardwork so gets authorship]
Signed-off-by: Netienne <etienne.basset@numericable.fr>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes potential fault at fault time if the object was unreferenced
while the mapping still existed.  Now, while the mmap_offset only lives
for the lifetime of the object, the object also stays alive while a vma
exists that needs it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Need to do this in case the unref ends up doing a free.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Lifted from the DDX modesetting.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They used to be different.  Now they're identical.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to hold the struct_mutex around pinning and the phys object
operations.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Check the error paths within intel_pipe_set_base() to first cleanup and
then report back the error.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

We need to skip the connectors with a NULL encoder to match the success
path and avoid an OOPS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

If we fail to create the ringbuffer, then we need to cleanup the allocated
hws.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

In the case where no EDID data is read from the device, adding the
panel_fixed_mode pointer to the probed modes list causes data corruption.

If the panel_fixed_mode pointer is added to the probed modes list at
init time, a copy of the mode is added again at drm_get_modes() request
time.  Then, the panel_fixed_mode pointer is freed because it is seen as
a duplicate mode.  Unfortunately, this pointer is still stored and used
in mode_fixup().

Because the panel_fixed_mode data is copied and returned at
drm_get_modes() time, it is unnecessary to add this information at init
time.
Signed-off-by: NSteve Aarnio <steve.j.aarnio@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Avoids leaking fbs and associated buffers on release.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Tested-by: NTested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

If we fail whilst constructing the fb, then we need to unpin it as well.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

A missing unpin on the error path.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

A missing unpin on the error path.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

A missing unreference and unpin after rejecting the relocation for an
invalid memory domain.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

We failed to unlock the mutex after failing to create the mmap offset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Set the request alignment to 0, and leave it up to i915_gem_object_pin()
to set the appropriate alignment to match the fence covering the object.

Eric Anholt mentioned that the pinning code is meant to choose the
maximum of the request alignment and that of the fence covering the
object... However currently, the pinning code will only apply the fence
constraints if the supplied alignment is 0.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The name table should only hold a single reference, so avoid leaking
additional references for secondary calls to flink().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
(which is called with mmap_sem already held) takes dev->struct_mutex.
So this is a potential AB-BA deadlock.

The way that i915_gem_execbuffer() triggers a page fault is by doing
copy_to_user() when returning new buffer offsets back to userspace;
however there is no reason to hold the struct_mutex when doing this
copy, since what is being copied is the contents of an array private to
i915_gem_execbuffer() anyway.  So we can fix the potential deadlock (and
get rid of the lockdep warning) by simply moving the copy_to_user()
outside of where struct_mutex is held.

This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.
Reported-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

A missing unreference if the user calls pin() a second time on a pinned
buffer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Also spotted by Owain Ainsworth.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Ensure that the object is unreferenced if we fail to allocate during
drm_gem_flink_ioctl().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Remove the member from the hash table before we free the structure!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Submenus of the graphics support "Support for frame buffer devices" and
"Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are
broken in half after latest changes for Intel 915 mode setting support.

The DRM subsection is broken because one option is put outside the choice
section it depends on.

The frame buffers part is broken then due to circular dependency.  Fix
this by make Intel frame buffers depend on CONFIG_INTEL_AGP.

Kconfigs are broken by d2f59357
("drm/i915: select framebuffer support automatically").

This is probably not only way to fix this.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The DRI people seem to have a hard time getting these right (see also
commit aeb565df).
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Migration helper.

The i915 driver recently added a 'depends on FB' rule to its
Kconfig entry - which silently turns off DRM_I915 if someone
has a working config but no CONFIG_FB selected, and upgrades
to the latest upstream kernel.

Norbert Preining reported this problem:

   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
   Subject     : dri /dev node disappeared with 2.6.29-rc1

So change it to "select FB", which auto-selects framebuffer
support. This way the driver keeps working, regardless of
whether FB was enabled before or not.

Kconfig select's of interactive options can be problematic to
dependencies and can cause build breakages - but in this case
it's safe because it's a leaf entry with no dependencies of its
own.

( There is some minor circular dependency fallout as FB_I810
  and FB_INTEL also used 'depends on FB' constructs - update
  those to "select FB" too. )
Reported-by: NNorbert Preining <preining@logic.at>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDave Airlie <airlied@linux.ie>

As discussed in the long thread about vblank related timeouts, it turns out
GM45 has different frame count registers than previous chips.  This patch
adds support for them, which prevents us from waiting on really stale
sequence values in drm_wait_vblank (which rather than returning immediately
ends up timing out or getting interrupted).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

In dc1336ff (set vblank enable flag correctly
across IRQ uninstall), we made sure drivers that uninstall their interrupt
handler set the vblank enabled flag correctly, so that when interrupts are
re-enabled, vblank interrupts & counts work as expected.  However I missed the
last_vblank field:  it needs to be updated as well, otherwise, at the next
drm_update_vblank_count we'll end up comparing a current count to a stale
one (the last one captured by the disable function), which may trigger the
wraparound handling, leading to a jumpy counter and hangs in drm_wait_vblank.

The jumpy counter can prevent the DRM_WAIT_ON from returning success if the
difference between the current count and the requested count is greater than
2^23, leading to timeouts or hangs, if the ioctl is restarted in a loop (as
is the case in libdrm < 2.4.4).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NMichel Dänzer <michel@daenzer.net>
Tested-by: NTimo Aaltonen <tjaalton@cc.hut.fi>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we failed to allocate a new fence register we would return
VM_FAULT_SIGBUS without relinquishing the lock.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Getting an unknown get/setparam used to be more significant back when they
didn't change much.  However, now that we're in the git world we're using
them instead of a monotonic version number to signal feature availability,
so clients ask about unknown params on older kernels more often.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>