This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case the change is trivial and the only
reason to do it is because we want to make cros_ec_cmd_xfer() a private
function for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: NPrashant Malani <pmalani@chromium.org>

RO and RW of EC may have different EC protocol version. If EC transitions
between RO and RW, but AP does not reboot (this is true for fingerprint
microcontroller / cros_fp, but not true for main ec / cros_ec), the AP
still uses the protocol version queried before transition, which can
cause problems. In the case of fingerprint microcontroller, this causes
AP to send the wrong version of EC_CMD_GET_NEXT_EVENT to RO in the
interrupt handler, which in turn prevents RO to clear the interrupt
line to AP, in an infinite loop.

Once an EC_HOST_EVENT_INTERFACE_READY is received, we know that there
might have been a transition between RO and RW, so re-query the protocol.
Signed-off-by: NYicheng Li <yichengli@chromium.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

The 'cros_ec' core driver is the common interface for the cros_ec
transport drivers to do the shared operations to register, unregister,
suspend, resume and handle_event. The interface is provided by including
the header 'include/linux/platform_data/cros_ec_proto.h', however, instead
of have the implementation of these functions in cros_ec_proto.c, it is in
'cros_ec.c', which is a different kernel module. Apart from being a bad
practice, this can induce confusions allowing the users of the cros_ec
protocol to call these functions.

The register, unregister, suspend, resume and handle_event functions
*should* only be called by the different transport drivers (i2c, spi, lpc,
etc.), so make this a bit less confusing by moving these functions from
the public in-kernel space to a private include in platform/chrome, and
then, the interface for cros_ec module and for the cros_ec_proto module is
clean.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>

This include isn't used. Remove it.
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

The ChromeOS EC has support for signaling to the host that a single IRQ
can serve multiple MKBP (Matrix KeyBoard Protocol) events.

Doing this serves an optimization purpose, as it minimizes the number of
round-trips into the interrupt handling machinery, and it proves
beneficial to sensor timestamping as it keeps the desired synchronization
of event times between the two processors.

This patch adds kernel support for this EC feature, allowing the ec_irq
to loop until all events have been served.
Signed-off-by: NEnrico Granata <egranata@chromium.org>
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

Add a layer of sanity checking to cros_ec_register against attempting to
register IRQ values that are not strictly greater than 0.
Signed-off-by: NEnrico Granata <egranata@chromium.org>
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

To improve sensor timestamp precision, given EC and AP are in different
time domains, the AP needs to try to record the exact moment an event
was signalled to the AP by the EC as soon as possible after it happens.

First thing in the hard irq is the best place for this.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Acked-by: NJonathan Cameron <Jonathan.Cameron@kernel.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

To avoid doc rot, put function documentations with code, not header.
Use kernel-doc style comments for exported functions.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

There is a bit of mess between cros-ec mfd includes and platform
includes. For example, we have a linux/mfd/cros_ec.h include that
exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
we have a linux/mfd/cros_ec_commands.h file that is non related to the
multifunction device (in the sense that is not exporting any function of
the mfd device). This causes crossed includes between mfd and
platform/chrome subsystems and makes the code difficult to read, apart
from creating 'curious' situations where a platform/chrome driver includes
a linux/mfd/cros_ec.h file just to get the exported functions that are
implemented in another platform/chrome driver.

In order to have a better separation on what the cros-ec multifunction
driver does and what the cros-ec core provides move and rework the
affected includes doing:

 - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
 - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c
   driver from include/linux/mfd/cros_ec.h to a new file
   include/linux/platform_data/cros_ec_proto.h
 - Update all the drivers with the new includes, so
   - Drivers that only need to know about the protocol include
     - linux/platform_data/cros_ec_proto.h
     - linux/platform_data/cros_ec_commands.h
   - Drivers that need to know about the cros-ec mfd device also include
     - linux/mfd/cros_ec.h
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: NChanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Series changes: 3
- Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp)
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrome subsystem.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NThierry Reding <thierry.reding@gmail.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: NChanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

An MFD is a device that contains several sub-devices (cells). For instance,
the ChromeOS EC fits in this description as usually contains a charger and
can have other devices with different functions like a Real-Time Clock,
an Audio codec, a Real-Time Clock, ...

If you look at the driver, though, we're doing something odd. We have
two MFD cros-ec drivers where one of them (cros-ec-core) instantiates
another MFD driver as sub-driver (cros-ec-dev), and the latest
instantiates the different sub-devices (Real-Time Clock, Audio codec,
etc).

                  MFD
------------------------------------------
   cros-ec-core
       |___ mfd-cellA (cros-ec-dev)
       |       |__ mfd-cell0
       |       |__ mfd-cell1
       |       |__ ...
       |
       |___ mfd-cellB (cros-ec-dev)
               |__ mfd-cell0
               |__ mfd-cell1
               |__ ...

The problem that was trying to solve is to describe some kind of topology for
the case where we have an EC (cros-ec) chained with another EC
(cros-pd). Apart from that this extends the bounds of what MFD was
designed to do we might be interested on have other kinds of topology that
can't be implemented in that way.

Let's prepare the code to move the cros-ec-core part from MFD to
platform/chrome as this is clearly a platform specific thing non-related
to a MFD device.

  platform/chrome  |         MFD
------------------------------------------
                   |
   cros-ec ________|___ cros-ec-dev
                   |       |__ mfd-cell0
                   |       |__ mfd-cell1
                   |       |__ ...
                   |
   cros-pd ________|___ cros-ec-dev
                   |        |__ mfd-cell0
                   |        |__ mfd-cell1
                   |        |__ ...
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

For ECs that support it, the EC returns the number of slp_s0
transitions and whether or not there was a timeout in the resume
response. Expose the last resume result to usermode via debugfs so
that usermode can detect and report S0ix timeouts.
Signed-off-by: NEvan Green <evgreen@chromium.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

Based on 1 normalized pattern(s):

  this software is licensed under the terms of the gnu general public
  license version 2 as published by the free software foundation and
  may be copied distributed and modified under those terms this
  program is distributed in the hope that it will be useful but
  without any warranty without even the implied warranty of
  merchantability or fitness for a particular purpose see the gnu
  general public license for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 285 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAlexios Zavras <alexios.zavras@intel.com>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141900.642774971@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support in code for the new forms of the host sleep event.
Detects the presence of this version of the command at runtime,
and use whichever form the EC supports. At this time, always
request the default timeout, and only report the failing response
via a WARN_ONCE(). Future versions could accept the sleep parameter
from outside the driver, and return the response information to
usermode or elsewhere.
Signed-off-by: NEvan Green <evgreen@chromium.org>
Reviewed-by: NRajat Jain <rajatja@chromium.org>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Acked-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Use devm_mfd_add_devices() for adding cros-ec core MFD child devices. This
reduces the need of remove callback from platform/chrome for removing the
MFD child devices.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Currently on every resume we check for mkbp events and notify the
clients. This helps in identifying the wakeup sources. But on devices
that do not support mkbp protocol, we might end up querying key state of
the keyboard in a loop which blocks the resume. Instead check for events
only if mkbp is supported.
Signed-off-by: NRaviChandra Sadineni <ravisadineni@chromium.org>
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event
related to keyboard,  call pm_wakeup_event() to make sure wakeup
triggers are accounted to keyb during suspend resume path.
Signed-off-by: NRavi Chandra Sadineni <ravisadineni@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Free the IRQ we might have requested when removing the cros_ec device,
so we can unload and reload the driver properly.
Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: NVincent Palatin <vpalatin@chromium.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If we cannot communicate with the EC chip to detect the protocol version
and its features, it's very likely useless to continue. Else we will
commit all kind of uninformed mistakes (using the wrong protocol, the
wrong buffer size, mixing the EC with other chips).
Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
Acked-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This reverts commit e04653a9.

It is no longer needed to install Chrome EC GPE handler to have
GPE enabled in suspend to idle path. It is found that with this
handler installed, EC wake up doesn't work because default EC
event handler that can wake up system is not getting called.
Signed-off-by: NWenkai Du <wenkai.du@intel.com>
Acked-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This patch splits the cros_ec_devs module in two parts with a
cros_ec_dev module responsible for handling MFD devices registration and
a cros_ec_ctl module responsible for handling the various user-space
interfaces.

For consistency purpose, the driver name for the cros_ec_dev module is
now cros-ec-dev instead of cros-ec-ctl.

In the next commit, the new cros_ec_dev module will be moved to the MFD
subtree so mfd_add_devices() calls are not done from outside MFD.
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Currently we request the irq when probing, but never free it. So after
unbind ec driver, this irq will be left requested, which would break
the next bind:

[ 2683.338437] genirq: Flags mismatch irq 64. 00002008 (chromeos-ec) vs. 00002008 (chromeos-ec)
[ 2683.338591] cros-ec-spi spi5.0: request irq 64: error -16
[ 2683.338610] cros-ec-spi spi5.0: cannot register EC
[ 2683.338656] cros-ec-spi: probe of spi5.0 failed with error -16
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The subset of wake-enabled host events is defined by the EC, but the EC
may still send non-wake host events if we're in the process of
suspending. Get the mask of wake-enabled host events from the EC and
filter out non-wake events to prevent spurious aborted suspend
attempts.
Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Acked-for-MFD-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenson Leung <bleung@chromium.org>

This patch installs an ACPI GPE handler for LID0 ACPI device to indicate
ACPI core that this GPE should stay enabled for lid to work in suspend
to idle path.
Signed-off-by: NArchana Patni <archana.patni@intel.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

pm_suspend_via_firmware() will return false for platforms with ACPI
disabled and ACPI is a prerequisite for S0ix support.

With this patch, sleep state event sent to EC is forced to S3 if ACPI is
disabled.
Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Notify EC when going to or returning from suspend so that proper actions
related to wake events can be taken.
Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The cros_ec driver is still active while the device is suspended.
Besides that, it also tries to transfer data even after the I2C host had
been suspended. This patch uses a simple flag to prevent this.
Signed-off-by: NJoseph Lo <josephl@nvidia.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Newer revisions of the ChromeOS EC add more events besides the keyboard
ones. So handle interrupts in the MFD driver and let consumers register
for notifications for the events they might care.

To keep backward compatibility, if the EC doesn't support MKBP event, we
fall back to the old MKBP key matrix host command.

Cc: Randall Spangler <rspangler@chromium.org>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Signed-off-by: NVic Yang <victoryang@google.com>
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Signed-off-by: NLee Jones <lee.jones@linaro.org>

Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.

Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.

Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NDmitry Torokhov <dtor@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Add support in cros_ec.c to handle EC host command protocol v3.
For v3+, probe for maximum shared protocol version and max
request, response, and passthrough sizes. For now, this will
always fall back to v2, since there is no bus-specific code
for handling proto v3 packets.
Signed-off-by: NStephen Barber <smbarber@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The MFD driver should only have the logic to instantiate its child devices
and setup any shared resources that will be used by the subdevices drivers.

The cros_ec MFD is more complex than expected since it also has helpers to
communicate with the EC. So the driver will only get more bigger as other
protocols are supported in the future. So move the communication protocol
helpers to its own driver as drivers/platform/chrome/cros_ec_proto.c.
Suggested-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Commit 1b84f2a4 ("mfd: cros_ec: Use fixed size arrays to transfer
data with the EC") modified the struct cros_ec_command fields to not
use pointers for the input and output buffers and use fixed length
arrays instead.

This change was made because the cros_ec ioctl API uses that struct
cros_ec_command to allow user-space to send commands to the EC and
to get data from the EC. So using pointers made the API not 64-bit
safe. Unfortunately this approach was not flexible enough for all
the use-cases since there may be a need to send larger commands
on newer versions of the EC command protocol.

So to avoid to choose a constant length that it may be too big for
most commands and thus wasting memory and CPU cycles on copy from
and to user-space or having a size that is too small for some big
commands, use a zero-length array that is both 64-bit safe and
flexible. The same buffer is used for both output and input data
so the maximum of these values should be used to allocate it.
Suggested-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If the EC device tree node has sub-nodes, try to instantiate them as
MFD sub-devices.  We can configure the EC features provided by the board.
Signed-off-by: NTodd Broch <tbroch@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The ChromeOS EC character device is an user-space interface to
allow applications to access the Embedded Controller.

Add a cell for this device so it's spawned from the mfd driver.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The struct cros_ec_command will be used as an ioctl() argument for the
API to control the ChromeOS EC from user-space. So the data structure
has to be 64-bit safe to make it compatible between 32 and 64 avoiding
the need for a compat ioctl interface. Since pointers are self-aligned
to different byte boundaries, use fixed size arrays instead of pointers
for transferring ingoing and outgoing data with the Embedded Controller.

Also, re-arrange struct members by decreasing alignment requirements to
reduce the needing padding size.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
it is working on the in-progress command.

The 10 milliseconds delay and the number of retries are the values
that were used by the flashrom tool when retrying commands.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI driver.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Instead of having users of the ChromeOS EC call the interface-specific
cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
to use instead.  This will allow us to put all the locking and retry
logic in one place instead of duplicating it across the different
drivers.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>