summaryrefslogtreecommitdiff
path: root/drivers/mfd/cros_ec.c
AgeCommit message (Collapse)Author
2016-08-31mfd: cros_ec: Add MKBP event supportVic Yang
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: Vic Yang <victoryang@google.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-22mfd: cros_ec: Staticise some newly introduced structuresLee Jones
Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-15mfd: cros_ec: Support multiple EC in a systemGwendal Grignou
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: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-15mfd: cros_ec: add proto v3 skeletonStephen Barber
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: Stephen Barber <smbarber@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-15mfd: cros_ec: Move protocol helpers out of the MFD driverJavier Martinez Canillas
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: Lee Jones <lee.jones@linaro.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-15mfd: cros_ec: Use a zero-length array for command dataJavier Martinez Canillas
Commit 1b84f2a4cd4a ("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: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-06-15mfd: cros_ec: Instantiate sub-devices from device treeTodd Broch
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: Todd Broch <tbroch@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-02-26mfd: cros_ec: Instantiate ChromeOS EC character deviceJavier Martinez Canillas
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: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Lee Jones <lee.jones@linaro.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-02-26mfd: cros_ec: Use fixed size arrays to transfer data with the ECJavier Martinez Canillas
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: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Lee Jones <lee.jones@linaro.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2014-10-06mfd: cros_ec: wait for completion of commands that return IN_PROGRESSAndrew Bresticker
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: Andrew Bresticker <abrestic@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-10-06mfd: cros_ec: move locking into cros_ec_cmd_xferAndrew Bresticker
Now that there's a central cros_ec_cmd_xfer(), move the locking out of the SPI driver. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-10-06mfd: cros_ec: stop calling ->cmd_xfer() directlyAndrew Bresticker
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: Andrew Bresticker <abrestic@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: Move EC interrupt to cros_ec_keybAndrew Bresticker
If we receive EC interrupts after the cros_ec driver has probed, but before the cros_ec_keyb driver has probed, the cros_ec IRQ handler will not run the cros_ec_keyb notifier and the EC will leave the IRQ line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and the resulting flood of interrupts causes the machine to hang. Since the EC interrupt is currently only used for the keyboard, move the setup and handling of the EC interrupt to the cros_ec_keyb driver. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: Check result code from EC messagesBill Richardson
Just because the host was able to talk to the EC doesn't mean that the EC was happy with what it was told. Errors in communincation are not the same as error messages from the EC itself. This change lets the EC report its errors separately. [dianders: Added common function to cros_ec.c] Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: cleanup: Remove EC wrapper functionsBill Richardson
Remove the three wrapper functions that talk to the EC without passing all the desired arguments and just use the underlying communication function that passes everything in a struct intead. This is internal code refactoring only. Nothing should change. Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_deviceBill Richardson
struct cros_ec_device has a superfluous "name" field. We can get all the debugging info we need from the existing ec_name and phys_name fields, so let's take out the extra field. The printout also has sufficient info in it without explicitly adding the transport. Before this change: cros-ec-spi spi2.0: Chrome EC (SPI) After this change: cros-ec-spi spi2.0: Chrome EC device registered Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: Use struct cros_ec_command to communicate with the ECBill Richardson
This is some internal structure reorganization / renaming to prepare for future patches that will add a userspace API to cros_ec. There should be no visible changes. Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-09mfd: cros_ec: Tweak struct cros_ec_device for clarityBill Richardson
The members of struct cros_ec_device were improperly commented, and intermixed the private and public sections. This is just cleanup to make it more obvious what goes with what. [dianders: left lock in the structure but gave it the name that will eventually be used.] Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-06-03i2c: ChromeOS EC tunnel driverDoug Anderson
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>
2014-06-03mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sourcesBill Richardson
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>
2014-06-03mfd: cros_ec: cleanup: cros_ec.c is GPL licensed, like all the others.Bill Richardson
This module has always been GPL licensed. It was just missing the explicit declaration to avoid tainting the kernel. Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-01-06mfd: Constify struct mfd_cell where possibleGeert Uytterhoeven
As of commit 03e361b25ee8dfb1fd9b890072c23c4aae01c6c7 ("mfd: Stop setting refcounting pointers in original mfd_cell arrays"), the "cell" parameter of mfd_add_devices() is "const" again. Hence make all cell data passed to mfd_add_devices() const where possible. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2013-06-13mfd: cros_ec: Convert to managed resources for allocating memoryLee Jones
Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-04-05mfd: cros_ec: Export needed symbols for the i2c and spi modulesSamuel Ortiz
In order to fix those, when all cros code is modular: ERROR: "cros_ec_prepare_tx" [drivers/mfd/cros_ec_spi.ko] undefined! ERROR: "cros_ec_register" [drivers/mfd/cros_ec_spi.ko] undefined! ERROR: "cros_ec_remove" [drivers/mfd/cros_ec_spi.ko] undefined! ERROR: "cros_ec_suspend" [drivers/mfd/cros_ec_spi.ko] undefined! ERROR: "cros_ec_resume" [drivers/mfd/cros_ec_spi.ko] undefined! ERROR: "cros_ec_register" [drivers/mfd/cros_ec_i2c.ko] undefined! ERROR: "cros_ec_remove" [drivers/mfd/cros_ec_i2c.ko] undefined! ERROR: "cros_ec_suspend" [drivers/mfd/cros_ec_i2c.ko] undefined! ERROR: "cros_ec_resume" [drivers/mfd/cros_ec_i2c.ko] undefined! Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-04-05mfd: Add ChromeOS EC implementationSimon Glass
This is the base EC implementation, which provides a high level interface to the EC for use by the rest of the kernel. The actual communcations is dealt with by a separate protocol driver which registers itself with this interface. Interrupts are passed on through a notifier. A simple message structure is used to pass messages to the protocol driver. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Che-Liang Chiou <clchiou@chromium.org> Signed-off-by: Jonathan Kliegman <kliegs@chromium.org> Signed-off-by: Luigi Semenzato <semenzato@chromium.org> Signed-off-by: Olof Johansson <olofj@chromium.org> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>