CHROMIUM: hid: quickstep: Initial add of driver

The ChomeOS Touch team uses a usb device built in-house to measure the
drag latency on touchpads.  This device communicates with the OS over
USB using a custom driver.  This CL adds that driver so that by default
Chromebooks will have the driver ready.  Previously, the kernel had to
be rebuilt for every device we wanted to test every time, so it will
save a lot of time on our end to already have it in there.

The device (named Quickstep) consists of a laser that lays across the
touchpad and hits a phototransistor on the other side.  The device
reports over USB HIDRAW a 1 or a 0 immediates each time the laser is
broken/unbroken by a finger inbetween the sensor and the laser.  This
driver simply listens for these events and records the time at which
they occur.  These events are stored in memory and can be accessed via
sysfs entries for later analysis by the latency-measuring scripts.

BUG=chromium:328451
TEST=Rebuilt kernel and used with the device.  Was able to access its
sysfs entries to both collect data and clear the logs.

Change-Id: I649c8625275bbdd68a301b96461c7b57c8f7ac8f
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179963
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: iwl7000: sort and extend element ID list

The element ID list is currently almost sorted by amendment
or similar topic, but the order is difficult to maintain and
not very transparent. Sort the list by ID instead, and add
a lot of missing IDs.

Change-Id: Ic4f6c4d832105dcbff0d0fadfc99d901b8ccffd0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184787
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in probe request correctly

In probe request frames, the VHT IEs should come before any
vendor IEs, but after interworking and similar, so add code
to order them correctly wrt. the IEs passed from userspace.

Change-Id: Ic40e60a74e20f36331cf60a168fb4610d5e4ffbf
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184788
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in association request correctly

In association request frames, there may be IEs passed from
userspace (such as interworking IEs) between HT and VHT, so
add code to insert those inbetween them.

Change-Id: I9dac0fae8e5c7ead0c290fcacb8937f35266a419
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184789
Reviewed-by: Paul Stewart <pstew@chromium.org>
mmc: dw_mmc: change to use recommended reset procedure

This changes the fifo reset code to follow the reset procedure
outlined in the documentation that we have.  It seems to help with
hangs seen during eMMC tuning.

BUG=chrome-os-partner:22839
TEST=booted on pit, rebooted machine over 100 time and no hangs seen.
     /wo this patch machine use to hangs once in 10~15 reboot cycles.

Change-Id: I1ec0cfcebe3a7787923ef504fe2e7d1ba37340fd
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178420
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: arm: dts: peach-pit: enable HS200

This enables HS200 using the upstream capability.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

BUG=chrome-os-partner:22839
TEST=`cat /sys/kernel/debug/mmc0/ios` shows clock at 200Mhz

Change-Id: I0e674297244c3e988c48673bc762d9f8de9880e3
Reviewed-on: https://chromium-review.googlesource.com/173534
Reviewed-by: Grant Grundler <grundler@chromium.org>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: ARM: exynos: Add pmu dts nodes for Exynos 542x

This adds two pmu nodes to the exynos542x.dtsi because the two types
of cores unfortunately have different interrupt parents. This is just a
first step in getting performance counters to work properly on 5420
with IKS.  There still needs to be work done to support the mulitple
pmu nodes and then context switch the counters properly in the
switcher code.

BUG=chrome-os-partner:22742
TEST="for i in $(seq 0 3) ;
	  do echo 700000 > \
	  /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_min_freq;
	  perf top works"

Change-Id: I720bf655a527e8e9e67608dd136c9cbd9aa1f6ef
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180635
Reviewed-by: Olof Johansson <olofj@chromium.org>
BACKPORT: fence: dma-buf cross-device synchronization (v17)

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

When emitting a fence, call:
  + trace_fence_emit()

To annotate that a fence is blocking on another fence, call:
  + trace_fence_annotate_wait_on(fence, on_fence)

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
    dma_buf *fence_buf = seqno_fence->sync_buf;
    get_dma_buf(fence_buf);

    ... tell the hw the memory location to wait ...
    custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
  } else {
    /* fall-back to sw sync * /
    fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
    that dma-fence didn't need to care about the sw->hw signaling path
    (it can be handled same as sw->sw case), and therefore the fence->ops
    can be simplified and more handled in the core.  So remove the signal,
    add_callback, cancel_callback, and wait ops, and replace with a simple
    enable_signaling() op which can be used to inform a fence supporting
    hw->hw signaling that one or more devices which do not support hw
    signaling are waiting (and therefore it should enable an irq or do
    whatever is necessary in order that the CPU is notified when the
    fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
    we decided that we need to be able to attach one fence to N dma-buf's,
    so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
    about checking if fence fired or not. This is broken by design.
    waitqueue_active during destruction is now fatal, since the signaller
    should be holding a reference in enable_signalling until it signalled
    the fence. Pass the original dma_fence_cb along, and call __remove_wait
    in the dma_fence_callback handler, so that no cleanup needs to be
    performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
    fence wasn't signaled yet, for example for hardware fences that may
    choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
    header and fixed include mess. dma-fence.h now includes dma-buf.h
    All members are now initialized, so kmalloc can be used for
    allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
    enable_signaling to bool. Rework dma_fence_wait. Added
    dma_fence_is_signaled and dma_fence_wait_timeout.
    s/dma// and change exports to non GPL. Added fence_is_signaled and
    fence_enable_sw_signaling calls, add ability to override default
    wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
    scheduler. Remove fence lock and use a global spinlock instead,
    this should hopefully remove all the locking headaches I was having
    on trying to implement this. enable_signaling is called with this
    lock held.
v11:
    Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
    However I kept the guarantee that after fence_signal returns, it is
    guaranteed that enable_signaling has either been called to completion,
    or will not be called any more.

    Add contexts and seqno to base fence implementation. This allows you
    to wait for less fences, by testing for seqno + signaled, and then only
    wait on the later fence.

    Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
    An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
    spam, and another runtime option can turn it off at runtime.
v12:
    Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
    and fence->seqno members.
v13:
    Fixup CONFIG_FENCE_TRACE kconfig description.
    Move fence_context_alloc to fence.
    Simplify fence_later.
    Kill priv member to fence_cb.
v14:
    Remove priv argument from fence_add_callback, oops!
v15:
    Remove priv from documentation.
    Explicitly include linux/atomic.h.
v16:
    Add trace events.
    Import changes required by android syncpoints.
v17:
    Use wake_up_state instead of try_to_wake_up. (Colin Cross)
    Fix up commit description for seqno_fence. (Rob Clark)

BUG=chromium:340541
TEST=builds and runs on link (doesn't change the behaviour of anything for now)

Change-Id: Ib3f25d4c4cfc4445c668155285687a8a77a528b2
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184965
Reviewed-by: Sean Paul <seanpaul@chromium.org>
ASoC: max98090: Claim max98091 support

The max98091 is the same as the 98090 but with an extra microphone.
The max98090 driver already has support for the max98091.  This just
allows us to use the proper compatible string in the device tree.

BUG=chrome-os-partner:24838
TEST=With all changes pit and pi work for:
- youtube (speakers and headphones)
- aplay (speakers and headphones)
- google voice search w/ builtin mic

Change-Id: I4da4b1eeaab4f5dfc588aa41b36123fc9d2f7819
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184091
ASoC: samsung: Add max98091 to daisy_max98095.c

The max98091 is the same as the 98090 but with an extra microphone.

This change considers 98091 as 98090 which is driver for both of 98090
and 98091 so that we use represented name max98091 in device tree.

BUG=chrome-os-partner:24838
TEST=With all changes pit and pi work for:
- youtube (speakers and headphones)
- aplay (speakers and headphones)
- google voice search w/ builtin mic

Change-Id: I36d0a399a10fbcdb503ade75162789a6693adecc
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183923
ARM: dts: Represent each audio device name for peach

The max98091 is the same as the 98090 but with an extra microphone.
this change represent every device audio device name of own board

BUG=chrome-os-partner:24838
TEST=With all changes pit and pi work for:
- youtube (speakers and headphones)
- aplay (speakers and headphones)
- google voice search w/ builtin mic

Change-Id: Ic8e2678a08a6cde08f6d75b5373c363e5f15bebd
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183924
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
UPSTREAM: ARM: add get_user() support for 8 byte types

A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).

v1: original
v2: pass correct size to check_uaccess, and better handling of narrowing
    double word read with __get_user_xb() (Russell King's suggestion)

Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
[seanpaul picked up version revised by rmk from http://lists.freedesktop.org/archives/dri-devel/2013-October/046668.html]
Signed-off-by: Sean Paul <seanpaul@chromium.org>

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Change-Id: Id57e9902131de9238bddcb7799ff6528526514c7
Reviewed-on: https://chromium-review.googlesource.com/184834
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm: review locking rules in drm_crtc.c

- config_cleanup was confused: It claimed that callers need to hold
  the modeset lock, but the connector|encoder_cleanup helpers grabbed
  that themselves (note that crtc_cleanup did _not_ grab the modeset
  lock). Which resulted in all drivers _not_ hodling the lock. Since
  this is for single-threaded cleanup code, drop the requirement from
  docs and also drop the lock_grabbing from all _cleanup functions.

- Kill the LOCKING section in the doctype, since clearly we're not
  good enough to keep them up-to-date. And misleading locking
  documentation is worse than useless (see e.g. the comment in the
  vmgfx driver about the cleanup mess). And since for most functions
  the very first line either grabs the lock or has a WARN_ON(!locked)
  the documentation doesn't really add anything.

- Instead put in some effort into explaining the only two special
  cases a bit better: config_init and config_cleanup are both called
  from single-threaded setup/teardown code, so don't do any locking.
  It's the driver's job though to enforce this.

- Where lacking, add a WARN_ON(!is_locked). Not many places though,
  since locking around fbdev setup/teardown is through-roughly screwed
  up, and so will break almost every single WARN annotation I've tried
  to add.

- Add a drm_modeset_is_locked helper - the Grate Modset Locking Rework
  will use the compiler to assist in the big reorg by renaming the
  mode lock, so start encapsulating things. Unfortunately this ended
  up in the "wrong" header file since it needs the definition of
  struct drm_device.

v2: Drop most WARNS again - we hit them all over the place, mostly in
the setup and teardown sequences. And trying to fix it up leads to
nice deadlocks, since the locking in the setup code is really
inconsistent.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 8faf6b18a2a6bece008de1e6bb80f0c608e58483)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: I2db8e9d928b62c8d73658a9d59d2d046d3a0f476
Reviewed-on: https://chromium-review.googlesource.com/184835
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/doc: integrate drm_crtc.c kerneldoc

And do a quick pass to adjust them to the last few (years?) of changes
...

This time actually compile-tested ;-)

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 065a50ed3ef75cb265e12e3e1b615db0835150bc)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: Iffdf4cfd6b78af6d97f9e92e62e6c6e2415d6b71
Reviewed-on: https://chromium-review.googlesource.com/184836
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/<drivers>: reorder framebuffer init sequence

With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.

This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.

- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
  cases didn't cleanup the framebuffer, which is now moot since
  the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
  break anything (but it's refcount management only, so should be safe).

v2: Split out exynos, since it's a bit more hairy than expected.

v3: Drop bogus cirrus hunk noticed by Richard Wilbur.

v4: Split out vmwgfx since there's a small change in return values.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit c7d73f6a8ad71f9d9f58c86981322c6e48093a4f)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: I0f4ae659f66869f08b50b5df054a41c7161313f2
Reviewed-on: https://chromium-review.googlesource.com/184837
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/vmwgfx: reorder framebuffer init sequence

vmwgfx has an oddity, when failing to reference the surface it'll
return 0, since that's what the successfull drm_framebuffer_init will
leave behind in ret. Fix this up by returning -EINVAL.

Split out from all the other driver updates due to the above tiny
semantic change. Shouldn't matter though since the reference grabbing
seemingly can't fail.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 80f0b5aff8f49f63eaf08bdae243de3a8ea3f77e)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: Id8e830655c46b4eb8ff6e79e47c2c7d966087089
Reviewed-on: https://chromium-review.googlesource.com/184838
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/gma500: move fbcon restore to lastclose

Doing this within the fb->destroy callback leads to a locking
nightmare. And all other drm drivers that restore the fbcon do
it in lastclose, too.

With this adjustments all fb->destroy callbacks optionally drop
references to any gem objects used as backing storage, call
drm_framebuffer_cleanup and then kfree the struct. Which nicely
simplifies the locking for framebuffer unreferencing and freeing,
since this doesn't require that we hold the mode_config lock. A
slight exception is the vmwgfx surface backed framebuffer, it also
calls drm_master_put and removes the object from a device-private
framebuffer list. Both seem to have solid locking in place already.

Conclusion is that now it is no longer required to hold the
mode_config lock while freeing a framebuffer.

v2: Drop the corresponding mutex_lock WARN check from
drm_framebuffer_unreference.

v3: Use just the mode_config lock not modeset_lock_all, due to patch
reordering.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 7147573a5ce499dec3979e6b524691d47e1288d5)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: If961d40dc0f8614bbbb4114af2f23043e18e906a
Reviewed-on: https://chromium-review.googlesource.com/184839
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex

With per-crtc locks modeset operations can run in parallel, and the
cursor code uses the device-global evo master channel for hw frobbing.
But the pageflip code can also sync with the master under some
circumstances. Hence just wrap things up in a mutex to ensure that
pushbuf access doesn't intermingle.

The approach here is a bit overkill since the per-crtc channels used
to schedule the pageflips could probably be used without this pushbuf
locking, but I'm not familiar enough with the nouveau codebase to be
sure of that.

v2: Add missing mutex_init to avoid angering lockdep.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 59ad1465423d968f06f243bc52cc3b1a320a27cf)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: I8d60e83fde7b9532eb6679247aac7fb31618e5bf
Reviewed-on: https://chromium-review.googlesource.com/184860
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/nouveau: try to protect nbo->pin_refcount

... by moving the bo_pin/bo_unpin manipulation of the pin_refcount
under the protection of the ttm reservation lock. pin/unpin seems
to get called from all over the place, so atm this is completely racy.

After this patch there are only a few places in cleanup functions
left which access ->pin_refcount without locking. But I'm hoping that
those are safe and some other code invariant guarantees that this
won't blow up.

In any case, I only need to fix up pin/unpin to make ->pageflip work
safely, so let's keep it at that.

Add a comment to the header to explain the new locking rule.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0ae6d7bc0e70dafc1739d50b2b8d9d7c61968395)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: I4657055ecc92917c57e97dd1313abf1e4f4ede3b
Reviewed-on: https://chromium-review.googlesource.com/184861
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>
UPSTREAM: drm/<drivers>: Unified handling of unimplemented fb->create_handle

Some drivers don't have real ->create_handle callbacks.

- cirrus/ast/mga200: Returns either 0 or -EINVAL.

- udl: Didn't even bother with a callback, leading to a nice
  userspace-triggerable OOPS.

- vmwgfx: This driver bothered with an implementation to return 0 as
  the handle (which is the canonical no-obj gem handle).

All have in common that ->create_handle doesn't really make too much
sense for them - that ioctl is used only for seamless fb takeover in
the radeon/nouveau/i915 ddx drivers. So allow drivers to not implement
this and return a consistent -ENODEV.

BUG=chromium:336809
TEST=Tested on pit, no regressions noted

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit af26ef3b3978349cfbd864163a6ebb4906b733b5)
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Change-Id: I70743cdfc00af74f7dabb53ab309c042edbf6944
Reviewed-on: https://chromium-review.googlesource.com/184862
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Sean Paul <seanpaul@chromium.org>