1. 14 Sep, 2020 4 commits
    • 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
    • Hans de Goede's avatar
      Input: soc_button_array - add active_low setting to soc_button_info · 838fc808
      Hans de Goede authored
      This is a preparation patch for adding support for Intel INT33D3
      ACPI devices. These INT33D3 devices follow yet another Intel defined
      (but not documented) ACPI GPIO button standard.
      
      Unlike the ACPI GPIO button devices supported so far, the GPIO used in
      the INT33D3 devices is active-high, rather then active-low.
      
      This commit makes setting the gpio_keys_button.active_low flag
      configurable through the soc_button_info struct and enables it for all
      currently supported devices.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20200826150601.12137-2-hdegoede@redhat.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      838fc808
  2. 08 Sep, 2020 4 commits
  3. 25 Aug, 2020 1 commit
  4. 07 Aug, 2020 7 commits
  5. 30 Jul, 2020 1 commit
  6. 29 Jul, 2020 2 commits
  7. 22 Jul, 2020 4 commits
  8. 21 Jul, 2020 3 commits
  9. 18 Jul, 2020 7 commits
  10. 16 Jul, 2020 1 commit
  11. 09 Jul, 2020 1 commit
  12. 07 Jul, 2020 5 commits