summaryrefslogtreecommitdiffstats
path: root/drivers/mfd/cros_ec_spi.c
Commit message (Collapse)AuthorAgeFilesLines
* platform/chrome: Move cros-ec transport drivers to drivers/platform.Enric Balletbo i Serra2018-07-031-743/+0
| | | | | | | | | | | | | There are some cros-ec transport drivers (I2C, SPI) living in MFD, while others (LPC) living in drivers/platform. The transport drivers are more platform specific. So, move the I2C and SPI transport drivers to the platform/chrome directory. The patch also removes the MFD_ prefix of their Kconfig symbols. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
* mfd: cros_ec: Retry commands when EC is known to be busyBrian Norris2018-05-231-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 001dde9400d5 ("mfd: cros ec: spi: Fix "in progress" error signaling") pointed out some bad code, but its analysis and conclusion was not 100% correct. It *is* correct that we should not propagate result==EC_RES_IN_PROGRESS for transport errors, because this has a special meaning -- that we should follow up with EC_CMD_GET_COMMS_STATUS until the EC is no longer busy. This is definitely the wrong thing for many commands, because among other problems, EC_CMD_GET_COMMS_STATUS doesn't actually retrieve any RX data from the EC, so commands that expected some data back will instead start processing junk. For such commands, the right answer is to either propagate the error (and return that error to the caller) or resend the original command (*not* EC_CMD_GET_COMMS_STATUS). Unfortunately, commit 001dde9400d5 forgets a crucial point: that for some long-running operations, the EC physically cannot respond to commands any more. For example, with EC_CMD_FLASH_ERASE, the EC may be re-flashing its own code regions, so it can't respond to SPI interrupts. Instead, the EC prepares us ahead of time for being busy for a "long" time, and fills its hardware buffer with EC_SPI_PAST_END. Thus, we expect to see several "transport" errors (or, messages filled with EC_SPI_PAST_END). So we should really translate that to a retryable error (-EAGAIN) and continue sending EC_CMD_GET_COMMS_STATUS until we get a ready status. IOW, it is actually important to treat some of these "junk" values as retryable errors. Together with commit 001dde9400d5, this resolves bugs like the following: 1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400d5, we would abort the first time we saw EC_SPI_PAST_END) 2. Before commit 001dde9400d5, transport errors (e.g., EC_SPI_RX_BAD_DATA) seen in other commands (e.g., EC_CMD_RTC_GET_VALUE) used to yield junk data in the RX buffer; they will now yield -EAGAIN return values, and tools like 'hwclock' will simply fail instead of retrieving and re-programming undefined time values Fixes: 001dde9400d5 ("mfd: cros ec: spi: Fix "in progress" error signaling") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* Merge tag 'mfd-next-4.16' of ↵Linus Torvalds2018-01-291-16/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Drivers: - Add support for RAVE Supervisory Processor Moved drivers: - Move Realtek Card Reader Driver to Misc New Device Support: - Add support for Pinctrl to axp20x New Functionality: - Add resume support to atmel-flexcom Fix-ups: - Split MFD (mfd) and userspace handlers (platform) in cros_ec - Fix trivial (whitespace, spelling) issue(s) in pcf50633-core - Clean-up error handling in ab8500-debugfs - General tidying up in tmio_core - Kconfig fix-ups for qcom-pm8xxx - Licensing changes (SPDX) to stm32-lptimer, stm32-timers - Device Tree fixups in mc13xxx - Simplify/remove unused code in cros_ec_spi, axp20x, ti_am335x_tscadc, kempld-core, intel_soc_pmic_core.c, ab8500-debugfs" * tag 'mfd-next-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (32 commits) mfd: lpc_ich: Do not touch SPI-NOR write protection bit on Apollo Lake mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile mfd: ab8500: Introduce DEFINE_SHOW_ATTRIBUTE() macro atmel_flexcom: Support resuming after a chip reset mfd: Remove duplicate includes dt-bindings: mfd: mc13xxx: Add the unit address to sysled mfd: stm32: Adopt SPDX identifier mfd: axp20x: Add pinctrl cell for AXP813 mfd: pm8xxx: Make elegible for COMPILE_TEST mfd: kempld-core: Use resource_size function on resource object mfd: tmio: Move register macros to tmio_core.c mfd: cros ec: spi: Simplify delay handling between SPI messages mfd: palmas: Assign the right powerhold mask for tps65917 mfd: ab8500-debugfs: Use common error handling code in ab8500_print_modem_registers() mfd: ti_am335x_tscadc: Remove redundant assignment to node mfd: pcf50633: Fix spelling mistake: 'Falied' -> 'Failed' dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver watchdog: Add RAVE SP watchdog driver mfd: Add driver for RAVE Supervisory Processor serdev: Introduce devm_serdev_device_open() ...
| * mfd: cros ec: spi: Simplify delay handling between SPI messagesJon Hunter2018-01-081-16/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EC SPI driver prevents SPI transfers being to rapidly by keeping track of the time the last transfer was issued via the 'last_transfer_ns' variable. Previously, if the 'last_transfer_ns' variable was zero, this indicated that no previous transfer had been sent and that no delay was needed. However, the EC SPI driver has been updated to always initialise the 'last_transfer_ns' variable during probe and therefore, it is no longer necessary to test if it is zero. Remove the code that checks if this variable is zero. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Benson Leung <bleung@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* | mfd: cros ec: spi: Fix "in progress" error signalingShawn Nematbakhsh2017-11-291-28/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For host commands that take a long time to process, cros ec can return early by signaling a EC_RES_IN_PROGRESS result. The host must then poll status with EC_CMD_GET_COMMS_STATUS until completion of the command. None of the above applies when data link errors are encountered. When errors such as EC_SPI_PAST_END are encountered during command transmission, it usually means the command was not received by the EC. Treating such errors as if they were 'EC_RES_IN_PROGRESS' results is almost always the wrong decision, and can result in host commands silently being lost. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* | mfd: cros ec: spi: Don't send first message too soonJon Hunter2017-11-291-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | On the Tegra124 Nyan-Big chromebook the very first SPI message sent to the EC is failing. The Tegra SPI driver configures the SPI chip-selects to be active-high by default (and always has for many years). The EC SPI requires an active-low chip-select and so the Tegra chip-select is reconfigured to be active-low when the EC SPI driver calls spi_setup(). The problem is that if the first SPI message to the EC is sent too soon after reconfiguring the SPI chip-select, it fails. The EC SPI driver prevents back-to-back SPI messages being sent too soon by keeping track of the time the last transfer was sent via the variable 'last_transfer_ns'. To prevent the very first transfer being sent too soon, initialise the 'last_transfer_ns' variable after calling spi_setup() and before sending the first SPI message. Cc: <stable@vger.kernel.org> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Benson Leung <bleung@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Increase wait time to 200msDoug Anderson2017-04-271-3/+6
| | | | | | | | | | | | | | | | | | | | | This is a sucky change to bump up the time we'll wait for the EC. Why is it sucky? If 200ms for a transfer is a common thing it will have a massively bad impact on keyboard responsiveness. It still seems like a good idea to do this, though, because we have a gas gauge that claims that in an extreme case it could stretch the i2c clock for 144ms. It's not a common case so it shouldn't affect responsiveness, but it can happen. It's much better to have a single slow keyboard response than to start returning errors when we don't have to. In newer EC designs we should probably implement a virtual battery to respond to the kernel to insulate the kernel from these types of issues. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec_spi: Remove unused variable 'request'Lee Jones2016-10-041-2/+0
| | | | Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec_spi: Repair comparison ordering issueLee Jones2016-01-141-2/+2
| | | | | | | | | | | | WARNING: Comparisons should place the constant on the right side of the test + BUG_ON(EC_MSG_PREAMBLE_COUNT > ec_dev->din_size); WARNING: Comparisons should place the constant on the right side of the test + BUG_ON(EC_MSG_PREAMBLE_COUNT > ec_dev->din_size); total: 0 errors, 2 warnings, 731 lines checked Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: Lock the SPI bus while holding chipselectNicolas Boichat2016-01-111-12/+18
| | | | | | | | | | | | | | | | | | | | | | cros_ec_cmd_xfer_spi and cros_ec_pkt_xfer_spi generally work like this: - Pull CS down (active), wait a bit, then send a command - Wait for response (multiple requests) - Wait a while, pull CS up (inactive) These operations, individually, lock the SPI bus, but there is nothing preventing the SPI framework from interleaving messages intended for other devices as the bus is unlocked in between. This is a problem as the EC expects CS to be held low for the whole duration. Solution: Lock the SPI bus during the whole transaction, to make sure that no other messages can be interleaved. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* spi: Drop owner assignment from spi_driversAndrew F. Davis2015-10-281-1/+0
| | | | | | | | | An spi_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* mfd: cros_ec: spi: Add OF match tableJavier Martinez Canillas2015-08-241-0/+7
| | | | | | | | | | The Documentation/devicetree/bindings/mfd/cros-ec.txt DT binding doc lists "google,cros-ec-spi" as a compatible string but the corresponding driver does not have an OF match table. Add the table to the driver so the SPI core can do an OF style match. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec: spi: Add delay for asserting CSAlexandru M Stan2015-06-151-2/+19
| | | | | | | | | | | | | | | | | | | Some ECs need a little time for waking up before they can accept SPI data at a high speed. This is configurable via a DT property "google,cros-ec-spi-pre-delay". This patch makes the cros_ec_spi driver to cause a delay before the beginning of a SPI transaction, to make sure that the EC has already woken up, if the property has been defined in the DTS. Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Chris Zhong <zyw@rock-chips.com> 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>
* mfd: cros_ec: Support multiple EC in a systemGwendal Grignou2015-06-151-1/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* mfd: cros_ec: add bus-specific proto v3 codeStephen Barber2015-06-151-53/+329
| | | | | | | | | | | | | Add proto v3 support to the SPI, I2C, and LPC. Signed-off-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec: add proto v3 skeletonStephen Barber2015-06-151-2/+5
| | | | | | | | | | | | | | | | | 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>
* mfd: cros_ec: Use a zero-length array for command dataJavier Martinez Canillas2015-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mfd: cros_ec: Remove parent fieldGwendal Grignou2015-06-151-1/+0
| | | | | | | | | | | | | | Parent and device were pointing to the same device structure. Parent is unused, removed. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Stephen Barber <smbarber@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec: move locking into cros_ec_cmd_xferAndrew Bresticker2014-10-061-11/+0
| | | | | | | | | | | 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>
* mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_ECDoug Anderson2014-10-061-0/+9
| | | | | | | | | | | | | | | | | | | | | If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be unresponsive for quite a while. Add a delay to the end of the command to prevent random failures of future commands. NOTES: * This could be optimized a bit by simply delaying the next command sent, but EC_CMD_REBOOT_EC is such a rare command that the extra complexity doesn't seem worth it. * This is a bit of an "ugly hack" since the SPI driver is effectively snooping on the communication and making a lot of assumptions. It would be nice to architect in some better solution long term. * This same logic probably needs to be applied to the i2c driver. Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* Merge tag 'mfd-for-linus-3.17' of ↵Linus Torvalds2014-08-071-30/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD update from Lee Jones: "Changes to existing drivers: - checkpatch fixes throughout the subsystem - use Regmap to handle IRQs in max77686, extcon-max77693 and mc13xxx-core - use DMA in rtsx_pcr - restrict building on unsupported architectures on timberdale, cs5535 - SPI hardening in cros_ec_spi - more robust error handing in asic3, cros_ec, ab8500-debugfs, max77686 and pcf50633-core - reorder PM runtime and regulator handing during shutdown in arizona - enable wakeup in cros_ec_spi - unused variable/code clean-up in pm8921-core, cros_ec, htc-i2cpld, tps65912-spi, wm5110-tables and ab8500-debugfs - add regulator handing into suspend() in sec-core - remove pointless wrapper functions in extcon-max77693 and i2c-cros-ec-tunnel - use cross-architecture friendly data sizes in stmpe-i2c, arizona, max77686 and tps65910 - devicetree documentation updates throughout - provide power management support in max77686 - few OF clean-ups in max77686 - use manged resources in tps6105x New drivers/supported devices: - add support for s2mpu02 to sec-core - add support for Allwinner A32 to sun6i-prcm - add support for Maxim 77802 in max77686 - add support for DA9063 AD in da9063 - new driver for Intel PMICs (generic) and specifically Crystal Cove (Re-)moved drivers == - move out keyboard functionality cros_ec ==> input/keyboard/cros_ec_keyb" * tag 'mfd-for-linus-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (101 commits) MAINTAINERS: Update MFD repo location mfd: omap-usb-host: Fix improper mask use. mfd: arizona: Only free the CTRLIF_ERR IRQ if we requested it mfd: arizona: Add missing handling for ISRC3 under/overclocked mfd: wm5110: Add new interrupt register definitions mfd: arizona: Rename thermal shutdown interrupt mfd: wm5110: Add in the output done interrupts mfd: wm5110: Remove non-existant interrupts mfd: tps65912-spi: Remove unused variable mfd: htc-i2cpld: Remove unused code mfd: da9063: Add support for AD silicon variant mfd: arizona: Map MICVDD from extcon device to the Arizona core mfd: arizona: Add MICVDD to mapped regulators for wm8997 mfd: max77686: Ensure device type IDs are architecture agnostic mfd: max77686: Add Maxim 77802 PMIC support mfd: tps6105x: Use managed resources when allocating memory mfd: wm8997-tables: Suppress 'line over 80 chars' warnings mfd: kempld-core: Correct a variety of checkpatch warnings mfd: ipaq-micro: Fix coding style errors/warnings reported by checkpatch mfd: si476x-cmd: Remedy checkpatch style complains ...
| * mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from ECBill Richardson2014-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | When communicating with the EC, the cmd_xfer() function should return the number of bytes it received from the EC, or negative on error. 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> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| * mfd: cros_ec: Check result code from EC messagesBill Richardson2014-07-091-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_deviceBill Richardson2014-07-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * mfd: cros_ec: Use struct cros_ec_command to communicate with the ECBill Richardson2014-07-091-8/+8
| | | | | | | | | | | | | | | | | | | | 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>
| * mfd: cros_ec: Detect in-progress commandsSimon Glass2014-07-091-0/+6
| | | | | | | | | | | | | | | | | | Some commands take a while to execute. Use -EAGAIN to signal this to the caller. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| * mfd: cros_ec: Tweak struct cros_ec_device for clarityBill Richardson2014-07-091-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * mfd: cros_ec_spi: Set wakeup capabilityPrathyush K2014-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Set the device as wakeup capable and register the wakeup source. Note: Though it makes more sense to have the SPI framework do this, (either via device tree or by board_info) this change is as per an existing mail chain: https://lkml.org/lkml/2009/8/27/291 Signed-off-by: Prathyush K <prathyush.k@samsung.com> Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
| * mfd: cros_ec: spi: Fix end of transfer on devices with no spi-msg-delayDoug Anderson2014-07-091-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cros_ec_spi makes the assumption that a 0-length message will put the spi chip select back to normal (non cs_toggle mode). This used to be the case back on kernel-3.8 on the spi-s3c64xx driver but doesn't appear to be true anymore. It seems like it was a pretty questionable assumption to begin with, so let's fix the code to be more robust. We know that a message with a single 0-length segment _will_ put things back in order. Change cros_ec_spi to handle this. This wasn't a problem on the main user of cros_ec_spi upstream (tegra) because it specified 'google,cros-ec-spi-msg-delay'. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* | mfd: cros_ec_spi: Use ktime_get_ns()Thomas Gleixner2014-07-231-6/+2
|/ | | | | | | | | | | | Replace the ever recurring: ts = ktime_get_ts(); ns = timespec_to_ns(&ts); with ns = ktime_get_ns(); Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org>
* mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100msDoug Anderson2014-06-031-8/+16
| | | | | | | | | | | | 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: spi: Make the cros_ec_spi timeout more reliableDoug Anderson2014-06-031-3/+12
| | | | | | | | | | | | | | | 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: Add mutex to cros_ec_spiDoug Anderson2014-06-031-5/+21
| | | | | | | | | | | | | 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: Calculate delay between transfers correctlyDavid Hendricks2014-06-031-1/+1
| | | | | | | | | | | | | | | | | 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 delay for raising CSRhyland Klein2014-01-211-0/+29
| | | | | | | | | | | | | | | | | The EC has specific timing it requires. Add support for an optional delay after raising CS to fix timing issues. This is configurable based on a DT property "google,cros-ec-spi-msg-delay". If this property isn't set, then no delay will be added. However, if set it will cause a delay equal to the value passed to it to be inserted at the end of a transaction. Signed-off-by: Rhyland Klein <rklein@nvidia.com> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Use 0 instead of '\0' consistentlyThierry Reding2014-01-211-3/+3
| | | | | | | | | memset() was being called with the second parameter set to '\0', which is equivalent but longer than the more canonical 0. Update the code to use the latter variant consistently across the driver. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Use correct module licenseThierry Reding2014-01-211-1/+1
| | | | | | | | According to the header comment in the source file the driver is licensed under GPL v2, so update MODULE_LICENSE() to match that. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Use consistent function namesThierry Reding2014-01-211-4/+4
| | | | | | | | Rename cros_ec_{probe,remove}_spi() to cros_ec_spi_{probe,remove}() for consistency. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Fix debug outputThierry Reding2014-01-061-1/+3
| | | | | | | | The dev_cont() symbol doesn't exist, so replace it with pr_cont(). While at it, also append a newline to the debug output to make it look nicer. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros ec: spi: Increase EC transaction delayDerek Basehore2014-01-061-3/+4
| | | | | | | | | | | 50 us is not a long enough delay between EC transactions. At least 70 us are needed for the 16 MHz STM32L part. Increase the delay to 200 us for an extra safety margin. Reviewed-by: Randall Spangler <rspangler@chromium.org> Signed-off-by: Derek Basehore <dbasehore@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* mfd: cros_ec_spi: Use %z to format pointer differencesGeert Uytterhoeven2013-05-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Before commit 5c29e47e6ac55b63c76999eb5b283a80208726c5 ("mfd: cros_ec_spi: Warnings fix"), 64-bit compiles gave the following warnings: drivers/mfd/cros_ec_spi.c: In function 'cros_ec_spi_receive_response': drivers/mfd/cros_ec_spi.c:123:5: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat] drivers/mfd/cros_ec_spi.c:157:3: warning: format '%d' expects argument of type 'int', but argument 6 has type 'long int' [-Wformat] drivers/mfd/cros_ec_spi.c:181:2: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat] After that commit, 32-bit compiles give: drivers/mfd/cros_ec_spi.c: In function ‘cros_ec_spi_receive_response’: drivers/mfd/cros_ec_spi.c:123: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘int’ drivers/mfd/cros_ec_spi.c:157: warning: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘int’ drivers/mfd/cros_ec_spi.c:181: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘int’ Use %z to format pointer differences to kill the warnings on both 32-bit and 64-bit. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* mfd: cros_ec_spi: Warnings fixSamuel Ortiz2013-04-051-3/+3
| | | | | | | | | | | | | | | To silent those: CC [M] drivers/mfd/cros_ec_spi.o drivers/mfd/cros_ec_spi.c: In function ‘cros_ec_spi_receive_response’: drivers/mfd/cros_ec_spi.c:123:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long int’ [-Wformat] drivers/mfd/cros_ec_spi.c:157:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long int’ [-Wformat] drivers/mfd/cros_ec_spi.c:181:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long int’ [-Wformat] Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* mfd: Add ChromeOS EC SPI driverSimon Glass2013-04-051-0/+375
This uses a SPI bus to talk to the ChromeOS EC. The protocol is defined by the EC and is fairly simple, with a length byte, checksum, command byte and version byte (to permit easy creation of new commands). Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
OpenPOWER on IntegriCloud