The vm callbacks are the same as the SI ones right now
(same regs and bits). We could share the SI variants, and
I may yet do that, but I figured I would add CIK specific
ones for now in case we need to change anything.

V2: add documentation, minor fixes.
V3: integrate vram offset fixes for APUs
V4: enable 2 level VM PTs
V5: index SH_MEM_* regs properly
V6: add ib_parse()
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

v2: split soft reset into compute and gfx.  Still need
to make reset more fine grained, but this should be a
start.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

v2: tiling fixes
v3: more tiling fixes
v4: more tiling fixes
v5: additional register init
v6: rebase
v7: fix gb_addr_config for KV/KB
v8: drop wip KV bits for now, add missing config reg
v9: fix cu count on Bonaire
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

register BAR is now at PCI BAR 5.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

New asics support non-privileged IBs.  This allows us
to skip IB checking in the driver since the hardware
will check the command buffers for us.  When using
non-privileged IBs, if the CP encounters an illegal
register in the command stream, it will halt and generate
an interrupt.  The CP needs to be reset to continue.  For now
just do a full GPU reset when this happens.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Mac laptops with multiple GPUs apparently use the gmux
driver for backlight control.  Don't register a radeon
backlight interface.  We may need to add other pci ids
for other hybrid mac laptops.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=65377Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

- remove adding 2 to checksum, this is incorrect.

This was incorrectly introduced in:
92db7f6c
http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html
However, the off by 2 was due to adding the version twice.
From the examples in the URL above:

[Rafał Miłecki][RV620] fglrx:
0x7454: 00 A8 5E 79     R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10     R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28     R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48     R600_HDMI_VIDEOINFOFRAME_3
===================
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77

However, the payload sum is not 0x1f8, it's 0x1f6.
00 + A8 + 5E + 00 +
00 + 28 + 00 + 10 +
00 + 48 + 00 + 28 +
00 + 48 =
0x1f6

Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part
of the payload.  So the total would be:
(0x82 + 0x2 + 0xD) + 0x1f6 = 0x287
-0x287 = 0x79

- properly emit the AVI infoframe version.  This was not being
emitted previous which is probably what caused the issue above.

This should fix blank screen when HDMI audio is enabled on
certain monitors.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: Rafał Miłecki <zajec5@gmail.com>

This fixes the kernel side so that the ring should come
up and ring and IB tests should work.  The userspace
UVD drivers will also need big endian fixes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

UVD ring can't use scratch thus it does need writeback buffer to keep
a valid address or radeon_ring_backup will trigger a kernel fault.

It's ok to not unpin the write back buffer on suspend as it leave in
gtt and thus does not need eviction.

v2: Fix the uvd case.

Reported and tracked by Wojtek <wojtask9@wp.pl>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

If a buffer is never bound to a virtual memory pagetable than don't try
to unbind it. Only drawback is that we don't update the pagetable when
unbinding the ib pool buffer which is fine because it only happens at
suspend or module unload/shutdown.

Fixes spurious messages about buffers without VM mappings. E.g.:
radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900

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

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

Daniel writes:
Just tiny regression fixes here:
- Two fixes to fix sdvo hotplug which broke in the hpd storm detection
  work.
- One fix to patch-up the sdvo lvds regression fixer from the last pull -
  we need to prefer the vbt mode over edid modes.

* tag 'drm-intel-fixes-2013-06-11' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: prefer VBT modes for SVDO-LVDS over EDID
  drm/i915: Enable hotplug interrupts after querying hw capabilities.
  drm/i915: Fix hotplug interrupt enabling for SDVOC

Patrik writes:
Two fixes for memory leaks split into Cedarview and Poulsbo versions,
and a fix for properly setting the pipe base when using fbdev. It's on
my todo-list to start unifying the chips since they are very similar,
but until then I'd like to split them up in case there are side-effects
on Cedarview that I cannot currently test.

airled: Verified pull from github matches what I expected.
* 'gma500-fixes' of git://github.com/patjak/drm-gma500:
  drm/gma500/cdv: Fix cursor gem obj referencing on cdv
  drm/gma500/psb: Fix cursor gem obj referencing on psb
  drm/gma500/cdv: Unpin framebuffer on crtc disable
  drm/gma500/psb: Unpin framebuffer on crtc disable
  drm/gma500: Add fb gtt offset to fb base

Pull spi fixes from Mark Brown:
 "A few nasty issues, particularly a race with the interrupt controller
  in the xilinx driver, together with a couple of more minor fixes and a
  much needed move of the mailing list away from sourceforge."

* tag 'spi-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: hspi: fixup long delay time
  spi: spi-xilinx: Remove ISR race condition
  spi: topcliff-pch: fix error return code in pch_spi_probe()
  spi: topcliff-pch: Pass correct pointer to free_irq()
  spi: Move mailing list to vger

Merge tag 'stable/for-linus-3.10-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull xen fixes from Konrad Rzeszutek Wilk:
 "Two bug-fixes for regressions:
   - xen/tmem stopped working after a certain combination of
     modprobe/swapon was used
   - cpu online/offlining would trigger WARN_ON."

* tag 'stable/for-linus-3.10-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.
  xen/smp: Fixup NOHZ per cpu data when onlining an offline CPU.

Pull regmap fixes from Mark Brown:
 "The biggest fix here is Lars-Peter's fix for custom locking callbacks
  which is pretty localised but important for those devices that use the
  feature.  Otherwise we've got a couple of fairly small cleanups which
  would have been sent sooner were it not for letting Lars-Peter's patch
  soak for a while"

* tag 'regmap-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: rbtree: Fixed node range check on sync
  regmap: regcache: Fixup locking for custom lock callbacks
  regmap: debugfs: Check return value of regmap_write()

Pull crypto fixes from Herbert Xu:
 "This fixes a build problem in sahara and temporarily disables two new
  optimisations because of performance regressions until a permanent fix
  is ready"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: sahara - fix building as module
  crypto: blowfish - disable AVX2 implementation
  crypto: twofish - disable AVX2 implementation

Commit 10a7a077 ("xen: tmem: enable Xen
tmem shim to be built/loaded as a module") allows the tmem module
to be loaded any time. For this work the frontswap API had to
be able to asynchronously to call tmem_frontswap_init before
or after the swap image had been set. That was added in git
commit 905cd0e1
("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").

Which means we could do this (The common case):

 modprobe tmem		[so calls frontswap_register_ops, no ->init]
			 modifies tmem_frontswap_poolid = -1
 swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
			 < 0 so tmem hypercall done]

Or the failing one:

 swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
 modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
			tmem_frontswap_poolid is 0, does not make a hypercall.
			Later in the module_init, sets tmem_frontswap_poolid=-1]

Which meant that in the failing case we would not call the hypercall
to initialize the pool and never be able to make any frontswap
backend calls.

Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
fixes it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Bob Liu <bob.liu@oracle.com>

In

commit 53d3b4d7
Author: Egbert Eich <eich@suse.de>
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC

Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SDVO-LVDS panels.
Unfortunately some machines seem to not be able to cope with the mode
provided in the EDID. Specifically they seem to not be able to cope
with a 4x pixel mutliplier instead of a 2x one, which seems to have
been worked around by slightly changing the panels native mode in the
VBT so that the dotclock is just barely above 50MHz.

Since it took forever to notice the breakage it's fairly safe to
assume that at least for SDVO-LVDS panels the VBT contains fairly sane
data. So just switch around the order and use VBT modes first.

v2: Also add EDID modes just in case, and spell Egbert correctly.

v3: Elaborate a bit more about what's going on on Chris' machine.

Cc: Egbert Eich <eich@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
Cc: stable@vger.kernel.org
Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(),
and so we never enabled the hotplug interrupts on SDVO as we were
checking too early.

This regression has been introduced somewhere in the hpd rework for
the storm detection and handling starting with

commit 1d843f9d
Author: Egbert Eich <eich@suse.de>
Date:   Mon Feb 25 12:06:49 2013 -0500

    DRM/I915: Add enum hpd_pin to intel_encoder.

and the follow-up patches to use the new encoder->hpd_pin variable for
the different irq setup functions.

The problem is that encoder->hpd_pin was set up _before_ the output
setup was done and so before we could assess the hotplug capabilities
of the outputs on an sdvo encoder.
Reported-by: Alex Fiestas <afiestas@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

A broken conditional would lead to SDVOC waiting upon hotplug events on
SDVOB - and so miss all activity on its SDVO port.

This regression has been introduced in

commit 1d843f9d
Author: Egbert Eich <eich@suse.de>
Date:   Mon Feb 25 12:06:49 2013 -0500

    DRM/I915: Add enum hpd_pin to intel_encoder.

References: https://bugs.freedesktop.org/show_bug.cgi?id=58405Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Pull powerpc fixes from Benjamin Herrenschmidt:
 "This is purely regressions (though not all recent ones) or stable
  material"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Partial revert of "Context switch more PMU related SPRs"
  powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
  powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
  powerpc/power8: Update denormalization handler
  powerpc/pseries: Simplify denormalization handler
  powerpc/power8: Fix oprofile and perf
  powerpc/eeh: Don't check RTAS token to get PE addr
  powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources

Pull ARM fixes from Russell King:
 "The biggest two fixes are fixing a compilation error with the
  decompressor, and a problem with our __my_cpu_offset implementation.

  Other changes are very trivial and small, which seems to be the way
  for most -rc stuff."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()
  ARM: 7750/1: update legacy CPU ID in decompressor cache support jump table
  ARM: 7743/1: compressed/head.S: work around new binutils warning
  ARM: 7742/1: topology: export cpu_topology
  ARM: 7737/1: fix kernel decompressor compilation error with CONFIG_DEBUG_SEMIHOSTING

In commit 59affcd3 I added context switching of more PMU SPRs, because
they are potentially exposed to userspace on Power8. However despite me
being a smart arse in the commit message it's actually not correct. In
particular it interacts badly with a global perf record.

We will have to do something more complicated, but that will have to
wait for 3.11.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

In commit bc09c219 "Fix finding overflowed PMC in interrupt" we added
a printk() to the PMU exception handler. Unfortunately that is not safe.

The problem is that the PMU exception may run even when interrupts are
soft disabled, aka NMI context. We do this so that we can profile parts
of the kernel that have interrupts soft-disabled.

But by calling printk() from the exception handler, we can potentially
deadlock in the printk code on logbuf_lock, eg:

  [c00000038ba575c0] c000000000081928 .vprintk_emit+0xa8/0x540
  [c00000038ba576a0] c0000000007bcde8 .printk+0x48/0x58
  [c00000038ba57710] c000000000076504 .perf_event_interrupt+0x2d4/0x490
  [c00000038ba57810] c00000000001f6f8 .performance_monitor_exception+0x48/0x60
  [c00000038ba57880] c0000000000032cc performance_monitor_common+0x14c/0x180
  --- Exception: f01 (Performance Monitor) at c0000000007b25d4 ._raw_spin_lock_irq
  +0x64/0xc0
  [c00000038ba57bf0] c00000000007ed90 .devkmsg_read+0xd0/0x5a0
  [c00000038ba57d00] c0000000001c2934 .vfs_read+0xc4/0x1e0
  [c00000038ba57d90] c0000000001c2cd8 .SyS_read+0x58/0xd0
  [c00000038ba57e30] c000000000009d54 syscall_exit+0x0/0x98
  --- Exception: c01 (System Call) at 00001fffffbf6f7c
  SP (3ffff6d4de10) is in userspace

Fix it by making sure we only call printk() when we are not in NMI
context.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Cc: <stable@vger.kernel.org> # 3.9
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

When introducing support for DABRX in 4474ef05, we broke older 32-bit CPUs
that don't have that register.

Some CPUs have a DABR but not DABRX.  Configuration are:
- No 32bit CPUs have DABRX but some have DABR.
- POWER4+ and below have the DABR but no DABRX.
- 970 and POWER5 and above have DABR and DABRX.
- POWER8 has DAWR, hence no DABRX.

This introduces CPU_FTR_DABRX and sets it on appropriate CPUs.  We use
the top 64 bits for CPU FTR bits since only 64 bit CPUs have this.

Processors that don't have the DABRX will still work as they will fall
back to software filtering these breakpoints via perf_exclude_event().
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: "Gorelik, Jacob (335F)" <jacob.gorelik@jpl.nasa.gov>
cc: stable@vger.kernel.org (v3.9 only)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

POWER8 can take a denormalisation exception on any VSX registers.

This does the extra 32 VSX registers we don't currently handle.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The following simplifies the denorm code by using macros to generate the long
stream of almost identical instructions.

This patch results in no changes to the output binary, but removes a lot of
lines of code.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

In 2ac6f427 powerpc/cputable: Fix oprofile_cpu_type on power8
we broke all power8 hw events.

This reverts this change and uses oprofile_type instead. Perf now works
on POWER8 again and oprofile will revert to using timers on POWER8.

Kudos to mpe this fix.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2"
are used to retrieve the PE address according to PCI address, which
made up of domain/bus/slot/function. If we don't have those 2 tokens,
the domain/bus/slot/function would be used as the address for EEH
RTAS operations. Some older f/w might not have those 2 tokens and
that blocks the EEH functionality to be initialized. It was introduced
by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization").

The patch skips the check on those 2 tokens so we can bring up EEH
functionality successfully. And domain/bus/slot/function will be
used as address for EEH RTAS operations.

Cc: <stable@vger.kernel.org> # v3.4+
Reported-by: Robert Knight <knight@princeton.edu>
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Tested-by: Robert Knight <knight@princeton.edu>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

If a BAR has the value of 0, we would assume that it is unset yet and
then mark the resource as unset and would reassign it later. But after
commit 6c5705fe (powerpc/PCI: get rid of device resource fixups)
the pcibios_fixup_resources is invoked after the bus address was
translated to linux resource. So the value of res->start is resource
address. And since the resource and bus address may be different, we
should translate it to the bus address before doing the check.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Pull hwmon fix from Guenter Roeck:
 "Improve chip detection in ADM1021 driver to avoid misdetections

  This is not a critical patch, but one we'll want to have applied to
  -stable, since the misdetection especially of LM84 has been causing
  trouble for quite some time."

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617

The internal crtc cursor gem object pointer was never set/updated since
it was required to be set in the first place.

Fixing this will make the pin/unpin count match and prevent cursor
objects from leaking when userspace drops all references to it. Also
make sure we drop the gem obj reference on failure.

This patch only affects Cedarview chips.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

The internal crtc cursor gem object pointer was never set/updated since
it was required to be set in the first place.

Fixing this will make the pin/unpin count match and prevent cursor
objects from leaking when userspace drops all references to it. Also
make sure we drop the gem obj reference on failure.

This patch only affects Poulsbo chips.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Cedarview.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Poulsbo.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

This patch fixes warnings due to missing lock on write error path.

  WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
  Hardware name: empty
  Pid: 26563, comm: dd Tainted: P           O 3.9.4 #12
  Call Trace:
    hpfs_truncate+0x75/0x80 [hpfs]
    hpfs_write_begin+0x84/0x90 [hpfs]
    _hpfs_bmap+0x10/0x10 [hpfs]
    generic_file_buffered_write+0x121/0x2c0
    __generic_file_aio_write+0x1c7/0x3f0
    generic_file_aio_write+0x7c/0x100
    do_sync_write+0x98/0xd0
    hpfs_file_write+0xd/0x50 [hpfs]
    vfs_write+0xa2/0x160
    sys_write+0x51/0xa0
    page_fault+0x22/0x30
    system_call_fastpath+0x1a/0x1f
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@kernel.org  # 2.6.39+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull timer fixes from Thomas Gleixner:

 - Trivial: unused variable removal

 - Posix-timers: Add the clock ID to the new proc interface to make it
   useful.  The interface is new and should be functional when we reach
   the final 3.10 release.

 - Cure a false positive warning in the tick code introduced by the
   overhaul in 3.10

 - Fix for a persistent clock detection regression introduced in this
   cycle

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timekeeping: Correct run-time detection of persistent_clock.
  ntp: Remove unused variable flags in __hardpps
  posix-timers: Show clock ID in proc file
  tick: Cure broadcast false positive pending bit warning