If radeon_cs_parser_init() fails, radeon_cs_ioctl() calls
radeon_cs_parser_fini() with the non-zero error value. The latter dereferenced
parser->ib which hasn't been initialized yet -> boom. Add a test for parser->ib
being non-NULL before dereferencing it.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We are happy enough that the KMS driver is stable enough for enough people
for the kms enable/disable to leave staging. Distros can now contemplate
turning this on.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If an error happen in r600_blit_prepare_copy report it rather
than WARNING and keeping execution. For instance if ib allocation
failed we did just warn about but then latter tried to access
NULL ib ptr causing oops. This patch also protect r600_copy_blit
with a mutex as otherwise one process might overwrite blit temporary
data with new one possibly leading to GPU lockup.

Should partialy or totaly fix:
https://bugzilla.redhat.com/show_bug.cgi?id=553279

V2 failing blit initialization is not fatal, fallback to memcpy when
this happen
V3 init blit before startup as we pin in startup, remove duplicate
code (this one was actualy tested unlike V2)
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes the driver not loading on older versions of VMware.
Signed-off-by: NPeter Hanzel <hanzelpeter@gmail.com>
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAustin Yuan <shengquan.yuan@gmail.com>
Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Re-order structure ttm_ref_object to remove 8 bytes of alignment padding
on 64 bit builds, so shrinking its size from 72 to 64 bytes allowing it
to fit into a smaller slab.
Signed-off-by: NRichard Kennedy <richard@rsk.demon.co.uk>
Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

if we get an error, release the AGP if we've acquired it already.
Signed-off-by: NDave Airlie <airlied@redhat.com>

First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.
Signed-off-by: NJohn Kacur <jkacur@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- Fix warning by using %zu instead of %d for size_t
- Fix spelling mistake, "to" should be "too".
Signed-off-by: NJohn Kacur <jkacur@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes errors like:
> reserve_ram_pages_type failed 0x15b7a000-0x15b7b000, track 0x8, req 0x10
when a BO is moved between WC and UC areas.
Reported-by: NXavier Chantry <shiningxc@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.

This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.

V2: fix silly addition of connector dig_block and cleanup the other
places in the code that pick the encoder.

V3: rename to dig_encoder and clean up further - also fix
the picking algorithm.

tested on Lenovo W500 + desktop 3650 cards.
Signed-off-by: NDave Airlie <airlied@redhat.com>

On the W500 we have UNIPHY routed to both DVI and DP, this seems
to always pick the DVI connector which means link training fails.

Switch to using active device to pick the connector, this seems
like it should be safe from a code review, and it fixes things
a bit more here.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes displayport work again here.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This just adds a little more info to the warning for old -ati/mesa
userspaces.
Signed-off-by: NDave Airlie <airlied@redhat.com>

These printks aren't required anymore.
Signed-off-by: NDave Airlie <airlied@redhat.com>

commit 731b5a15
Author: James Simmons <jsimmons@infradead.org>
Date:   Thu Oct 29 20:39:07 2009 +0000

    drm/kms: properly handle fbdev blanking

uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON
is actually for turning output on instead of blank.

This makes fb blank broken on my T61, it put LVDS on but leave
pipe disabled which made screen totally white or caused some
'burning' effect.

[airlied: James objects to this but at this point in 2.6.33,
I can't see a patch that will fix this properly like he wants coming
in time and otherwise this is a regression - proper fix for 2.6.34
hopefully.]

Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is the least invasive fix without migrating the radeon driver
to pm_ops from what I can see. We just always migrate VRAM objects
on IGPs for now and we can fix it up later to migrate depending
on STR vs STD.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use VRAM whenever there is free space for DMA buffers,
but use system GMR memory if using VRAM would cause an eviction.

This significantly reduces the guest system memory usage for
VMs with a large amount of VRAM allocated.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is needed to fix a vmwgfx memory usage bug.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* korg/drm-radeon-next:
  drm/radeon/kms: fix legacy get_engine/memory clock
  drm/radeon/kms/atom: atom parser fixes
  drm/radeon/kms: clean up atombios pll code
  drm/radeon/kms: clean up pll struct
  drm/radeon/kms/atom: fix crtc lock ordering
  drm/radeon: r6xx/r7xx possible security issue, system ram access
  drm/radeon/kms: r600/r700 don't test ib if ib initialization fails
  drm/radeon/kms: Forbid creation of framebuffer with no valid GEM object
  drm/radeon/kms: r600 handle irq vector ring overflow
  drm/radeon/kms: r600/r700 don't process IRQ if not initialized
  drm/radeon/kms: r600/r700 disable irq at suspend
  drm/radeon/kms/r4xx: cleanup atom path
  drm/radeon/kms: fix atombios_crtc_set_base
  drm/radeon/kms/atom: upstream parser updates
  drm/radeon/kms/atom: fix some parser bugs
  drm/radeon/kms: fix hardcoded mmio size in register functions
  drm/radeon/kms/r100: fix bug in CS parser
  drm/radeon/kms/r200: fix bug in CS parser
  drm/radeon/kms/r200: fix bug in CS parser

* 'nouveau/for-airlied' of ../drm-nouveau-next:
  drm/nv50: prevent switching off SOR when in use for DVI-over-DP
  drm/nv50: fail auxch transaction if reply count not what we expect
  drm/nouveau: fix failure path if userspace specifies no valid memtypes
  drm/nouveau: report LVDS as disconnected if lid closed
  drm/nv50: prevent accidently turning off encoders we're actually using
  drm/nv50: fix alignment of per-channel fifo cache
  drm/nouveau: Evict buffers in VRAM before freeing sgdma
  drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts
  drm/nouveau: fix thinko in nv04_instmem.c
  drm/nouveau: fix a race condition in nouveau_dma_wait()

Resending this with Thomas Hellstrom's signoff for merging into 2.6.33

ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(&nentry->list_kref, ttm_bo_release_list);

we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.

However, we then use the next pointer we stored, which is not guaranteed
to be valid.

This was apparently the cause of some Nouveau oopses I experienced.

This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry->next.

v2 updated by me according to Thomas Hellstrom's feedback.
v3 proposed by Thomas Hellstrom. Commit comment updated by me.

Both updates fixed minor efficiency/style issues only and all three versions
should be correct.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Another hack because of us exposing each encoder block's function as
an encoder rather than exposing a single encoder that deals with them
all.

A proper fix will come, it's just rather invasive so this hack will
do until then.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need to add the buffer to the list even if we fail, otherwise the
validate_fini() call won't unreserve + unreference the GEM object,
making TTM very unhappy.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Also adds a module option to ignore the status reported via ACPI, in case
we hit systems with broken ACPI.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fix a bad shift in the post div.

Should fix fdo bug 26145
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only reset the reg block on the initial execute
table call; nested calls require the reg block not be
reset on each call.  Also reset the fb window and
io mode.  This matches the upstream parser behavior.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- split pll adjust into a separate function
- use a union for SetPixelClock params
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- add a new flag for fixed post div
- pull the pll flags into the struct
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes crtc_prepare and crtc_commit match.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch workaround a possible security issue which can allow
user to abuse drm on r6xx/r7xx hw to access any system ram memory.
This patch doesn't break userspace, it detect "valid" old use of
CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte
the address these registers are pointing to with the one of the
last color buffer. This workaround will work for old mesa &
xf86-video-ati and any old user which did use similar register
programming pattern as those (we expect that there is no others
user of those ioctl except possibly a malicious one). This patch
add a warning if it detects such usage, warning encourage people
to update their mesa & xf86-video-ati. New userspace will submit
proper relocation.

Fix for xf86-video-ati / mesa (this kernel patch is enough to
prevent abuse, fix for userspace are to set proper cs stream and
avoid kernel warning) :
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b
http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f

Abusing this register to perform system ram memory is not easy,
here is outline on how it could be achieve. First attacker must
have access to the drm device and be able to submit command stream
throught cs ioctl. Then attacker must build a proper command stream
for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to
overwrite the GPU GART which is in VRAM. To achieve so attacker
as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point
to the GPU GART, then it has to find a way to write predictable
value into those buffer (with little cleverness i believe this
can be done but this is an hard task). Once attacker have such
program it can overwritte GPU GART to program GPU gart to point
anywhere in system memory. It then can reusse same method as he
used to reprogram GART to overwritte the system ram through the
GART mapping. In the process the attacker has to be carefull to
not overwritte any sensitive area of the GART table, like ring
or IB gart entry as it will more then likely lead to GPU lockup.
Bottom line is that i think it's very hard to use this flaw
to get system ram access but in theory one can achieve so.

Side note: I am not aware of anyone ever using the GPU as an
attack vector, nevertheless we take great care in the opensource
driver to try to detect and forbid malicious use of GPU. I don't
think the closed source driver are as cautious as we are.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

If ib initialization failed don't try to test ib as it will result
in an oops (accessing NULL ib buffer ptr).
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This will avoid oops if at later point the fb is use. Trying to create
a framebuffer with no valid GEM object is bogus and should be forbidden
as this patch does.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

In some rare case i faced an irq overflow quickly followed by
a GPU lockup (hard hang) this patch try to deal with irq vector
ring overflow, so far haven't been able to reproduce it with
the patch.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

In some rare case the wptr returned from the hw wasn't 0 and leaded
to trick r600_process_irq that their were irq to process. Add a
check to bail out if irq hasn't been initialized this will avoid
oops provoqued by the rare wptr != 0 on initialization.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

To avoid hw doing anythings after we disabled PCIE GART, fully
disable IRQ at suspend. Also cleanup a bit the ih structure
and process function.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>