drm/i915: enable HiZ Raw Stall Optimization

backported to SteamOS kernel branch.

The optimization is available on Ivy Bridge and later, and is disabled by
default.  Enabling it helps certain workloads such as GLBenchmark TRex test.

Signed-off-by: Chia-I Wu <olv at lunarg.com>
Cc: Ian Romanick <ian.d.romanick at intel.com>
Cc: Chad Versace <chad.versace at linux.intel.com>
HID: Bluetooth: hidp: register HID devices async

While l2cap_user callbacks are running, the whole hci_dev is locked. Even
if we would add more fine-grained locking to HCI core, it would still be
called from the non-reentrant rx work-queue and thus block the event
processing.

However, if we want to perform synchronous I/O during HID device
registration (eg., to perform device-detection), we need the HCI core
to be able to dispatch incoming data.

Therefore, we now move device-registration to a separate worker. The HCI
core can continue running and we add devices asynchronously in another
kernel thread. Device removal is synchronized and waits for the worker
to exit before calling the usual device removal functions.

If l2cap_user->remove is called before the thread registered the devices,
we set "terminate" to true and the thread will skip it. If
l2cap_user->remove is called after it, we notice this as the device
is no longer in HIDP_SESSION_PREPARING state and simply unregister the
device as we did before.
There is no new deadlock as we now call hidp_session_add_dev() with
one lock less held (the HCI lock) and it cannot itself call back into
HCI as it was called with the HCI-lock held before.

One might wonder whether this can block during device unregistration.
But we set "terminate" to true and wake the HIDP thread up _before_
unregistering the HID/input devices. Therefore, all pending HID I/O
operations are canceled. All further I/O attempts will fail with ENODEV
or EIO. So all latency we can get are few context-switches, but no
timeouts or blocking I/O waits!

This change also prepares for a long standing HID bug. All HID devices
that register power_supply devices need to be able to handle callbacks
during registration (a power_supply oddity that cannot easily be fixed).
So with this patch available, we can allow HID I/O during registration
by calling the recently introduced hid_device_io_start/stop helpers,
which currently are a no-op for bluetooth due to this locking.

Note that we cannot do the same for input devices. input-core doesn't
allow us to call input_event() asynchronously to input_register_device(),
which HID-core kindly allows (for good reasons).
Fixing input-core to allow this isn't as easy as it sounds and is,
beside simplifying HIDP, not really an improvement. Hence, we still
register input devices synchronously as we did before. Only HID devices
are registered asynchronously.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Daniel Nicoletti <dantti12@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Backport support for the Sony Sixaxis and DualShock 4 controllers.

This backports support for force-feedback on both the Sixaxis and
DualShock 4, full LED support for both controllers, battery reporting for
both controllers and touchpad support on the DS4.  All features are
functional under both USB and Bluetooth.

Additionally, this adds a workaround to stop the Sixaxis from blinking
after the PS button is pushed when connected via USB and it uses the same
trick as the xpad driver to set the default LED values using the joystick
device number.

Note that the DualShock 4 needs BlueZ 5.14 or newer to pair correctly.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Workaround for sending reports to the Sixaxis and DualShock 4.

The Sixaxis and DualShock 4 want output reports sent on the control
channel when running on Bluetooth, so a special case is needed for them.

This is a bit of an ugly hack, but it gets the job done without needing to
backport the rather extensive HID system changes in newer kernels that are
needed to make these controllers function via Bluetooth.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Correct DualShock 4 HID descriptors

 -A 6 bit value had a logical maximum of 255 when the largest it can be is 63.
 -Correct a logical max value that should be 255 instead of -1.
 -Clamp the gyroscope values to -8192/8191 as these are the largest true
  orientation values.  Anything larger or smaller is just noise.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Correct DualShock 4 HID descriptors

 -A 6 bit value had a logical maximum of 255 when the largest it can be is 63.
 -Correct a logical max value that should be 255 instead of -1.
 -Clamp the gyroscope values to -8192/8191 as these are the largest true
  orientation values.  Anything larger or smaller is just noise.
 -Correct an outdated comment block.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Merge branch 'alchemist-3.10' of github.com:ArtVandelae/steamos_kernel into alchemist-3.10
Merge pull request #6 from ArtVandelae/alchemist-3.10

Backport support for the DualShock 3 and 4 controllers.
Merge pull request #4 from LunarG/enable-HiZ-on-Haswell

drm/i915: enable HiZ Raw Stall Optimization
Revert "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled"

This reverts commit 2b1461bbae34fc229cb5f58e5980aa32ee09ee77.

Revert "ALSA: hda - hdmi: introduce patch_nvhdmi()"

This reverts commit c6a3cab88784e5d6d97ef57061b8fa75a4b67726.
hid: sony: Copy the initial LED state to the sony_sc struct

The LEDs aren't set on the Sixaxis on USB until the PS button is pushed, but
the initial_values array still needs to be copied to the sony_sc struct so
they can be set properly when that happens.
hid: sony: Set the DualShock 4 touchpad bits in the input_configured callback

Set the DualShock4 touchpad bits in the input_configured callback
so that they are registered properly for any input devices created
during hid_hw_start.

Fixes an issue where the touch axes would wrongly be mapped to axis 0 in the
joystick device.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Merge pull request #7 from ArtVandelae/alchemist-3.10

Fix DualShock 3 LEDs and incorrect mapping of touch axes
Input: xpad - add support for Xbox One controllers

Xbox One controllers require an initialization message to start sending
data, so xpad_init_output becomes a required function. The Xbox One
controller does not have LEDs like the Xbox 360 controller, so that
functionality is not implemented. The format of messages controlling rumble
is currently undocumented, so rumble support is not yet implemented.

Note that Xbox One controller advertises three interfaces with the same
interface class, subclass and protocol, so we have to also match against
interface number.

Signed-off-by: Ted Mielczarek <ted@mielczarek.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add force feedback support for Xbox One controllers.

There's apparently a serial number woven into both input and output packets;
neglecting to specify a valid serial number causes the controller to ignore
the rumble packets.

The scale of the rumble was also apparently halved in the packets.

The initialization packet had to be changed to allow force feedback to work.
Set fast sample_c: bit 9 of HALF_SLICE_CHICKEN3