Using PM latency request turns out to be very fragile and only works for
some systems, depending upon the ACPI implementation. However, I've
stumbled across a promising bit in INSTPM: "Interrupt-Based AGPBUSY#".

This reverts commit b0b544cd.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Userspace has a legitimate requirement to use a delta that points to
outside of the target bo, and so we need to enable this. (As this is an
abi break, albeit a relaxation of the current restrictions, mark the change
with a new flag.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

drivers/gpu/drm/i915/i915_irq.c: In function ‘ironlake_irq_postinstall’:
drivers/gpu/drm/i915/i915_irq.c:1618: warning: unused variable ‘pipe’
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Merge in the conflicting eDP fix.

Conflicts:
	drivers/gpu/drm/i915/i915_irq.c
	drivers/gpu/drm/i915/intel_display.c
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The code paths for modesetting are growing in complexity as we may need
to move the buffers around in order to fit the scanout in the aperture.
Therefore we face a choice as to whether to thread the interruptible status
through the entire pinning and unbinding code paths or to add a flag to
the device when we may not be interrupted by a signal. This does the
latter and so fixes a few instances of modesetting failures under stress.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we just need a temporary array whilst performing the relocations for
the execbuffer, first attempt to allocate using kmalloc even if it is
not of order page-0. This avoids the overhead of remapping the
discontiguous array and so gives a moderate boost to execution
throughput.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Seems like we are forever to be cursed with buggy firmware, so allow the
user to explicitly set the panel connection status.

Of secondary utility for cases where I run laptops with the lid closed,
but still want to configure the LVDS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Dave Airlie spotted that we had a potential bug should we ever rearrange
the drm_i915_gem_object so not the base drm_gem_object was not its first
member. He noticed that we often convert the return of
drm_gem_object_lookup() immediately into drm_i915_gem_object and then
check the result for nullity. This is only valid when the base object is
the first member and so the superobject has the same address. Play safe
instead and use the compiler to convert back to the original return
address for sanity testing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In a few places I replaced reads of per-pipe registers with the actual
register offsets themselves (converting I915_READ(reg) to _PIPE(reg)).
Alexey caught this on his 9xx machine because the cursor control write
was affected.  A quick audit showed a few more places where I'd borked
a read, so here's a patch to fix things up.
Reported-by: NAlexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: compilation fix]
Tested-by: NAlexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit 633f2ea2 and the
attempted fix dcbe6f2b.

There is a single clock source used for both SSC (some LVDS and DP) and
non-SSC (VGA, DVI) outputs. So we need to be careful to only enable SSC
as necessary. However, fiddling with DREFCLK was causing DP links to be
dropped and we do not have a fix ready, so revert.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems.  So avoid FDI training and PCH PLL enabling in that case.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NAndy Whitcroft <apw@canonical.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27187
Tested-by: Thorsten Vollmer <thorsten@thvo.de> (DFI-ACP G5M150-N w/852GME)
Tested-by: Moritz Brunner <2points@gmx.org> (Asus M2400N/i855GM)
Tested-by: Indan Zupancic <indan@nul.nu> (Thinkpad X40/855GM rev 02)
Tested-by: Eric Anholt <eric@anholt.net> (865G)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events).  So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
  eCryptfs: Copy up lower inode attrs in getattr
  ecryptfs: read on a directory should return EISDIR if not supported
  eCryptfs: Handle NULL nameidata pointers
  eCryptfs: Revert "dont call lookup_one_len to avoid NULL nameidata"

The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.

If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.

A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.

IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.

For more information see the below links. This fixes bugs:

  http://bugzilla.kernel.org/show_bug.cgi?id=23472
  http://bugzilla.kernel.org/show_bug.cgi?id=25072Signed-off-by: NIndan Zupancic <indan@nul.nu>
Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We force particular alignment when we generate attribute structures
when generation MODULE_VERSION() data and we need to make sure that
this alignment is followed when we iterate over these structures,
otherwise we may crash on platforms whose natural alignment is not
sizeof(void *), such as m68k.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
[ There are more issues here, but the fixes are incredibly ugly - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86:
  dell-laptop: Toggle the unsupported hardware killswitch
  thinkpad_acpi: Always report scancodes for hotkeys
  acer-wmi: Fix capitalisation of GUID
  platform/x86: ideapad-laptop depends on INPUT
  platform: x86: acer-wmi: world-writable sysfs threeg file
  platform: x86: asus_acpi: world-writable procfs files
  platform: x86: tc1100-wmi: world-writable sysfs wireless and jogdial files
  platform-drivers: x86: pmic: Use request_irq instead of chained handler
  platform-drivers: x86: pmic: Use irq_chip buslock mechanism
  platform-drivers: x86: Convert pmic to new irq_chip functions
  platform-drivers: x86: pmic: Fix up bogus irq hackery

* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
  fixdep: Do not record dependency on the source file itself

Add fs/eventfd.c to filesystems docbook.
Make typo corrections in fs/eventfd.c.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Update the "log_buf_len" description to use [KMG] syntax for the
buffer size.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The '[KMG]' suffix is commonly described after a number of kernel
parameter values documentation.  Explicitly state its semantics.
Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Complete the crashkernel= kernel parameter documentation.
Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  ceph: keep reference to parent inode on ceph_dentry
  ceph: queue cap_snaps once per realm
  libceph: fix socket write error handling
  libceph: fix socket read error handling

Merge branch 's5p-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung

* 's5p-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: S5PV210: Fix regulator names
  ARM: S5PV210: Update max8998_platform_data
  ARM: SAMSUNG: Drop exporting s3c24xx_ts_set_platdata
  ARM: S5P: Fix end address in memory resource information for UART devices
  ARM: S5P64X0: Cleanup map.h file
  ARM: S5P6442: Cleanup map.h file
  ARM: S5PC100: Clenaup map.h file
  ARM: S5PV210: Cleanup map.h file
  ARM: S5PV310: Cleanup map.h file

* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
  [CIFS] update cifs version
  cifs: Fix regression in LANMAN (LM) auth code
  cifs: fix handling of scopeid in cifs_convert_address

* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
  ARM: 6745/1: kprobes insn decoding fix
  ARM: tlb: move noMMU tlb_flush() to asm/tlb.h
  ARM: tlb: delay page freeing for SMP and ARMv7 CPUs
  ARM: Keep exit text/data around for SMP_ON_UP
  ARM: Ensure predictable endian state on signal handler entry
  ARM: 6740/1: Place correctly notes section in the linker script
  ARM: 6700/1: SPEAr: Correct SOC config base address for spear320
  ARM: 6722/1: SPEAr: sp810: switch to slow mode before reset
  ARM: 6712/1: SPEAr: replace readl(), writel() with relaxed versions in uncompress.h
  ARM: 6720/1: SPEAr: Append UL to VMALLOC_END
  ARM: 6676/1: Correct the cpu_architecture() function for ARMv7
  ARM: 6739/1: update .gitignore for boot/compressed
  ARM: 6743/1: errata: interrupted ICALLUIS may prevent completion of broadcasted operation
  ARM: 6742/1: pmu: avoid setting IRQ affinity on UP systems
  ARM: 6741/1: errata: pl310 cache sync operation may be faulty

* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
  [S390] net: provide architecture specific NET_SKB_PAD
  [S390] atomic: use inline asm
  [S390] correct ipl parameter block safe guard
  [S390] atomic: use ACCESS_ONCE() for atomic_read()
  [S390] dasd: correct device table

Update version to 1.71 so we can more easily spot modules with the last two fixes
Signed-off-by: NSteve French <sfrench@us.ibm.com>

It is found on Dell Inspiron 1018 that the firmware reports that the hardware
killswitch is not supported. This makes the rfkill key not functional.

This patch forces the driver to toggle the firmware rfkill status in the case
that the hardware killswitch is indicated as unsupported by the firmware.
Signed-off-by: NKeng-Yu Lin <keng-yu.lin@canonical.com>
Tested-by: NAlessio Igor Bogani <abogani@texware.it>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Some thinkpad hotkeys report key codes like KEY_FN_F8 when something
like KEY_VOLUMEDOWN is desired. Always provide the scan codes in
addition to the key codes to assist with debugging these issues. Also
send the scan code before the key code to match what other drivers do,
as some userspace utilities expect this ordering.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 needs to be
6AF4F258-B401-42FD-BE91-3D4AC2D7C0D3 to match the hardware alias.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Cc: stable@kernel.org

Most platform/x86 drivers that use INPUT_SPARSEKMAP also depend on INPUT,
so do the same for ideapad-laptop.  This fixes a kconfig warning and
subsequent build errors when CONFIG_INPUT is disabled.

warning: (ACER_WMI && ASUS_LAPTOP && DELL_WMI && HP_WMI && PANASONIC_LAPTOP && IDEAPAD_LAPTOP && EEEPC_LAPTOP && EEEPC_WMI && MSI_WMI && TOPSTAR_LAPTOP && ACPI_TOSHIBA) selects INPUT_SPARSEKMAP which has unmet direct dependencies (!S390 && INPUT)

ERROR: "input_free_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_register_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_setup" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_allocate_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_unregister_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_free" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_report_event" [drivers/platform/x86/ideapad-laptop.ko] undefined!
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: platform-driver-x86@vger.kernel.org
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to write to hardware registers.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to change ACPI settings.  The comment says that it
is done deliberatelly, however, the comment before disp_proc_write()
says that at least one of these setting is experimental.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to change WMI settings.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

There is no need to install a chained handler for this hardware. This
is a plain x86 IOAPIC interrupt which is handled by the core code
perfectly fine. There is nothing special about demultiplexing these
gpio interrupts which justifies a custom hack. Replace it by a plain
old interrupt handler installed with request_irq. That makes the code
agnostic about the underlying primary interrupt hardware. The overhead
for this is minimal, but it gives us the advantage of accounting,
balancing and to detect interrupt storms. gpio interrupts are not
really that performance critical.

Patch fixups from akpm
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>