1. 07 Mar, 2021 1 commit
    • Philippe Gerum's avatar
      ipipe: pinctrl: enable basic pipeline support · 4e7a5e7c
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      This patch enables the Intel pinctrl/GPIO core driver to operate in a
      pipelined interrupt system. However, it does not allow chained GPIO
      IRQs to be handled from the head stage of such pipeline yet. In other
      words, the chained GPIO interrupts can safely be handled from the
      in-band stage when CONFIG_IPIPE is turned on, but cannot be routed to
      a real-time application.
      Enabling full support will require the I-pipe core to handle IRQs
      chained from a shared parent interrupt natively, which it is not
      implemented at the moment.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
  2. 18 Nov, 2020 1 commit
  3. 21 Oct, 2019 1 commit
  4. 01 Oct, 2019 1 commit
  5. 09 Sep, 2019 1 commit
  6. 19 Aug, 2019 1 commit
    • Chris Chiu's avatar
      pinctrl: intel: remap the pin number to gpio offset for irq enabled pin · 6cb0880f
      Chris Chiu authored
      On Asus X571GT, GPIO 297 is configured as an interrupt and serves
      for the touchpad. The touchpad will report input events much less
      than expected after S3 suspend/resume, which results in extremely
      slow cursor movement. However, the number of interrupts observed
      from /proc/interrupts increases much more than expected even no
      touching touchpad.
      This is due to the value of PADCFG0 of PIN 225 for the interrupt
      has been changed from 0x80800102 to 0x80100102. The GPIROUTIOXAPIC
      is toggled on which results in the spurious interrupts. The PADCFG0
      of PIN 225 is expected to be saved during suspend, but the 297 is
      saved instead because the gpiochip_line_is_irq() expect the GPIO
      offset but what's really passed to it is PIN number. In this case,
      the /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges shows
      288: INT3450:00 GPIOS [436 - 459] PINS [216 - 239]
      So gpiochip_line_is_irq() returns true for GPIO offset 297, the
      suspend routine spuriously saves the content for PIN 297 which
      we expect to save for PIN 225.
      This commit maps the PIN number to GPIO offset first in the
      intel_pinctrl_should_save() to make sure the values for the
      specific PINs can be correctly saved and then restored.
      Fixes: c538b943
       ("pinctrl: intel: Only restore pins that are used by the driver")
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
  7. 18 Aug, 2019 1 commit
  8. 07 Aug, 2019 4 commits
  9. 23 Jul, 2019 2 commits
  10. 20 May, 2019 2 commits
  11. 28 Apr, 2019 2 commits
  12. 09 Apr, 2019 1 commit
    • Binbin Wu's avatar
      pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase · 2fef3276
      Binbin Wu authored
      In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the
      callbacks for suspend/resume.
      GPIO pin may be used as the interrupt pin by some device. However, using
      SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume
      callback is called after resume_device_irqs(). Unintended interrupts may
      arrive due to resuming device irqs first, but the GPIO controller is not
      properly restored.
      Normally, for a SMP system, there are multiple cores, so even when there are
      unintended interrupts, BSP gets the chance to initialize the GPIO chip soon.
      But when there is only 1 core is active (other cores are offlined or
      single core) during resume, it is more easily to observe the unintended
      This patch renames the suspend/resume function by adding suffix "_noirq",
      and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS().
      Signed-off-by: default avatarBinbin Wu <binbin.wu@intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
  13. 08 Nov, 2018 2 commits
  14. 03 Oct, 2018 2 commits
  15. 25 Sep, 2018 1 commit
  16. 20 Sep, 2018 1 commit
  17. 31 Aug, 2018 2 commits
  18. 29 Aug, 2018 1 commit
  19. 03 Aug, 2018 1 commit
  20. 29 Jul, 2018 1 commit
  21. 02 Jul, 2018 1 commit
  22. 23 Mar, 2018 1 commit
  23. 07 Dec, 2017 1 commit
  24. 02 Dec, 2017 1 commit
    • Mika Westerberg's avatar
      pinctrl: intel: Initialize GPIO properly when used through irqchip · f5a26acf
      Mika Westerberg authored
      When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
      switches the pin to GPIO mode and makes sure interrupts are routed to
      the GPIO hardware instead of IOAPIC. However, if the GPIO is used
      directly through irqchip, as is the case with many I2C-HID devices where
      I2C core automatically configures interrupt for the device, the pin is
      not initialized as GPIO. Instead we rely that the BIOS configures the
      pin accordingly which seems not to be the case at least in Asus X540NA
      SKU3 with Focaltech touchpad.
      When the pin is not properly configured it might result weird behaviour
      like interrupts suddenly stop firing completely and the touchpad stops
      responding to user input.
      Fix this by properly initializing the pin to GPIO mode also when it is
      used directly through irqchip.
      Fixes: 7981c001
       ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
      Reported-by: default avatarDaniel Drake <drake@endlessm.com>
      Reported-and-tested-by: default avatarChris Chiu <chiu@endlessm.com>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  25. 29 Nov, 2017 1 commit
  26. 08 Nov, 2017 1 commit
  27. 31 Oct, 2017 1 commit
  28. 31 Aug, 2017 2 commits
  29. 22 Aug, 2017 1 commit
    • Rushikesh S Kadam's avatar
      pinctrl: intel: Disable GPIO pin interrupts in suspend · 5ff56b01
      Rushikesh S Kadam authored
      The fix prevents unintended wakes from second level GPIO pin interrupts.
      On some Intel Kabylake platforms, it is observed that GPIO pin interrupts
      can wake the platform from suspend-to-idle, even though the IRQ is not
      configured as IRQF_NO_SUSPEND or enable_irq_wake().
      This can cause undesired wakes on Mobile devices such as Laptops and
      Chromebook devices. For example a headset jack insertion is not a desired
      wake source on Chromebook devices.
      The pinctrl-intel (GPIO controller) driver implements a "Shared IRQ" model.
      All GPIO pin interrupts are OR'ed and mapped to a first level IRQ14 (or
      IRQ15). The driver registers an irq_chip struct and maps an irq_domain for
      the GPIO pin interrupts. The IRQ14 handler demuxes and calls the second
      level IRQ for the respective pin.
      In the suspend entry flow, at suspend_noirq stage, the kernel disables IRQs
      that are not marked for wake. The pinctrl-intel driver does not implement a
      irq_disable()  callback (to take advantage of lazy disabling). The
      pinctrl-intel GPIO interrupts are not disabled in hardware during suspend
      entry, and thus are able to wake the SoC out of suspend-to-idle.
      This patch sets the IRQCHIP_MASK_ON_SUSPEND flag for the GPIO irq_chip, to
      disable the second level interrupts at suspend_noirq stage via the irq_mask
      callbacks. The irq_mask callback disables the IRQs in hardware by
      programming the corresponding GPIO pad registers. Only IRQs that are not
      marked for wake are disabled.
      Signed-off-by: default avatarRushikesh S Kadam <rushikesh.s.kadam@intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-and-tested-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  30. 09 Jun, 2017 1 commit