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

pinctrl: intel: Make it possible to specify mode per pin in a group

2017-06-09T11:02:50+00:00

On some SoCs not all pins in a group use the same mode when a certain
function is muxed out of them. This makes it possible to specify mode per
pin as an array instead in addition to single integer.

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

pinctrl: intel: Add support for variable size pad groups

2017-06-09T11:01:35+00:00

The Intel GPIO hardware has a concept of pad groups, which means 1 to 32
pads occupying their own GPI_IS, GPI_IE, PAD_OWN and so on registers. The
existing hardware has the same amount of pads in each pad group (except the
last one) so it is possible to use community->gpp_size to calculate start
offset of each register.

With the next generation SoCs the pad group size is not always the same
anymore which means we cannot use community->gpp_size for register offset
calculations directly.

To support variable size pad groups we introduce struct intel_padgroup that
can be filled in by the client drivers according the hardware pad group
layout. The core driver will always use these when it performs calculations
for pad register offsets. The core driver will automatically populate pad
groups based on community->gpp_size if the driver does not provide any.
This makes sure the existing drivers still work as expected.

Signed-off-by: Mika Westerberg 
Signed-off-by: Chuah, Kim Tatt 
Signed-off-by: Tan Jui Nee 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

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