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

pinctrl: intel: Implement intel_gpio_get_direction callback

2018-03-23T03:07:22+00:00

Allows querying GPIO direction from the pad config register.
If the pad is not in GPIO mode, return an error.

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

pinctrl: intel: ensure error return ret is initialized

2017-12-07T08:59:39+00:00

In the (unlikely) event that community->ngpps is zero, or if every
gpp->gpio_base is less than zero, then an ininitialized value in
ret is returned by function intel_gpio_add_pin_ranges. Fix this by
ensuring ret is initialized to zero.  It's a moot point, but I think
it is worthwhile ensuring this corner case is fixed.

Detected by CoverityScan, CID#1462415 ("Uninitialized scalar variable")

Fixes: a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups")
Signed-off-by: Colin Ian King 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: Initialize GPIO properly when used through irqchip

2017-12-02T12:11:04+00:00

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: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
Reported-by: Daniel Drake 
Reported-and-tested-by: Chris Chiu 
Signed-off-by: Mika Westerberg 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij

pinctrl: intel: Allow custom GPIO base for pad groups

2017-11-29T12:44:52+00:00

Currently we always have direct mapping between GPIO numbers and the
hardware pin numbers. However, there are cases where that's not the case
anymore (more about this in the next patch). Instead we need to be able
to specify custom GPIO base for certain pad groups.

To support this, add a new field (gpio_base) to the pad group structure
and update the core Intel pinctrl driver to handle this accordingly.
Passing 0 as gpio_base will use direct mapping so the existing drivers
do not need to be modified. Passing -1 excludes the whole pad group from
having GPIO mapping.

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

Merge branch 'gpio-irqchip-rework' of /home/linus/linux-gpio into devel

2017-11-09T08:38:42+00:00

gpio: Move irqdomain into struct gpio_irq_chip

2017-11-08T13:06:21+00:00

In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.

Signed-off-by: Thierry Reding 
Acked-by: Grygorii Strashko 
Signed-off-by: Linus Walleij

pinctrl: intel: Make offset to interrupt status register configurable

2017-10-31T09:10:24+00:00

Some GPIO blocks have the interrupt status (GPI_IS) offset different
than it normally is, so make it configurable. If no offset is specified
we use the default.

While there remove two unused constants from the core driver.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: Read back TX buffer state

2017-08-31T13:34:31+00:00

In the same way as it's done in pinctrl-cherryview.c we would provide
a readback TX buffer state.

Fixes: 17fab473693 ("pinctrl: intel: Set pin direction properly")
Reported-by: "Bourque, Francis" 
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Tested-by: "Bourque, Francis" 
Signed-off-by: Linus Walleij

pinctrl: intel: Decrease indentation in intel_gpio_set()

2017-08-31T12:46:36+00:00

Decrease indentation in intel_gpio_set() to make it looking slightly better
and be in align with intel_gpio_get().

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

pinctrl: intel: Disable GPIO pin interrupts in suspend

2017-08-22T12:46:15+00:00

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: Rushikesh S Kadam 
Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Reviewed-and-tested-by: Rajneesh Bhardwaj 
Signed-off-by: Linus Walleij