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

pinctrl: cherryview: Do not mask all interrupts in probe

2017-03-26T10:13:17Z

commit bcb48cca23ec9852739e4a464307fa29515bbe48 upstream. The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC which can be used directly by the platform/BIOS or drivers. One such wire is used as SCI (System Control Interrupt) which ACPI depends on to be able to trigger GPEs (General Purpose Events). The pinctrl driver itself uses another IRQ resource which is wire OR of all the 8 (or 16) wires and follows what BIOS has programmed to the IntSel register of each pin. Currently the driver masks all interrupts at probe time and this prevents these direct interrupts from working as expected. The reason for this is that some early stage prototypes had some pins misconfigured causing lots of spurious interrupts. We fix this by leaving the interrupt mask untouched. This allows SCI and other direct interrupts work properly. What comes to the possible spurious interrupts we switch the default handler to be handle_bad_irq() instead of handle_simple_irq() (which was not correct anyway). Reported-by: Yu C Chen Reported-by: Anisse Astier Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Prevent possible interrupt storm on resume

2016-11-18T09:48:34Z

commit d2cdf5dc58f6970e9d9d26e47974c21fe87983f3 upstream. When the system is suspended to S3 the BIOS might re-initialize certain GPIO pins back to their original state or it may re-program interrupt mask of others. For example Acer TravelMate B116-M had BIOS bug where certain GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the pin state was high once the BIOS gave control to the OS on resume. This triggers lots of messages like: irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview] ->action(): (null) IRQ_NOPROBE set We reset the mask back to known state in chv_pinctrl_resume() but that is called only after device interrupts have already been enabled. Now, this particular issue was fixed by upgrading the BIOS to the latest (v1.23) but not everybody upgrades their BIOSes so we fix it up in the driver as well. Prevent the possible interrupt storm by moving suspend and resume hooks to be called at _noirq time instead. Since device interrupts are still disabled we can restore the mask back to known state before interrupt storm happens. Reported-by: Christian Steiner Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Serialize register access in suspend/resume

2016-11-18T09:48:34Z

commit 56211121c0825cd188caad05574fdc518d5cac6f upstream. If async suspend is enabled, the driver may access registers concurrently with another instance which may fail because of the bug in Cherryview GPIO hardware. Prevent this by taking the shared lock while accessing the hardware in suspend and resume hooks. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: prevent concurrent access to GPIO controllers

2016-08-20T16:09:17Z

commit 0bd50d719b004110e791800450ad204399100a86 upstream. Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor series, a common lock must be used to prevent concurrent accesses across the 4 GPIO controllers managed by this driver. See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), errata #CHT34, for further information. Signed-off-by: Dan O'Donovan Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: replace trivial implementations of gpio_chip request/free

2015-10-16T20:20:21Z

Replace all trivial request/free callbacks that do nothing but call into pinctrl code with the generic versions. Signed-off-by: Jonas Gorski Acked-by: Bjorn Andersson Acked-by: Heiko Stuebner Acked-by: Eric Anholt Acked-by: Mika Westerberg Acked-by: Andrew Bresticker Acked-by: Baruch Siach Acked-by: Matthias Brugger Acked-by: Lee Jones Acked-by: Laxman Dewangan Acked-by: Maxime Ripard Signed-off-by: Linus Walleij

genirq: Remove irq argument from irq flow handlers

2015-09-16T13:47:51Z

Most interrupt flow handlers do not use the irq argument. Those few which use it can retrieve the irq number from the irq descriptor. Remove the argument. Search and replace was done with coccinelle and some extra helper scripts around it. Thanks to Julia for her help! Signed-off-by: Thomas Gleixner Cc: Julia Lawall Cc: Jiang Liu

pinctrl: cherryview: Use raw_spinlock for locking

2015-08-26T07:27:39Z

When running -rt kernel and an interrupt happens on a GPIO line controlled by Intel Cherryview/Braswell pinctrl driver we get: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0 Preemption disabled at:[] cpu_startup_entry+0x17f/0x480 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16 ... Call Trace: [] dump_stack+0x4a/0x61 [] ___might_sleep+0xe7/0x170 [] rt_spin_lock+0x1f/0x50 [] chv_gpio_irq_ack+0x3d/0xa0 [] handle_edge_irq+0x75/0x180 [] generic_handle_irq+0x27/0x40 [] chv_gpio_irq_handler+0x7e/0x110 [] handle_irq+0xaa/0x190 ... This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack() is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock which in -rt is an rt-mutex causing might_sleep() rightfully to complain about sleeping function called from invalid context. In order to keep -rt happy but at the same time make sure that register accesses get serialized, convert the driver to use raw_spinlock instead. Suggested-by: Linus Walleij Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: cherryview: Serialize all register access

2015-08-13T11:20:02Z

There is a hardware issue in Intel Braswell/Cherryview where concurrent GPIO register access might results reads of 0xffffffff and writes might get dropped. Prevent this from happening by taking the serializing lock for all places where it is possible that more than one thread might be accessing the hardware concurrently. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc

2015-07-17T19:56:20Z

Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu Cc: Linus Walleij Cc: linux-gpio@vger.kernel.org Signed-off-by: Thomas Gleixner

pinctrl/cherryview: Use irq_set_handler_locked()

2015-07-17T19:56:17Z

Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle. Signed-off-by: Thomas Gleixner Cc: Jiang Liu Cc: Julia Lawall Cc: Linus Walleij Cc: linux-gpio@vger.kernel.org