| Age | Commit message (Collapse) | Author |
|---|
|
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 <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
|
|
The Intel Baytrail pinctrl driver implements irqchip callbacks which are
called with desc->lock raw_spinlock held. In mainline this is fine because
spinlock resolves to raw_spinlock. However, running the same code in -rt 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:[<ffffffff81092e9f>] cpu_startup_entry+0x17f/0x480
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13
...
Call Trace:
<IRQ> [<ffffffff816283c6>] dump_stack+0x4a/0x61
[<ffffffff81077e17>] ___might_sleep+0xe7/0x170
[<ffffffff8162d6cf>] rt_spin_lock+0x1f/0x50
[<ffffffff812e3b88>] byt_gpio_clear_triggering+0x38/0x60
[<ffffffff812e3bc1>] byt_irq_mask+0x11/0x20
[<ffffffff810a7013>] handle_level_irq+0x83/0x150
[<ffffffff810a3457>] generic_handle_irq+0x27/0x40
[<ffffffff812e3a5f>] byt_gpio_irq_handler+0x7f/0xc0
[<ffffffff810050aa>] handle_irq+0xaa/0x190
...
This is because in -rt spinlocks are preemptible so taking the driver
private spinlock in irqchip callbacks causes might_sleep() to trigger.
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.
Also shorten the critical section a bit in few places.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
There is a hardware issue in Intel Baytrail where concurrent GPIO register
access might result reads of 0xffffffff and writes might get dropped
completely.
Prevent this from happening by taking the serializing lock in all places
where it is possible that more than one thread might be accessing the
hardware concurrently.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The FSF address is already mentioned in the COPYING file. No need to
duplicate that information to individual files.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
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 <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
|
|
The BIOS might reconfigure pins as it needs when S3 is entered. This might
cause drivers using the GPIOs to fail because the state was wrong or
interrupts stopped working.
Fix this by saving and restoring enough pin context over system sleep.
Reported-by: Hans Holmberg <hans.holmberg@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Instead of handling everything in the driver's first level interrupt
handler, we can take advantage of already existing flow handlers that are
provided by the IRQ core.
This changes the functionality a bit also. Previously the driver looped
over pending interrupts in a single loop, restarting the loop if some
interrupt changed state. This caused problem with Lenovo Thinkpad 10
digitizer that it was not able to deassert the interrupt before the driver
disabled the interrupt for good (looplimit was exhausted).
Rework the interrupt handling logic a bit so that we provide proper mask,
ack and unmask operations in terms of Baytrail GPIO hardware and loop over
pending interrupts only once. If the interrupt remains asserted the first
level handler will be re-triggered automatically.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
If the pin is already configured as GPIO and it has any of the triggering
flags set, we may get spurious interrupts depending on the state of the
pin.
Prevent this by clearing the triggering flags on such pins. However, if the
pin is also configured as "direct IRQ" we leave the flags as is. Otherwise
it will prevent interrupts that are routed directly to IO-APIC.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Zotac ZBOX PI320, a Baytrail based mini-PC, has power button connected to a
GPIO pin and it is exposed to the operating system as Windows 8 button
array. This is implemented in Linux as a driver using gpio_keys.
However, BIOS on this particula machine forgot to mux the pin to be a GPIO
instead of native function, which results following message to be seen on
the console:
byt_gpio INT33FC:02: pin 16 cannot be used as GPIO.
This causes power button to not work as the driver was not able to request
the GPIO it needs.
So instead of completely preventing this we allow turning the pin as GPIO
but issue warning that something might be wrong.
Reported-by: Benjamin Adler <benadler@gmx.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control changes from Linus Walleij:
"Here is a stash of pin control changes I have collected for the v3.19
series. Mainly new hardware support, with Intels new embedded SoC as
the especially interesting thing standing out, fully using the
subsystem.
- Force conversion of the ux500 pin control device trees and parsers
to use the generic pin control bindings.
- New driver and device tree bindings for the Qualcomm PMIC MPP pin
controller and GPIO.
- Some ACPI infrastructure for pin controllers.
- New driver for the Intel CherryView/Braswell pin controller, the
first Intel pin controller to fully take advantage of the pin
control subsystem.
- Support the Freescale i.MX VF610 variant.
- Support the sunxi A80 variant.
- Support the Samsung Exynos 4415 and Exynos 7 variants.
- Split out Intel pin controllers to their own subdirectory.
- A large slew of rockchip pin control updates, including
suspend/resume support.
- A large slew of Samsung Exynos pin controller updates.
- Various minor updates and fixes"
* tag 'pinctrl-v3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (49 commits)
pinctrl: at91: enhance (debugfs) at91_gpio_dbg_show
pinctrl: meson: add device tree bindings documentation
gpio: tz1090: Fix error handling of irq_of_parse_and_map
pinctrl: tz1090-pinctrl.txt: Fix typo in binding
pinctrl: pinconf-generic: Declare dt_params/conf_items const
pinctrl: exynos: Add support for Exynos4415
pinctrl: exynos: Add initial driver data for Exynos7
pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts
pinctrl: exynos: Consolidate irq domain callbacks
pinctrl: exynos: Generalize the eint16_31 demux code
pinctrl: samsung: Separate per-bank init and runtime data
pinctrl: samsung: Constify samsung_pin_ctrl struct
pinctrl: samsung: Constify samsung_pin_bank_type struct
pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct
pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()
pinctrl: Add Intel Cherryview/Braswell pin controller support
gpio / ACPI: Add knowledge about pin controllers to acpi_get_gpiod()
pinctrl: Fix path error in documentation
pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume
pinctrl: rockchip: add suspend/resume functions
...
|
|
We are going to have more pinctrl drivers for Intel hardware so separate
all our pin controller drivers to own directory.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
