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>

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>

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>

Yet another regression due to

commit 135c81b8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 21:37:09 2013 +0200

    drm/i915: clean up crtc timings computation

I'm starting to wonder whether this was worth it ...

v2: Actually make it compile.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We've failed to properly clear out the flags when converting a dtd to
a drm mode. For more paranoia just memset the entire structure (and
drop the now redundant clears).

Also since

commit 135c81b8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 21:37:09 2013 +0200

    drm/i915: clean up crtc timings computation

we don't update the crtc timings any more properly, so do that again.

v2: Remove more redundant clearing, spotted by Ville.

v3: Actually make it compile. Oops.

v4: Use a temporary structure to fill in the mode and copy it over
with drm_mode_copy. This will ensure we don't clobber the mode list or
id. Suggested by Ville.

Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Use the = {}; structure clearing instead of memset as
suggested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This adds the enable_bapm callback for kb/kv.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

This adds the enable_bapm callback for trinity.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

bapm is a pm feature for sharing the power budget between
the GPU and the CPU on APUs.  It needs to be enabled or
disabled in certain circumstances.  For now, disable it
when on battery and enable it when on AC power.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

bapm is a power management feature for handling the
power budget between the CPU and GPU on APUs.  This
patch adds support for enabling or disabling it.
For now disable it by default.  Enabling it properly
requires quite a bit more work and will be addressed
in a separate patch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

bapm is a power management feature for handling the
power budget between the CPU and GPU on APUs.  This
patch adds support for enabling or disabling it.
For now disable it by default.  Enabling it properly
requires quite a bit more work and will be addressed
in a separate patch.

This patch fixes hangs on boot on certain trinity
laptops when the system is on battery power.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The hwmon sysfs interface allows exposing temperature limits. The "max"
and "min" thresholds will be exposed as a critical high limit and its
hysteresis value, respectively. This gives the user a better idea of how
well cooling is doing and whether it is sufficient.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

You can get the driver data from struct device directly, there's no
need to get the PCI device first.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards.  This worked
previously because the OUTPUT_ENABLE action is always called
immediately after the ENABLE action so the data_offset remained
set.  In 6f8bbaf5
(drm/radeon/atom: initialize more atom interpretor elements to 0),
we explictly reset data_offset to 0 between atom calls which then
caused this to fail.  The fix is to just skip calling the
OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
action does the same thing and more.  Ultimately, we could
probably drop the OUTPUT_ENABLE action all together on DCE3
asics.

fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791

v2: only rs880 seems to be affected
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org