Skip to content

L
linux
Switch branch/tag
  1. 09 Nov, 2020 17 commits
  3. 07 Oct, 2020 2 commits
  5. 05 Oct, 2020 5 commits
  7. 04 Oct, 2020 2 commits
  9. 28 Sep, 2020 2 commits
  11. 16 Sep, 2020 8 commits
  13. 14 Sep, 2020 4 commits
    • Johnny Chuang's avatar
      Input: elants_i2c - report resolution of ABS_MT_TOUCH_MAJOR by FW information. · 4238e52c
      Johnny Chuang authored 
      This patch adds a new behavior to report touch major resolution
based on information provided by firmware.

In initial process, driver acquires touch information from touch ic.
It contains one byte about the resolution value of ABS_MT_TOUCH_MAJOR.
Touch driver will report touch major resolution by this information.
Signed-off-by: default avatarJohnny Chuang <johnny.chuang.emc@gmail.com>
Reviewed-by: default avatarHarry Cutts <hcutts@chromium.org>
Link: https://lore.kernel.org/r/1598581195-9874-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      4238e52c
    • Furquan Shaikh's avatar
      Input: raydium_i2c_ts - use single i2c_transfer transaction when using RM_CMD_BANK_SWITCH · f492ffe4
      Furquan Shaikh authored 
      On an AMD chromebook, where the same I2C bus is shared by both Raydium
touchscreen and a trackpad device, it is observed that interleaving of
I2C messages when `raydium_i2c_read_message()` is called leads to the
Raydium touch IC reporting incorrect information. This is the sequence
that was observed to result in the above issue:

* I2C write to Raydium device for RM_CMD_BANK_SWITCH
* I2C write to trackpad device
* I2C read from trackpad device
* I2C write to Raydium device for setting address
* I2C read from Raydium device >>>> This provides incorrect
  information

This change adds a new helper function `raydium_i2c_xfer()` that
performs I2C transactions to the Raydium device. It uses the register
address to decide if RM_CMD_BANK_SWITCH header needs to be sent to the
device (i.e. if register address is greater than 255, then bank switch
header is sent before the rest of the transaction). Additionally, it
ensures that all the I2C operations performed as part of
`raydium_i2c_xfer()` are done as a single i2c_transfer. This
guarantees that no other transactions are initiated to any other
device on the same bus in between. Additionally,
`raydium_i2c_{send|read}*` functions are refactored to use this new
helper function.

Verified with the patch across multiple reboots (>100) that the
information reported by the Raydium  touchscreen device during probe
is correct.
Signed-off-by: default avatarFurquan Shaikh <furquan@google.com>
Link: https://lore.kernel.org/r/20200821024006.3399663-1-furquan@google.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      f492ffe4
    • Hans de Goede's avatar
      Input: soc_button_array - work around DSDTs which modify the irqflags · 78a5b53e
      Hans de Goede authored 
      Some 2-in-1s which use the soc_button_array driver have this ugly issue in
their DSDT where the _LID method modifies the irq-type settings of the
GPIOs used for the power and home buttons. The intend of this AML code is
to disable these buttons when the lid is closed.

The AML does this by directly poking the GPIO controllers registers. This
is problematic because when re-enabling the irq, which happens whenever
_LID gets called with the lid open (e.g. on boot and on resume), it sets
the irq-type to IRQ_TYPE_LEVEL_LOW. Where as the gpio-keys driver programs
the type to, and expects it to be, IRQ_TYPE_EDGE_BOTH.

This commit adds a workaround for this which (on affected devices) does
not set gpio_keys_button.gpio on these 2-in-1s, instead it gets the irq for
the GPIO, configures it as IRQ_TYPE_LEVEL_LOW (to match how the _LID AML
code configures it) and passes the irq in gpio_keys_button.irq.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200906122016.4628-2-hdegoede@redhat.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      78a5b53e
    • Hans de Goede's avatar
      Input: soc_button_array - add support for INT33D3 tablet-mode switch devices · 4e5d9c19
      Hans de Goede authored 
      According to the Microsoft documentation for Windows 8 convertible
devices, these devices should implement a PNP0C60 "laptop/slate mode state
indicator" ACPI device.

This device can work in 2 ways, if there is a GPIO which directly
indicates the device is in tablet-mode or not then the direct-gpio mode
should be used. If there is no such GPIO, but instead the events are
coming from e.g. the embedded-controller, then there should still be
a PNP0C60 ACPI device and event-injection should be used to send the
events. The drivers/platform/x86/intel-vbtn.c code is an example from
a standardized manner of doing the latter.

On various 2-in-1s with either a detachable keyboard, or with 360°
hinges, the direct GPIO mode is indicated by an ACPI device with a
HID of INT33D3, which contains a single GpioInt in its ACPI resource
table, which directly indicates if the device is in tablet-mode or not.

This commit adds support for this to the soc_button_array code, as
well as for the alternative ID9001 HID which some devices use
instead of the INT33D3 HID.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200826150601.12137-3-hdegoede@redhat.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      4e5d9c19
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7