linux.git/drivers/pinctrl/intel/pinctrl-intel.c, branch v4.12

pinctrl: intel: unlock on error in intel_config_set_pull()

2017-02-13T14:42:26+00:00

We need to unlock before returning -EINVAL on this error path.

Fixes: 04cc058f0c52 ("pinctrl: intel: Add support for 1k additional pull-down")
Signed-off-by: Dan Carpenter 
Signed-off-by: Linus Walleij

pinctrl: intel: Add support for 1k additional pull-down

2017-01-30T14:04:23+00:00

The next generation Intel GPIO hardware supports additional 1k pull-down
per-pad. Add support for this to the Intel core pinctrl driver.

Signed-off-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

pinctrl: intel: Add support for hardware debouncer

2017-01-30T14:01:35+00:00

The next generation Intel GPIO hardware has two additional registers
PADCFG2 and PADCFG3. The latter is marked as reserved but the former
includes configuration for per-pad hardware debouncer.

This patch adds support for that in the Intel pinctrl core driver. Since
these are additional features on top of the current generation hardware,
we use revision number and feature flags to enable this if detected.

Signed-off-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

Merge tag 'v4.10-rc6' into devel

2017-01-30T13:39:20+00:00

Linux 4.10-rc6

Resolved conflicts in:
	drivers/pinctrl/pinctrl-amd.c
	drivers/pinctrl/samsung/pinctrl-exynos.c

pinctrl: intel: Convert to use devm_gpiochip_add_data()

2017-01-11T12:52:37+00:00

This simplifies error handling and allows us to drop intel_pinctrl_remove()
completely.

Signed-off-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

pinctrl: intel: Set pin direction properly

2017-01-11T12:49:05+00:00

There are two bits in the PADCFG0 register to configure direction, one per
TX/RX buffers.

For now we wrongly assume that the GPIO is always requested before it is being
used, which is not true when the GPIO is used through irqchip. In this case the
GPIO is never requested and we never enable RX buffer for it.

Fix this by setting both bits accordingly.

Reported-by: Jarkko Nikula 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

pinctrl: intel: set default handler to be handle_bad_irq()

2016-12-07T14:26:59+00:00

We switch the default handler to be handle_bad_irq() instead of
handle_simple_irq() (which was not correct anyway).

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

pinctrl: intel: Only restore pins that are used by the driver

2016-10-18T12:38:16+00:00

Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
to explicitly disable USB touchscreen interrupt. This is done to prevent
situation where the lid is closed the touchscreen is left functional.

The pinctrl driver (wrongly) assumes it owns all pins which are owned by
host and not locked down. It is perfectly fine for BIOS to use those pins
as it is also considered as host in this context.

What happens is that when the lid of Dell XPS 13 is closed, the BIOS
configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
we restore all host owned pins to the known state which includes CPU_GP_1
and this overwrites what the BIOS has programmed there causing the
touchscreen to fail as no interrupts are reaching the CPU anymore.

Fix this by restoring only those pins we know are explicitly requested by
the kernel one way or other.

Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
Reported-by: AceLan Kao 
Tested-by: AceLan Kao 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: Configure GPIO chip IRQ as wakeup interrupts

2016-09-23T13:14:21+00:00

On some Intel BXT platform, wake-up from suspend-to-idle on pressing
power-button is not working. Its noticed that gpio-keys driver marking the
second level IRQ/power-button as wake capable but Intel pintctrl
driver is missing to mark GPIO chip/controller IRQ which first level IRQ
as wake cable if its GPIO pin IRQ is wakeble. So, though the first level
IRQ gets generated on power-button press, since it is not marked as
wake capable resume/wake-up flow is not happening.
Intel pintctrl/GPIO driver need to mark GPIO chip/controller IRQ (first
level IRQ) as wake capable iff GPIO pin's IRQ (second level IRQ) is marked
as wake cable.

Changes in v2:
 - Add missing irq initialisation.

Signed-off-by: Nilesh Bacchewar 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: Protect set wake flow by spin lock

2016-07-11T09:15:33+00:00

It seems intel_gpio_irq_wake() misses lock protection against I/O flow.
Use spin lock here as well.

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