Pull chrome platform updates from Benson Leung.
Everything but the SPDX identifier updates actually came in earlier
through the MFD merge.
* tag 'chrome-platform-for-linus-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: chromeos_tbmc - fix SPDX identifier
Immutable branch (mfd, chrome) due for the v4.19 window
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
Immutable branch (mfd, chrome) due for the v4.19 window
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
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>
Original submission was GPLv2 only, so mark as GPL-2.0.
Also restored some descriptive lines that were there before.
Signed-off-by: Benson Leung <bleung@chromium.org>
Pull chrome platform updates from Benson Leung:
- further changes from Dmitry related to the removal of platform data
from atmel_mxt_ts and chromeos_laptop.
This time, we have some changes that teach chromeos_laptop how to
supply acpi properties for some input devices so that the peripheral
driver doesn't have to do dmi matching on some Chromebook platforms.
- new Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.
- other misc cleanup
* tag 'chrome-platform-for-linus-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: Use to_cros_ec_dev more broadly
platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes
platform: chrome: Add input dependency for tablet switch driver
platform/chrome: chromeos_laptop - supply properties for ACPI devices
platform/chrome: chromeos_tbmc - add SPDX identifier
platform: chrome: Add Tablet Switch ACPI driver
platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found
Move to_cros_ec_dev macro to cros_ec.h and use it when the private ec
object is needed from device object.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Celes has newer touch controller (compared to the controllers used in
older BayTrail-based devices) and so uses the same button mapping as
Samus.
This fixes the issue with mouse button being stuck in pressed state
after the first click.
Reported-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
We should stop our worker thread while we're suspended. If we don't
then we'll get messages like:
cros-ec-spi spi5.0: spi transfer failed: -108
cros-ec-spi spi5.0: cs-deassert spi transfer failed: -108
cros-ec-ctl cros-ec-ctl.0.auto: EC communication failed
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
BayTrail-based and newer Chromebooks describe their peripherals in ACPI;
unfortunately their description is not complete, and peripherals
drivers, such as driver for Atmel Touch controllers, has to resort to
DMI-matching to configure the peripherals properly. To avoid polluting
peripheral driver code, let's teach chromeos_laptop driver to supply
missing data via generic device properties.
Note we supply "compatible" string for Atmel peripherals not because it is
needed for matching devices and driver (matching is still done on ACPI HID
entries), but because peripherals driver will be using presence of
"compatible" property to determine if device properties have been attached
to the device, and fail to bind if they are absent.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace the original license statement with the SPDX identifier.
Add also one line of description as recommended by the COPYING file.
Signed-off-by: Benson Leung <bleung@chromium.org>
Add a kernel driver for GOOG0006, an ACPI driver reporting an event when
the tablet switch status changes.
On an ACPI based convertible chromebook check evtest display tablet mode
switch changes:
Available devices:
..
/dev/input/event3: Tablet Mode Switch
..
Testing ... (interrupt to exit)
Event: time 1484879712.604360, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 1
Event: time 1484879712.604360, -------------- SYN_REPORT ------------
Event: time 1484879715.132228, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 0
Event: time 1484879715.132228, -------------- SYN_REPORT ------------
...
Check state is updated at resume time when different from suspend time.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Commit 001dde9400 ("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 001dde9400 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 001dde9400, this resolves bugs like the
following:
1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400, we
would abort the first time we saw EC_SPI_PAST_END)
2. Before commit 001dde9400, 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: 001dde9400 ("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>
Older models of Chromebooks did not describe the LPC EC in their ACPI
tables; starting with Strago-based devices Google is using GOOG0004 device
to describe EC LPC.
DMI-based match is fragile and does not work reliably, especially when
using custom firmware. It is also not needed when we can locate the right
ACPI device, so let's stop bailing out when DMI does not match but the
right ACPI device is present.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle)
used to set and get the keyboard wake lid angle. This attribute is
present only if 2 accelerometers are controlled by the EC.
This patch also moves the cros_ec features check before the device is
added so the features map obtained from the EC is ready on time.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
When accessing a sysfs attribute, if the EC command fails, -EPROTO is
now returned instead of an error message as it is unlikely an app is
parsing the error message to do something meaningful.
Also, this patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer() so an error message is printed in the syslog.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
