kernel.git/drivers/mfd/cros_ec.c, branch linux-4.0.y

mfd: cros_ec: wait for completion of commands that return IN_PROGRESS

2014-10-06T20:30:16Z

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 Reviewed-by: Simon Glass Signed-off-by: Javier Martinez Canillas Signed-off-by: Lee Jones

mfd: cros_ec: move locking into cros_ec_cmd_xfer

2014-10-06T20:29:50Z

Now that there's a central cros_ec_cmd_xfer(), move the locking out of the SPI driver. Signed-off-by: Andrew Bresticker Reviewed-by: Simon Glass Signed-off-by: Javier Martinez Canillas Reviewed-by: Doug Anderson Signed-off-by: Lee Jones

mfd: cros_ec: stop calling ->cmd_xfer() directly

2014-10-06T20:29:07Z

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 Reviewed-by: Simon Glass Signed-off-by: Javier Martinez Canillas Reviewed-by: Doug Anderson Signed-off-by: Lee Jones

mfd: cros_ec: Move EC interrupt to cros_ec_keyb

2014-07-09T13:58:20Z

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 Signed-off-by: Doug Anderson Acked-by: Dmitry Torokhov Signed-off-by: Lee Jones

mfd: cros_ec: Check result code from EC messages

2014-07-09T13:58:19Z

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 Signed-off-by: Doug Anderson Signed-off-by: Lee Jones

mfd: cros_ec: cleanup: Remove EC wrapper functions

2014-07-09T13:58:18Z

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 Signed-off-by: Doug Anderson Reviewed-by: Simon Glass Acked-by: Wolfram Sang Acked-by: Dmitry Torokhov Signed-off-by: Lee Jones

mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device

2014-07-09T13:58:18Z

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 Signed-off-by: Doug Anderson Reviewed-by: Simon Glass Signed-off-by: Lee Jones

mfd: cros_ec: Use struct cros_ec_command to communicate with the EC

2014-07-09T13:58:17Z

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 Signed-off-by: Doug Anderson Signed-off-by: Lee Jones

mfd: cros_ec: Tweak struct cros_ec_device for clarity

2014-07-09T13:58:16Z

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 Signed-off-by: Doug Anderson Signed-off-by: Lee Jones

i2c: ChromeOS EC tunnel driver

2014-06-03T07:11:49Z

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 Signed-off-by: Simon Glass Signed-off-by: Doug Anderson Reviewed-by: Wolfram Sang Signed-off-by: Lee Jones