mfd: cros_ec: spi: Calculate delay between transfers correctly

To avoid spamming the EC we calculate the time between the previous
transfer and the current transfer and force a delay if the time delta
is too small.

However, a small miscalculation causes the delay period to be
far too short. Most noticably this impacts commands with a long
turnaround time such as EC firmware reads and writes.

Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: cros_ec: spi: Add mutex to cros_ec_spi

The main transfer function for cros_ec_spi can be called by more than
one client at a time.  Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

The cros_ec_spi transfer had two problems with its timeout code:

1. It looked at the timeout even in the case that it found valid data.
2. If the cros_ec_spi code got switched out for a while, it's possible
   it could get a timeout after a single loop.  Let's be paranoid and
   make sure we do one last transfer after the timeout expires.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

We're adding i2c tunneling to the list of things that goes over
cros_ec.  i2c tunneling can be slooooooow, so increase our deadline to
100ms to account for that.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

This just updates include/linux/mfd/cros_ec_commands.h to match the
latest EC version (which is the One True Source for such things).  See
<https://chromium.googlesource.com/chromiumos/platform/ec>

[dianders: took today's ToT version from the Chromium OS EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]

Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
i2c: ChromeOS EC tunnel driver

On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main "Application Processor") and the EC (the Embedded
Controller).  These are:
* The battery (sbs-battery).
* The power management unit tps65090.

On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).

The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
  were caused by the EC, the AP, or some device on the bus).

On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
  longer on the bus used for AP/EC communication.  The battery was
  exposed to the AP through a limited i2c tunnel and tps65090 was
  exposed to the AP through a custom Linux driver.

On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.

The upstream "tegra124-venice2" uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.

This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: max14577: Cast to architecture agnostic data type

drivers/mfd/max14577.c:334:25:
  warning: cast from pointer to integer of different size
    max14577->dev_type = (unsigned int)of_id->data;
                         ^
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Correct addresses of always-on trigger registers

Update the addresses and names to match current silicon.
The WM8997 regmap tables have been adjusted to match the new
names.
Missing registers have been added to WM5110 default value table.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: abx500-core: Remove unused function abx500_dump_all_banks()

abx500_dump_all_banks() has no callers in the kernel, so it's probably
safe to remove it.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: palmas: Format the header file

Formats the palmas header file. Convert all
the offset values to hexadecimal.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: ti-keystone-devctrl: Add bindings for device state control

The Keystone II devices have a set of registers that are used to control
the status of its peripherals. This node is intended to allow access to
this functionality.

Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: db8500-prcmu: Remove check for CONFIG_DBX500_PRCMU_DEBUG

A check for CONFIG_DBX500_PRCMU_DEBUG was added in v3.6. But there's no
Kconfig symbol DBX500_PRCMU_DEBUG. So remove this check.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: tps65218: Terminate of match table

Failure to terminate this match table can lead to boot failures
depending on where the compiler places the match table.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: menelaus: Use module_i2c_driver

module_i2c_driver simplifies the code by eliminating
boilerplate code.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: wm5102: Correct default for LDO Control 2 register

Update the default value to match the patch.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
ARM: dts: am4372.dtsi: add DSS information

Add DT data for the display subsystem for AM4372. The DSS on AM4372 is
basically OMAP3's DSS, without DSI and VENC blocks.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
ARM: dts: am437x-gp-evm: add LCD data

Add DT data for am437x-gp-evm's LCD panel.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
ARM: dts: am43x-epos-evm: add LCD data

Add DT data for am43x-epos-evm's LCD panel.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
ARM: dts: omap5.dtsi: add DSS nodes

Add OMAP5 DSS nodes to omap5.dtsi.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
ARM: dts: omap5-uevm.dts: add tca6424a

omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>