When we are using memcpy to move objects around, and we fail to memcpy
due to lack of memory to populate or failure to finish the copy, we don't
want to destroy the mm_node that has been copied into old_copy.

While working on a new kms driver that uses memcpy, if I overallocated bo's
up to the memory limits, and eviction failed, then machine would oops soon
after due to having an active bo with an already freed drm_mm embedded in it,
freeing it a second time didn't end well.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

More important fixes for 3.9:
- error_state improvements to help debug the new scanline wait code added
  for gen6+ - bug reports started popping up :( patch from Chris Wilson.
- fix a panel power sequence confusion between the eDP and lvds detection
  code resulting in black screens - regression introduce in 3.8 (Jani
  Nikula)
- Chris fixed the root-cause of the ilk relocation vs. evict bug.
- Another piece of cargo-culted rc6 lore from Jani, fixes up a regression
  where a system refused to go into rc6 after suspend sometimes.

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: fix FORCEWAKE posting reads
  drm/i915: Invalidate the relocation presumed_offsets along the slow path
  drm/i915/eDP: do not write power sequence registers for ghost eDP
  drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state

A number of fixes, and one revert for a patch having some wierd side effects.

* 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
  Revert "drm/radeon: do not move bo to different placement at each cs"
  drm/radeon: improve semaphore debugging on lockup
  drm/radeon: allow FP16 color clear registers on r500
  drm/radeon: clear reset flags if engines are idle

This reverts commit d025e9e2.

This causes corruption for a number of users and needs further
investigation in the next cycle.
https://bugzilla.kernel.org/show_bug.cgi?id=52491
https://bugs.freedesktop.org/show_bug.cgi?id=58659
http://lists.freedesktop.org/archives/dri-devel/2013-January/032961.htmlSigned-off-by: Alex Deucher <alexander.deucher@amd.com>

We stopped reading FORCEWAKE for posting reads in

commit 8dee3eea
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

and started using something from the same cacheline instead. On the
bug reporter's machine this broke entering rc6 states after a
suspend/resume cycle. It turns out reading ECOBUS as posting read
worked fine, while GTFIFODBG did not, preventing RC6 states after
suspend/resume per the bug report referenced below. It's not entirely
clear why, but clearly GTFIFODBG was nowhere near the same cacheline
or address range as FORCEWAKE.

Trying out various registers for posting reads showed that all tested
registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
work. Conversely, most (but not quite all) registers for which
NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
bug.

Based on the above, add posting reads on ECOBUS where GTFIFODBG was
previously relied on.

In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
address range as FORCEWAKE_VLV.

v2: Add more details to the commit message. No functional changes.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
CC: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: add cc: stable and make the commit message a bit clearer that
this is a regression fix and what exactly broke.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.

Fixes regression from commit bcf50e27
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Nov 21 22:07:12 2010 +0000

    drm/i915: Handle pagefaults in execbuffer user relocations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@fwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Some machines detect an eDP port even if it's not really there, and eDP
initialization has a fail path for this. Typically such machines have an
LVDS display instead. A regression introduced in

commit 82ed61fa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Oct 20 20:57:41 2012 +0200

    drm/i915: make edp panel power sequence setup more robust

updated the power sequence registers PCH_PP_ON_DELAYS, PCH_PP_OFF_DELAYS,
and PCH_PP_DIVISOR also in the ghost eDP case, messing up the LVDS display.

Split the power sequencer initialization into two, delaying the register
updates until after we know the eDP is real.

Note: Keep the PP_CONTROL unlocking in the first part, even if it does not
update registers, per the commit message of the above mentioned commit.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52601Reported-and-tested-by: Ryan Coe <ryan@rycomotorsports.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Probably not a candidate for stable kernels because of conflicts
in DRM versioning.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Fixes a hard lock in the gpu reset code after the
rework for DMA support (0ecebb9e
"drm/radeon: switch to a finer grained reset for evergreen")
due to not bailing before the MC shutdown if the relevant engines
are idle.

Discussion:
http://lists.freedesktop.org/archives/dri-devel/2013-January/032985.htmlReported-by: Eldad Zack <eldad@fogrefinery.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

These are useful for investigating hangs involving WAIT_FOR_EVENT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Apply a droplet of Future-Proof in the if-ladder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This is a left-over from when udl_get_edid returned the amount of bytes
successfully read, which it no longer does.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

The buffer passed to usb_control_msg may end up in scatter-gather list, and
may thus not be on the stack. Having it on the stack usually works on x86, but
not on other archs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

udldrmfb only reads the main EDID block, and if that advertises extensions
the drm_edid code expects them to be present, and starts reading beyond the
buffer udldrmfb passes it.

Although it may be possible to read more EDID info with the udl we simpy don't
know how, and even if trial and error gets it working on one device, that is
no guarantee it will work on other revisions. So this patch does a simple fix
in the form of patching the EDID info to report 0 extension blocks, this
fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Fixes for UMS mode which has been broken for a while plus an rn50 fix
and a dma fix.

* 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
  radeon/kms: fix dma relocation checking
  radeon/kms: force rn50 chip to always report connected on analog output
  drm/radeon: fix error path in kpage allocation
  drm/radeon: fix a bogus kfree
  drm/radeon: fix NULL pointer dereference in UMS mode

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

Regression fixes since rework mostly.

* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nvc0/fb: fix crash when different mutex is used to protect same list
  drm/nouveau/clock: fix support for more than 2 monitors on nve0
  drm/nv50/disp: fix selection of bios script for analog outputs
  drm/nv17-50: restore fence buffer on resume
  drm/nouveau: fix blank LVDS screen regression on pre-nv50 cards
  drm/nouveau: fix nouveau_client allocation failure path
  drm/nouveau: don't return freed object from nouveau_handle_create
  drm/nouveau/vm: fix memory corruption when pgt allocation fails
  drm/nouveau: add locking around instobj list operations
  drm/nouveau: do not forcibly power on lvds panels
  drm/nouveau/devinit: ensure legacy vga control is enabled during post

Fixes regression introduced in commit 861d2107
"drm/nouveau/fb: merge fb/vram and port to subdev interfaces"

nv50_fb_vram_{new,del} functions were changed to use
nouveau_subdev->mutex instead of the old nouveau_mm->mutex.
nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't
have its own fb_vram_del function, using nv50_fb_vram_del instead.
Because of this, on nvc0 a different mutex ends up being used to protect
additions and deletions to the same list.

This patch is a -stable candidate for 3.7.
Signed-off-by: Aleksi Torhamo <aleksi@torhamo.net>
Reported-by: Roy Spliet <r.spliet@student.tudelft.nl>
Tested-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Fixes regression introduced in commit 70790f4f
"drm/nouveau/clock: pull in the implementation from all over the place"

When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set,
the PLLs it is used for got limited to only the first two VPLLs.

nv50_crtc_set_clock was only called to change VPLLs, so it didn't
limit what it was used for in any way. Since nvc0_clock_pll_set is
used for all PLLs, it has to specify which PLLs the code is used for,
and only listed the first two VPLLs.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735

This patch is a -stable candidate for 3.7.
Signed-off-by: Aleksi Torhamo <aleksi@torhamo.net>
Tested-by: Aleksi Torhamo <aleksi@torhamo.net>
Tested-by: Sean Santos <quantheory@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Analog output number was overwritten by value from digital output path.
Fix it.

Fixes resume from s2ram: https://bugs.freedesktop.org/show_bug.cgi?id=58729
(as stumbled on by J Binder, Pontus Fuchs and me)
Fixes blank screen on module load (reported by Sune Mølgaard).

Fixes regression from commit 186ecad2
("drm/nv50/disp: move remaining interrupt handling into core").
Reported-by: J Binder <wheel@herr-der-mails.de>
Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Reported-by: Sune Mølgaard <sune@molgaard.org>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Tested-by: Sune Mølgaard <sune@molgaard.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Since commit 5e120f6e "drm/nouveau/fence:
convert to exec engine, and improve channel sync" nouveau fence sync
implementation for nv17-50 and nvc0+ started to rely on state of fence buffer
left by previous sync operation. But as pinned bo's (where fence state is
stored) are not saved+restored across suspend/resume, we need to do it
manually.

nvc0+ was fixed by commit d6ba6d21
"drm/nvc0/fence: restore pre-suspend fence buffer context on resume".

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Commit 2a44e499 ("drm/nouveau/disp: introduce proper init/fini, separate
from create/destroy") started to call display init routines on pre-nv50
hardware on module load. But LVDS init code sets driver state in a way
which prevents modesetting code from operating properly.

nv04_display_init calls nv04_dfp_restore, which sets encoder->last_dpms to
NV_DPMS_CLEARED.

drm_crtc_helper_set_mode
  nv04_dfp_prepare
    nv04_lvds_dpms(DRM_MODE_DPMS_OFF)

nv04_lvds_dpms checks last_dpms mode (which is NV_DPMS_CLEARED) and wrongly
assumes it's a "powersaving mode", the new one (DRM_MODE_DPMS_OFF) is too,
so it skips calling some crucial lvds scripts.
Reported-by: Chris Paulson-Ellis <chris@edesix.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Depending on the point of failure, freed object would be returned
or memory leak would happen.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

If we return freed vm, nouveau_drm_open will happily call nouveau_cli_destroy,
which will try to free it again.
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fixes memory corruptions, oopses, etc. when multiple gpuobjs are
simultaneously created or destroyed.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

This fix was put in place to fix a bug where the eDP panel on certain
laptops fails to respond over the aux channel after suspend.

It appears that on some systems (Dell M6600, with LVDS panel) there's a
very bad interaction with the eDP init table that causes the SOR to get
very confused and not drive the panel correctly, leading to bleed.

A DPMS off/on cycle is enough to bring it back, but, this will avoid the
problem by not touching the panel GPIOs at times we're not meant to.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fixes ACPI backlight control after suspend on some systems.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We were checking the index against the size of the relocation buffer
instead of against the last index. This fix kernel segfault when
userspace submit ill formated command stream/relocation buffer pair.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Those rn50 chip are often connected to console remoting hw and load
detection often fails with those. Just don't try to load detect and
report connect.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Index into chunks[] array doesn't look right.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.

This patch fixes a kernel oops that can be provoked
in UMS mode.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Daniel writes:
"Pretty much all just major fixes:
- 2 pieces of duct-tape for the ilk bug.
- Sprite regression fixes from Chris.
- OOPS fix for a div-by-zero from Chris, regression due to the modeset
  rework in 3.7, now brought to light by a benign change in 3.8.
- Fix interrupted bo pinning, used to work around CS coherency issues on
  i830/i845 (kernel also has a w/a newly in 3.8, but pinning is more efficient if
  possible)."

Pull x86 platform driver bugfixes from Matthew Garrett.

* 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86:
  asus-laptop: Fix potential invalid pointer dereference
  Update MAINTAINERS entry
  asus-laptop: Do not call HWRS on init
  sony-laptop: fix SNC buffer calls when SN06 returns Integers
  samsung-laptop: Add quirk for broken acpi_video backlight on N250P
  acer-wmi: add Aspire 5741G touchpad toggle key
  acer-wmi: change to emit touchpad on off key
  acer-wmi: fix obj is NULL but dereferenced
  MAINTAINERS: change the mail address of acer-wmi/msi-laptop maintainer

Pull KVM bugfixes from Marcelo Tosatti.

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: use dynamic percpu allocations for shared msrs area
  KVM: PPC: Book3S HV: Fix compilation without CONFIG_PPC_POWERNV
  powerpc: Corrected include header path in kvm_para.h
  Add rcu user eqs exception hooks for async page fault

Merge tag 'trace-3.8-rc2-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing regression fix from Steven Rostedt:
 "A change that came in this merge window broke the writing to the
  trace_options file.  It causes garbage to be read during the compare
  of option names, and breaks setting options via the trace_options
  file, although options can still be set via the options/<option>
  files."

* tag 'trace-3.8-rc2-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Fix regression of trace_options file setting

This partially reverts

commit 6c085a72
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 20 11:40:46 2012 +0200

    drm/i915: Track unbound pages

Closer inspection of that patch revealed a bunch of unrelated changes
in the shrinker:
- The shrinker count is now in pages instead of objects.
- For counting the shrinkable objects the old code only looked at the
  inactive list, the new code looks at all bounds objects (including
  pinned ones). That is obviously in addition to the new unbound list.
- The shrinker cound is no longer scaled with
  sysctl_vfs_cache_pressure. Note though that with the default tuning
  value of vfs_cache_pressue = 100 this doesn't affect the shrinker
  behaviour.
- When actually shrinking objects, the old code first dropped
  purgeable objects, then normal (inactive) objects. Only then did it,
  in a last-ditch effort idle the gpu and evict everything. The new
  code omits the intermediate step of evicting normal inactive
  objects.

Safe for the first change, which seems benign, and the shrinker count
scaling, which is a bit a different story, the endresult of all these
changes is that the shrinker is _much_ more likely to fall back to the
last-ditch resort of idling the gpu and evicting everything.  The old
code could only do that if something else evicted lots of objects
meanwhile (since without any other changes the nr_to_scan will be
smaller than the object count).

Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only
dentry/inode object caches should scale their shrinker counts with
vfs_cache_pressure. Originally I've had that change reverted, too. But
Chris Wilson insisted that it's too bogus and shouldn't again see the
light of day.

Hence revert all these other changes and restore the old shrinker
behaviour, with the minor adjustment that we now first scan the
unbound list, then the inactive list for each object category
(purgeable or normal).

A similar patch has been tested by a few people affected by the gen4/5
hangs which started to appear in 3.7, which some people bisected to
the "drm/i915: Track unbound pages" commit. But just disabling the
unbound logic alone didn't change things at all.

Note that this patch doesn't fix the referenced bugs, it only hides
the underlying bug(s) well enough to restore pre-3.7 behaviour. The
key to achieve that is to massively reduce the likelyhood of going
into a full gpu stall and evicting everything.

v2: Reword commit message a bit, taking Chris Wilson's comment into
account.

v3: On Chris Wilson's insistency, do not reinstate the rather bogus
vfs_cache_pressure change.
Tested-by: Greg KH <gregkh@linuxfoundation.org>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
References: https://bugs.freedesktop.org/show_bug.cgi?id=57122
References: https://bugs.freedesktop.org/show_bug.cgi?id=56916
References: https://bugs.freedesktop.org/show_bug.cgi?id=57136
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Pull s390 patches from Martin Schwidefsky:
 "Add the finit_module system call, fix the irq statistics in
  /proc/stat, fix a s390dbf lockdep problem, a patch revert for a
  problem that is not 100% understood yet, and a few patches to
  fix warnings."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/pci: define read*_relaxed functions
  s390/topology: export cpu_topology
  s390/pm: export pm_power_off
  s390/pci: define isa_dma_bridge_buggy
  s390/3215: partially revert tty close handling fix
  s390/irq: count cpu restart events
  s390/irq: remove split irq fields from /proc/stat
  s390/irq: enable irq sum accounting for /proc/stat again
  s390/syscalls: wire up finit_module syscall
  s390/pci: remove dead code
  s390/smp: fix section mismatch for smp_add_present_cpu()
  s390/debug: Fix s390dbf lockdep problem in debug_(un)register_view()

The latest change to allow trace options to be set on the command
line also broke the trace_options file.

The zeroing of the last byte of the option name that is echoed into
the trace_option file was removed with the consolidation of some
of the code. The compare between the option and what was written to
the trace_options file fails because the string holding the data
written doesn't terminate with a null character.

A zero needs to be added to the end of the string copied from
user space.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>