Merge tag 'vmwgfx-next-2014-03-28' of git://people.freedesktop.org/~thomash/linux into drm-next

vmwgfx render-node support and drm + ttm changes it depends upon.

Pull request of 2014-03-28

* tag 'vmwgfx-next-2014-03-28' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Bump driver minor and date
  drm/vmwgfx: Enable render nodes
  drm/vmwgfx: Tighten the security around buffer maps
  drm/ttm: Add a ttm_ref_object_exists function
  drm/vmwgfx: Tighten security around surface sharing v2
  drm/vmwgfx: Allow prime fds in the surface reference ioctls
  drm/vmwgfx: Drop authentication requirement on UNREF ioctls
  drm/vmwgfx: Reinstate and tighten security around legacy master model
  drm/vmwgfx: Use a per-device semaphore for reservation protection
  drm: Add a function to get the ioctl flags
  drm: Protect the master management with a drm_device::master_mutex v3
  drm: Remove the minor master list
  drm: Improve on minor type helpers v3
  drm: Make control nodes master-less v3
  drm: Break out ioctl permission check to a separate function v2
  drm: Have the crtc code only reference master from legacy nodes v2
Use 'E' instead of 'X' for unsigned module taint flag.

Takashi Iwai <tiwai@suse.de> says:
> The letter 'X' has been already used for SUSE kernels for very long
> time, to indicate the external supported modules.  Can the new flag be
> changed to another letter for avoiding conflict...?
> (BTW, we also use 'N' for "no support", too.)

Note: this code should be cleaned up, so we don't have such maps in
three places!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Input: add driver for SOC button array

This patch adds support for the GPIO buttons on some Intel Bay Trail
tablets originally running Windows 8. The ACPI description of these
buttons follows "Windows ACPI Design Guide for SoC Platforms".

Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: appletouch - implement sensor data smoothing

Use smoothed version of sensor array data to calculate movement and add
weight to prior values when calculating average. This gives more granular
and more predictable movement.

Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: appletouch - fix jumps when additional fingers are detected

Addresses issues related to when a second finger enters or leaves the
field, causing the cursor to jump or the page to scroll unexpectedly; now,
we discard any movement change that happens at the exact moment we detect a
change in the number of fingers touching the trackpad. This doesn't
completely resolve the issue but does greatly mitigate it.

Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge tag 'v3.14' into drm-intel-next-queued

Linux 3.14

The vt-d w/a merged late in 3.14-rc needs a bit of fine-tuning, hence
backmerge.

Conflicts:
	drivers/gpu/drm/i915/i915_gem_gtt.c
	drivers/gpu/drm/i915/intel_ddi.c
	drivers/gpu/drm/i915/intel_dp.c

All trivial adjacent lines changed type conflicts, so trivial git
doesn't even show them in the merg commit.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: restrict vt-d stolen memory workaround to pre-gen8

We want future generations to at least attempt to use all features, so
restrict the stolen memory disabling when vt-d is enabled to the
latest generation we have reports for. Which is a HSW per the original
report.

Also once we get a bit a hold of some of the mysterious framebuffer in
stolen memory issues that still haunt bugzilla, we should probably
drop this hack again and see what happens.

This was introduced in

commit 0f4706d2740f2a221cd502922b22e522009041d9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 18 14:50:50 2014 +0200

    drm/i915: Disable stolen memory when DMAR is active

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/vlv: use W_SYNC_SHIFT for interlaced modes on VLV

This makes HDMI testers happier on VLV platforms.  It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.

Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>"
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Program VSYNCSHIFT in a more consistent manner

When interlaced sdvo output is used, vsyncshift should supposedly
be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by
using the legacy vsyncshift interlace mode which causes the hardware
to ignore the VSYNCSHIFT register.

The only odd thing here is that on PCH platforms we program the
VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both
sides have to agree on the value or not. On the CPU side there's no
way to override the value via PIPECONF anymore, so if we want to make
the CPU side agree with the PCH side, we should probably program the
approriate value into VSYNCSHIFT manually. So let's do that, but for
now leave the PCH side to still use the legacy interlace mode in
TRANSCONF.

We can also drop the gen2 check since gen2 doesn't support interlaced
modes at all.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Fix the interlace mode selection for gmch platforms

PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo
since it implies a slightly weird vsync shift of htotal/2. For everything
else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in
the VSYNCSHIFT register take effect.

The only exception is gen3 simply because VSYNCSHIFT didn't exist yet.
Gen2 doesn't support interlaced modes at all, so we can drop the
explicit gen2 checks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Make sure vsyncshift is positive

If vsyncshift comes out as negative, add one htotal to it to get the
corresponding positive value.

This is rather theoretical as it would require a mode where the
hsync+back porch is very long and the active+front porch very short.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."

This reverts commit 2754436913b94626a5414d82f0996489628c513d.

Conflicts:
	drivers/gpu/drm/i915/i915_irq.c

The partial application of interrupt masking without regard to other
pathways for adjusting the RPS frequency results in completely disabling
the PM interrupts. This leads to excessive power consumption as the GPU
is kept at max clocks (until the failsafe mechanism fires of explicitly
downclocking the GPU when all requests are idle). Or equally as bad for
the UX, the GPU is kept at minimum clocks and prevented from upclocking
in response to a requirement for more power.

Testcase: pm_rps/blocking
Cc: Deepak S <deepak.s@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Refactor gen6_set_rps

What used to be a short-circuit now needs to adjust interrupt masking in
response to user requests for changing the min/max allowed frequencies.
This is currently done by a special case and early return, but the next
patch adds another common action to take, so refactor the code to reduce
duplication.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Mask PM/RPS interrupt generation based on activity

The speculation is that we can conserve more power by masking off
the interrupts at source (PMINTRMSK) rather than filtering them by the
up/down thresholds (RPINTLIM). We can select which events we know will
be active based on the current frequency versus our imposed range, i.e.
if at minimum, we know we will not want to generate any more
down-interrupts and vice versa.

v2: We only need the TIMEOUT when above min frequency.
v3: Tweak VLV at the same time

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Deepak S <deepak.s@linux.intel.com>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GFS2: Fix return value in slot_get()

ENOSPC was being returned in slot_get inspite of successful
execution of the function. This patch fixes this return
code.

Signed-off-by: Abhi Das <adas@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Revert "[media] em28xx-dvb: fix PCTV 461e tuner I2C binding"

The first hunk of this patch got merged wrong, likely due to some
changes at the em28xx resume code. Revert it to reapply it right.

This reverts commit 37571b163c15831cd0a213151c21387363dbf15b.

Reported-by: Chris Lee <updatelee@gmail.com>
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Cc: stable@vger.kernel.org # Don't apply this patch or 37571b163c15
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] em28xx-dvb: fix PCTV 461e tuner I2C binding

Add missing m88ts2022 module reference counts as removing that module
is not allowed when it is used by em28xx-dvb module. That same module
was not unregistered correctly, fix it too.

Error cases validated by returning errors from m88ds3103, m88ts2022
and a8293 probe().

Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
MAINTAINERS: update entry for fs/locks.c

Both Bruce and I have done a fair bit of work in these files recently,
and would like to be notified if anyone is proposing changes to it.

Also, Matthew is no longer interested in maintaining this code, so
remove him.

Cc: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
locks: close potential race between setlease and open

As Al Viro points out, there is an unlikely, but possible race between
opening a file and setting a lease on it. generic_add_lease is done with
the i_lock held, but the inode->i_flock check in break_lease is
lockless. It's possible for another task doing an open to do the entire
pathwalk and call break_lease between the point where generic_add_lease
checks for a conflicting open and adds the lease to the list. If this
occurs, we can end up with a lease set on the file with a conflicting
open.

To guard against that, check again for a conflicting open after adding
the lease to the i_flock list. If the above race occurs, then we can
simply unwind the lease setting and return -EAGAIN.

Because we take dentry references and acquire write access on the file
before calling break_lease, we know that if the i_flock list is empty
when the open caller goes to check it then the necessary refcounts have
already been incremented. Thus the additional check for a conflicting
open will see that there is one and the setlease call will fail.

Cc: Bruce Fields <bfields@fieldses.org>
Cc: David Howells <dhowells@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@fieldses.org>
locks: clean up comment typo

Acked-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>