Totally unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only used by ioctl, not by any in-tree drivers.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

No caller (rightly) cares about it, so drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any in-tree user. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any current driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any driver. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any driver (rightly so!). Kill them.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any in-kernel driver. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NAdam Serbinski <adam@serbinksi.com>
Signed-off-by: NDave 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: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the code cleanup in

7a6b2896 is the first bad commit
commit 7a6b2896
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=29738Reported-by-Tested-by: NTill MAtthiesen <entropy@everymail.net>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

Nouveau needs to be able to drop the mutex before sleeping to prevent a
deadlock from occuring.
Signed-off-by: NBen 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: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen 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: NBertrand VIEILLE <Vieille.Bertrand@free.fr>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This commit fixes fdo bug 29685.
Reported-by: NVlado Plaga <rechner@vlado-do.de>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NPatrice Mandin <patmandin@gmail.com>
Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen 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: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Looks like this got copied from the ddx wrong.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The meaning of ucMemoryType changed on recent boards, however,
ulBootUpSidePortClock should be set properly across all boards.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We are passing a ttm type when we want to pass true/false.
Reported-by: NDr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric 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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

For the shared paths on the next generation chipsets.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric 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: NDave Airlie <airlied@redhat.com>
Signed-off-by: NEric 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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric 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=27452Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noone is using tty argument so let's get rid of it.
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: NJason Wessel <jason.wessel@windriver.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>