linux.git/drivers/pinctrl/intel/pinctrl-intel.c, branch v5.5

pinctrl: intel: Missed type change to unsigned int

2019-11-07T09:10:02+00:00

We converted 'unsigned' type to be 'unsigned int' in the driver,
but there are couple of leftovers. So, finish the task now.

Signed-off-by: Andy Shevchenko

pinctrl: intel: Use helper to restore register values on ->resume()

2019-10-30T14:05:18+00:00

We can restore only values that had been changed and do not spam kernel log
with unnecessary messages. Convert intel_gpio_update_pad_mode() to a helper
function that will be used across few callers.

Suggested-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg

pinctrl: intel: Drop level from warning to debug in intel_restore_hostown()

2019-10-30T14:05:18+00:00

Since we didn't get any new reports from users about wrong settings
of pad ownership, there is no point to spam kernel log with it. Thus,
drop level from warning to debug.

Also, modify format to be in align with the rest restore helpers.

Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg

pinctrl: intel: Introduce intel_restore_intmask() helper

2019-10-30T14:05:18+00:00

Refactor restoring GPI_IE registers by using an introduced helper.

Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg

pinctrl: intel: Introduce intel_restore_hostown() helper

2019-10-30T14:05:18+00:00

Refactor restoring HOSTSW_OWN registers by using an introduced helper.

Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg

pinctrl: intel: Introduce intel_restore_padcfg() helper

2019-10-30T14:05:18+00:00

Deduplicate restoring PADCFGx registers by using a common helper.

Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg

pinctrl: intel: Avoid potential glitches if pin is in GPIO mode

2019-10-30T14:05:18+00:00

When consumer requests a pin, in order to be on the safest side,
we switch it first to GPIO mode followed by immediate transition
to the input state. Due to posted writes it's luckily to be a single
I/O transaction.

However, if firmware or boot loader already configures the pin
to the GPIO mode, user expects no glitches for the requested pin.
We may check if the pin is pre-configured and leave it as is
till the actual consumer toggles its state to avoid glitches.

Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
Depends-on: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
Cc: stable@vger.kernel.org
Cc: fei.yang@intel.com
Reported-by: Oliver Barta 
Reported-by: Malin Jonsson 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mika Westerberg

pinctrl: intel: Allocate IRQ chip dynamic

2019-10-01T14:36:07+00:00

Keeping the IRQ chip definition static shares it with multiple instances of
the GPIO chip in the system. This is bad and now we get this warning from
GPIO library:

"detected irqchip that is shared with multiple gpiochips: please fix the driver."

Hence, move the IRQ chip definition from being driver static into the struct
intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance.

Fixes: ee1a6ca43dba ("pinctrl: intel: Add Intel Broxton pin controller support")
Depends-on: 5ff56b015e85 ("pinctrl: intel: Disable GPIO pin interrupts in suspend")
Reported-by: Federico Ricchiuto 
Suggested-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mika Westerberg

pinctrl: intel: mark intel_pin_to_gpio __maybe_unused

2019-09-09T10:11:42+00:00

The intel_pin_to_gpio() function is only called by the
PM support functions and causes a warning when those are disabled:

drivers/pinctrl/intel/pinctrl-intel.c:841:12: error: unused function 'intel_pin_to_gpio' [-Werror,-Wunused-function]

Mark it __maybe_unused to suppress the warning.

Suggested-by: Andy Shevchenko 
Signed-off-by: Arnd Bergmann 
Reviewed-by: Chris Chiu 
Acked-by: Andy Shevchenko 
Signed-off-by: Mika Westerberg

pinctrl: intel: remap the pin number to gpio offset for irq enabled pin

2019-08-19T09:41:44+00:00

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: c538b9436751 ("pinctrl: intel: Only restore pins that are used by the driver")
Signed-off-by: Chris Chiu 
Acked-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko