clk: qcom: Add support for root clock generators (RCGs)

Add support for the root clock generators on Qualcomm devices.
RCGs are highly customizable mux/divider/counter clocks that can
be used to generate almost any rate desired given some input
source that is faster than the desired rate.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for branches/gate clocks

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add reset controller support

Reset controllers and clock controllers are combined into one IP
block on Qualcomm chipsets. Usually a reset signal is associated
with each clock branch but sometimes a reset signal is associated
with a handful of clocks. Either way the register interface is
the same; set a bit to assert a reset and clear a bit to deassert
a reset. Add support for these types of resets signals.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for MSM8960's global clock controller (GCC)

Add a driver for the global clock controller found on MSM8960
based platforms. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)

Add a driver for the multimedia clock controller found on MSM
8960 based platforms. This should allow multimedia device drivers
to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for MSM8974's global clock controller (GCC)

Add a driver for the global clock controller found on MSM 8974
based platforms. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC)

Add a driver for the global clock controller found on MSM 8974
based platforms. This should allow most multimedia device drivers
to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk: qcom: Add support for MSM8660's global clock controller (GCC)

Add a driver for the global clock controller found on MSM8660
based platforms. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
devicetree: bindings: Document qcom,gcc

Document the global clock controller found on Qualcomm devices.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
devicetree: bindings: Document qcom,mmcc

Document the multimedia clock controller found on Qualcomm devices

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
dts: bindings: trivial clock bindings doc fixes

fix a typo in the "clock specifiers" discussion,
clarify that clock specifiers (the integer cells
part that goes with the phandle) may be empty

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Rob Herring <robh@kernel.org>
devicetree: macb: Document clock properties

The macb driver uses the clock bindings. Document the required
properties, especially the driver specific clock-names.

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Rob Herring <robh@kernel.org>
x86, tsc, apic: Unbreak static (MSR) calibration when CONFIG_X86_LOCAL_APIC=n

If we aren't going to use the local APIC anyway, we obviously don't
care about its timer frequency.

Link: http://lkml.kernel.org/r/tip-rgm7xmg7k6qnjlw3ynkcjsmh@git.kernel.org
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Bin Gao <bin.gao@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Merge tag 'davinci-for-v3.14/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/dt

From Sekhar Nori:
DaVinci device tree file updates to add GPIO
support.

* tag 'davinci-for-v3.14/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: davinci: da850 evm: add GPIO pinumux entries DT node
  ARM: davinci: da850: add GPIO DT node

Signed-off-by: Kevin Hilman <khilman@linaro.org>
HID: sony: Add force-feedback support for the Dualshock 4

Adds the Dualshock 4 to the HID device list and enables force-feedback.

Adds a Dualshock 4 specific worker function since the Dualshock 4 needs a
different report than the Sixaxis.

The right motor in the Dualshock 4 is variable so the full rumble value
is now passed to the worker function and clamped there if necessary.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Add LED controls for the Dualshock 4

Add LED lightbar controls for the Dualshock 4.

The Dualshock 4 light bar has 3 separate RGB LEDs that can range in
brightness from 0 to 255 so a full byte is now needed to store each LED's
state

Changed the module to support an arbitrary number of LEDs instead of being
hardcoded to 4.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Rename worker function

Rename sony_state_worker to sixaxis_state_worker since the function is now
sixaxis specific.

Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Merge tag 'davinci-for-v3.14/soc' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/soc

From Sekhar Nori:
A patch to fix the return value of clk_round_rate()

* tag 'davinci-for-v3.14/soc' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: davinci: clock: return 0 upon error from clk_round_rate()
HID: logitech-dj: Fix USB 3.0 issue

This fix (not very clean though) should fix the long time USB3
issue that was spotted last year. The rational has been given by
Hans de Goede:

 ----

I think the most likely cause for this is a firmware bug
in the unifying receiver, likely a race condition.

The most prominent difference between having a USB-2 device
plugged into an EHCI (so USB-2 only) port versus an XHCI
port will be inter packet timing. Specifically if you
send packets (ie hid reports) one at a time, then with
the EHCI controller their will be a significant pause
between them, where with XHCI they will be very close
together in time.

The reason for this is the difference in EHCI / XHCI
controller OS <-> driver interfaces.

For non periodic endpoints (control, bulk) the EHCI uses a
circular linked-list of commands in dma-memory, which it
follows to execute commands, if the list is empty, it
will go into an idle state and re-check periodically.

The XHCI uses a ring of commands per endpoint, and if the OS
places anything new on the ring it will do an ioport write,
waking up the XHCI making it send the new packet immediately.

For periodic transfers (isoc, interrupt) the delay between
packets when sending one at a time (rather then queuing them
up) will be even larger, because they need to be inserted into
the EHCI schedule 2 ms in the future so the OS driver can be
sure that the EHCI driver does not try to start executing the
time slot in question before the insertion has completed.

So a possible fix may be to insert a delay between packets
being send to the receiver.

 ----

I tested this on a buggy Haswell USB 3.0 motherboard, and I always
get the notification after adding the msleep.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: hid-sensor-hub: Fix buggy report descriptors

This addresses regression caused by commit id "751d17e23a9f7"
 iio: hid-sensors: Fix power and report state.
This commit removed a quirk, to change the enumeration base
to 1 from 0 based on an CONFIG paramter. There was objection to
add more changes under this quirk, instead suggested to add an
HID quirk. But there is no easy way to add HID qurik as the
reports are not properly using collection class.

The solution was to use logical minimum, which is a correct way.
There were changes done in firmware to address this.

Unfortunately some devices, still use old FW and can't be upgraded
to newer version on Linux devices as there is no FW upgrade tool
available for Linux devices. So we need to fix report descriptors,
for such devices. This will not have any impact, if the FW uses
logical 1 as minimum.

In this patch we look for usage id for "power and report state", and
modify logical minimum value to 1.

Background on enum:
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>