kernel.git/drivers/pinctrl/intel/pinctrl-intel.c, branch linux-4.9.y

pinctrl: intel: Read back TX buffer state

2018-08-06T14:23:02Z

commit d68b42e30bbacd24354d644f430d088435b15e83 upstream. 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 Cc: Anthony de Boer Signed-off-by: Greg Kroah-Hartman

Revert "pinctrl: intel: Initialize GPIO properly when used through irqchip"

2018-04-29T09:31:58Z

This reverts commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mike writes: It seems that commit f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip") can cause problems on some Skylake systems with Sunrisepoint PCH-H. Namely on certain systems it may turn the backlight PWM pin from native mode to GPIO which makes the screen blank during boot. There is more information here: https://bugzilla.redhat.com/show_bug.cgi?id=1543769 The actual reason is that GPIO numbering used in BIOS is using "Windows" numbers meaning that they don't match the hardware 1:1 and because of this a wrong pin (backlight PWM) is picked and switched to GPIO mode. There is a proper fix for this but since it has quite many dependencies on commits that cannot be considered stable material, I suggest we revert commit f5a26acf0162 from stable trees 4.9, 4.14 and 4.15 to prevent the backlight issue. Reported-by: Mika Westerberg Fixes: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip") Cc: Daniel Drake Cc: Chris Chiu Cc: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: intel: Initialize GPIO properly when used through irqchip

2018-02-17T12:21:19Z

commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream. 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 Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: intel: Set pin direction properly

2017-07-05T12:40:24Z

[ Upstream commit 17fab473693e8357a9aa6fee4fbed6c13a34bd81 ] 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 Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2016-10-18T12:38:16Z

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:21Z

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:33Z

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

pinctrl: intel: Prevent force threading of the interrupt handler

2016-06-18T08:35:47Z

The pinctrl-intel needs to use request_irq() instead of chained interrupt handling because it shares the interrupt with multiple GPIO host controllers found on Intel CPUs. In -rt all such interrupts are forced to run in thread context which triggers following warning: WARNING: CPU: 0 PID: 530 at kernel/irq/handle.c:151 handle_irq_event_percpu+0x23d/0x240 irq 348 handler irq_default_primary_handler+0x0/0x10 enabled interrupts Modules linked in: CPU: 0 PID: 530 Comm: irq/14-INT3452: Not tainted 4.6.2-rt5 #1060 0000000000000000 ffff88007a257c98 ffffffff812d8494 ffff88007a257ce8 0000000000000000 ffff88007a257cd8 ffffffff8105e554 000000977a257d90 ffff88007a37a380 000000000000015c 0000000000000002 0000000000000000 Call Trace: [] dump_stack+0x4f/0x6b [] __warn+0xe4/0x100 [] warn_slowpath_fmt+0x4f/0x60 [] ? __synchronize_hardirq+0x60/0x60 [] handle_irq_event_percpu+0x23d/0x240 [] handle_irq_event+0x62/0x90 [] handle_edge_irq+0x8f/0x190 [] generic_handle_irq+0x22/0x30 [] intel_gpio_irq+0xdc/0x150 [] irq_forced_thread_fn+0x23/0x70 [] irq_thread+0x13b/0x1d0 [] ? __schedule+0x2e4/0x5a0 [] ? irq_finalize_oneshot.part.37+0xd0/0xd0 [] ? irq_thread+0x1d0/0x1d0 [] ? wake_threads_waitq+0x30/0x30 [] kthread+0xd4/0xf0 [] ? _raw_spin_unlock_irq+0x17/0x40 [] ret_from_fork+0x22/0x40 [] ? kthread_worker_fn+0x190/0x190 The handle_irq_event_* functions (and I suppose generic_handle_irq()) is expected to be called with interrupts disabled and they rightfully complain here because we run in thread context with interrupts enabled. Fix this by adding IRQF_NO_THREAD flag when the master interrupt is requested. This prevents forced threading of the interrupt used by the GPIO host controllers. Reported-by: Kim Tatt Chuah Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: intel: Use raw_spinlock for locking

2016-06-18T08:35:44Z

When running -rt kernel and GPIO interrupt happens we get following BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931 in_atomic(): 1, irqs_disabled(): 0, pid: 530, name: irq/14-INT3452: Preemption disabled at:[] handle_edge_irq+0x1b/0x190 CPU: 0 PID: 530 Comm: irq/14-INT3452: Not tainted 4.6.2-rt5 #1060 0000000000000000 ffff88007a257d58 ffffffff812d8494 0000000000000000 ffff88017a330000 ffff88007a257d78 ffffffff81083a11 ffff88007a252430 ffff88007a252430 ffff88007a257d90 ffffffff8167ef20 000000000000001a Call Trace: [] dump_stack+0x4f/0x6b [] ___might_sleep+0xe1/0x160 [] rt_spin_lock+0x20/0x50 [] intel_gpio_irq_ack+0x2d/0x80 [] handle_edge_irq+0x7b/0x190 [] generic_handle_irq+0x22/0x30 [] intel_gpio_irq+0xdc/0x150 [] irq_forced_thread_fn+0x23/0x70 [] irq_thread+0x13b/0x1d0 [] ? __schedule+0x2e4/0x5a0 [] ? irq_finalize_oneshot.part.37+0xd0/0xd0 [] ? irq_thread+0x1d0/0x1d0 [] ? wake_threads_waitq+0x30/0x30 [] kthread+0xd4/0xf0 [] ? _raw_spin_unlock_irq+0x17/0x40 [] ret_from_fork+0x22/0x40 [] ? kthread_worker_fn+0x190/0x190 The reason why this happens is because intel_gpio_irq_ack() is called with desc->lock raw_spinlock locked which cannot sleep but our normal spinlock (which is converted to rtmutex in -rt) is allowed to sleep. This causes might_sleep() to trigger. Fix this by converting the normal spinlock to a raw_spinlock. Reported-by: Kim Tatt Chuah Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v4.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2016-05-19T19:50:56Z

Pull pin control updates from Linus Walleij: "This kernel cycle was quite calm when it comes to pin control and there is really just one major change, and that is the introduction of devm_pinctrl_register() managed resources. Apart from that linear development, details below. Core changes: - Add the devm_pinctrl_register() API and switch all applicable drivers to use it, saving lots of lines of code all over the place. New drivers: - driver for the Broadcom NS2 SoC - subdriver for the PXA25x SoCs - subdriver for the AMLogic Meson GXBB SoC Driver improvements: - the Intel Baytrail driver now properly supports pin control - Nomadik, Rockchip, Broadcom BCM2835 support the .get_direction() callback in the GPIO portions - continued development and stabilization of several SH-PFC SoC subdrivers: r8a7795, r8a7790, r8a7794 etc" * tag 'pinctrl-v4.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (85 commits) Revert "pinctrl: tegra: avoid parked_reg and parked_bank" pinctrl: meson: Fix eth_tx_en bit index pinctrl: tegra: avoid parked_reg and parked_bank pinctrl: tegra: Correctly check the supported configuration pinctrl: amlogic: Add support for Amlogic Meson GXBB SoC pinctrl: rockchip: fix pull setting error for rk3399 pinctrl: stm32: Implement .pin_config_dbg_show() pinctrl: nomadik: hide nmk_gpio_get_mode when unused pinctrl: ns2: rename pinctrl_utils_dt_free_map pinctrl: at91: Merge clk_prepare and clk_enable into clk_prepare_enable pinctrl: at91: Make at91_gpio_template const pinctrl: baytrail: fix some error handling in debugfs pinctrl: ns2: add pinmux driver support for Broadcom NS2 SoC pinctrl: sirf/atlas7: trivial fix of spelling mistake on flagged pinctrl: sh-pfc: Kill unused variable in sh_pfc_remove() pinctrl: nomadik: implement .get_direction() pinctrl: nomadik: use BIT() with offsets consequently pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range pinctrl: zynq: Use devm_pinctrl_register() for pinctrl registration pinctrl: u300: Use devm_pinctrl_register() for pinctrl registration ...