I missed this when I fixed up this file.
Noticed-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.

Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)" issue.

v2: agd5f: add some parens around ring->ready check
Signed-off-by: Alex Ivanov <gnidorah@p0n4ik.tk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

CIK uses a different index for 1D DST surfaces compared to SI.  Expose
the new index so libdrm_radeon can use it properly for userspace
drivers.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

There are multiple valid values, not just 0 or 1.  Required
to properly support 2D tiling in the userspace drivers.

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

The string is encoded from the MSB to the LSB of the register.

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Newer versions of gcc seem to wander off into the weeds
when dealing with variable sizes arrays in structs.
Rather than indexing the arrays, use pointer arithmetic.

Fix up spread spectrum tables.

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

If the user has forced the driver to use the internal GPU gart
rather than AGP on an AGP card, force the buffers to vram
as well.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Cc: stable@vger.kernel.org

A couple small msm fixes.  Plus drop of set_need_resched().

* 'msm-fixes-3.12' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: drop unnecessary set_need_resched()
  drm/msm: fix potential NULL pointer dereference
  drm/msm: workaround for missing irq
  drm/msm: return -EBUSY if bo still active
  drm/msm: fix return value check in ERR_PTR()
  drm/msm: fix cmdstream size check
  drm/msm: hangcheck harder
  drm/msm: handle read vs write fences

Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes

Just small fixes, and code cleanups.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: fix return value check in lowlevel_buffer_allocate()
  drm/exynos: Fix address space warnings in exynos_drm_fbdev.c
  drm/exynos: Fix address space warning in exynos_drm_buf.c
  drm/exynos: Remove redundant OF dependency

Merge tag 'drm-intel-fixes-2013-09-19' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Some more dealock fixes around pageflips and gpu hangs, fixes for hsw hangs
when doing modesets/dpms. And a few minor things to rectify issues with our
modeset state tracking which the checker spotted.

* tag 'drm-intel-fixes-2013-09-19' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Don't enable the cursor on a disable pipe
  drm/i915: do not update cursor in crtc mode set
  drm/i915: kill set_need_resched
  drm/i915/dvo: set crtc timings again for panel fixed modes
  drm/i915/sdvo: Robustify the dtd<->drm_mode conversions
  drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversion
  drm/i915: Use proper print format for debug prints
  drm/i915: fix wait_for_pending_flips vs gpu hang deadlock
  drm/i915: Track pfit enable state separately from size

This reverts commit 7c510133.

Well looks like not enough digging was done, libdrm_nouveau before 2.4.33
used contexts,

292da616fe1f936ca78a3fa8e1b1b19883e343b6 nouveau: pull in major libdrm rewrite

got rid of them,
Reported-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Reported-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.

Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out.  Inspired by a patch from
Konstantin Khlebnikov.  The callchain leading to this, cut&pasted from
Konstantin's original patch:

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)

Note that the entire locking in the fb helper around panic/sysrq and kdbg
is ...  non-existant.  So we have a decent change of blowing up
everything.  But since reworking this ties in with funny concepts like the
fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Fix uninitialized warning.

drivers/gpu/drm/ttm/ttm_object.c: In function ‘ttm_base_object_lookup’:
drivers/gpu/drm/ttm/ttm_object.c:213:10: error: ‘base’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  kref_put(&base->refcount, ttm_release_base);
          ^
drivers/gpu/drm/ttm/ttm_object.c:221:26: note: ‘base’ was declared here
  struct ttm_base_object *base;
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.

On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer.  After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.

It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: stable@vger.kernel.org
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

A couple of bios parser fixes (one for ancient chips, another for new ones - important in Optimus configs).  Another to make sure KMS is enabled on certain Optimus configs, and a TTM failure path fix.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau/ttm: prevent double-free in nouveau_sgdma_create_ttm() failure path
  drm/nouveau/bios/init: fix thinko in INIT_CONFIGURE_MEM
  drm/nouveau/kms: enable for non-vga pci classes
  drm/nouveau/bios/init: stub opcode 0xaa

On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.

v2: Move the crtc active checks to intel_crtc_cursor_{set,move} to
    avoid confusing people during modeset

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The cursor is disabled before crtc mode set in crtc disable (and we
assert this is the case), and enabled afterwards in crtc enable. Do not
update it in crtc mode set.

On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.

v2: Add note about HSW hangs - vsyrjala

Cc: stable@vger.kernel.org
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

TTM calls the destructor on its own already...
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Silences the following warnings:
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40:
expected void [noderef] <asn:2>*kvaddr
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40:    got void *
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48:
expected void [noderef] <asn:2>*kvaddr
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48:    got void *
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29:
expected void [noderef] <asn:2>*kvaddr
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29: got void *
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Now that DRM_EXYNOS depends on OF, we do not need individual
drivers to depend on it.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

This was inherited from i915/udl, and not actually needed.
Signed-off-by: Rob Clark <robdclark@gmail.com>

A few more radeon fixes.  A fix for UVD on AGP cards, a fix for non-full
screen scaling on laptop panels with DP bridge chips, and a bunch of dpm
fixes.

* 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: avoid UVD corruptions on AGP cards
  drm/radeon: fix panel scaling with eDP and LVDS bridges
  drm/radeon/dpm: rework auto performance level enable
  drm/radeon: Fix hmdi typo
  drm/radeon/dpm/rs780: fix force_performance state for same sclks
  drm/radeon/dpm/rs780: don't enable sclk scaling if not required
  drm/radeon/dpm/rs780: add some sanity checking to sclk scaling
  drm/radeon/dpm/rs780: use drm_mode_vrefresh()

Putting everything into VRAM seems to help.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
Full aspect) was selected.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Calling force_performance_level() from set_power_state()
doesn't work on some asics because the current power
state pointer has not been properly updated at that point.
Move the calls to force_performance_level() out of the
asic specific set_power_state() functions and into
the main power state sequence.

Fixes dpm resume on SI.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

I keep making that one, so checked if I was the only one. Apparently
not.

Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

If the low and high sclks within a power state are the same,
there no need to enable sclk scaling.  Enabling sclk scaling
can cause display stability issues on some boards.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

If the low and high sclks are the same, there is no need to
enable sclk scaling.  This causes display stability issues on
certain boards.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60857Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>

Since the clock scaling is based on fb divider adjustments,
make sure the other pll parameters are the same.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

Rather than open coding it.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

This very much looks like copypasta from drm/i915's fault handler.
It was used there to duct-tape over issues around gpu reset handling.

Since that can't ever happen for udl and there's seemingly no other
reason for this just drop it.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Radeon drm fixes for 3.12.  All over the place (display, dpm, uvd, etc.).
Also adds a couple more berlin pci ids.

* 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux: (25 commits)
  drm/radeon/dpm: add bapm callback for kb/kv
  drm/radeon/dpm: add bapm callback for trinity
  drm/radeon/dpm: add infrastructure to properly handle bapm
  drm/radeon/dpm: handle bapm on kb/kv
  drm/radeon/dpm: handle bapm on trinity
  drm/radeon: expose DPM thermal thresholds through sysfs
  drm/radeon: simplify driver data retrieval
  drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)
  drm/radeon/dpm: fix fallback for empty UVD clocks
  drm/radeon: add command submission tracepoint
  drm/radeon: remove stale radeon_fence_retire tracepoint
  drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback
  drm/radeon: fix typo in PG flags
  drm/radeon: add some additional berlin pci ids
  drm/radeon/cik: update gpu_init for an additional berlin gpu
  drm/radeon: add spinlocks for indirect register accesss
  drm/radeon: protect concurrent smc register access with a spinlock
  drm/radeon: dpm updates for KV
  drm/radeon: signedness bug in kv_dpm.c
  drm/radeon: clean up r600_free_extended_power_table()
  ...

This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days are now gone so we can drop the hacks and just
rip the reschedule-point out.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The dereference to 'pdata' should be moved below the NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.
Reported-by: Y.C. Chen <yc_chen@aspeedtech.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>