- 16 Oct, 2015 7 commits
-
-
Laurent Pinchart authored
When requesting a GPIO through the legacy or the gpiod_* API the gpiochip request operation is first called and then the GPIO flags are parsed and the GPIO is configured. This prevents the gpiochip from rejecting the request if the flags are not supported by the device. To fix this split the parse-and-configure operation in two and parse flags before requesting the GPIO. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Jonas Gorski authored
Replace all trivial request/free callbacks that do nothing but call into pinctrl code with the generic versions. Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Acked-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Andrew Bresticker <abrestic@chromium.org> Acked-by:
Baruch Siach <baruch@tkos.co.il> Acked-by:
Matthias Brugger <matthias.bgg@gmail.com> Acked-by:
Lee Jones <lee@kernel.org> Acked-by:
Laxman Dewangan <ldewangan@nvidia.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Jonas Gorski authored
Instead of storing in the chip data whether the chip uses pinctrl and conditionally call pinctrl_{request,free}_gpio, just don't populate request/free in that case. This makes the implementations trivial and the same as the generic implementations, thus we can just use them. Signed-off-by: -
Jonas Gorski authored
Instead of storing in the chip data whether the chip uses pinctrl and conditionally call pinctrl_{request,free}_gpio, just don't populate request/free in that case. This makes the implementations trivial and the same as the generic implementations, thus we can just use them. Signed-off-by: -
Jonas Gorski authored
Replace all trivial request/free callbacks that do nothing but call into pinctrl code with the generic versions. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
James Hogan <james.hogan@imgtec.com> Acked-by:
Stefan Agner <stefan@agner.ch> Acked-by:
Joachim Eastwood <manabian@gmail.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Jonas Gorski authored
Provide generic request/free implementations that pinctrl aware gpio drivers can use instead of open coding if they use a 1:1 pin to gpio signal mapping. Signed-off-by:
-
Grygorii Strashko authored
This patch fixes below static checker warning by changing type of irq field in struct gpio_bank from u16 to int. drivers/gpio/gpio-omap.c:1191 omap_gpio_probe() warn: assigning (-6) to unsigned variable 'bank->irq' drivers/gpio/gpio-omap.c 1188 bank->irq = platform_get_irq(pdev, 0); 1189 if (bank->irq <= 0) { bank->irq is u16. 1190 if (!bank->irq) 1191 bank->irq = -ENXIO; Does not work. 1192 if (bank->irq != -EPROBE_DEFER) Does not work. 1193 dev_err(dev, 1194 "can't get irq resource ret=%d\n", bank->irq); 1195 return bank->irq; 1196 } Fixes: commit 89d18e3a: "gpio: omap: switch to use platform_get_irq" Signed-off-by:Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
- 15 Oct, 2015 2 commits
-
-
Linus Walleij authored
The PL061 can handle level IRQs and edge IRQs, however it is just utilizing handle_simple_irq() for all IRQs. Inspired by Stefan Agners patch to vf610, this assigns the right handler depending on what type is set up, and after this handle_bad_irq() is only used as default and if the type is not specified, as is done in the OMAP driver: defining the IRQ type is really not optional for this driver. The interrupt handler was just writing the interrupt clearing register for all lines that were high when entering the handling loop, this is wrong: that register is only supposed to be written (on a per-line basis) for edge IRQs, so this ACK was moved to the .irq_ack() callback as is proper. Tested with PL061 on the ARM RealView PB11MPCore and the MMC/SC card detect GPIO. Cc: Jonas Gorski <jogo@openwrt.org> Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: -
Dan Carpenter authored
We were returning with "chip->lock" held by mistake. It's safe to move the return to before we take the spinlock. Fixes: 1dbf7f29 ('gpio: pl061: detail IRQ trigger handling') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 05 Oct, 2015 6 commits
-
-
Linus Walleij authored
This reverts commit ddd54040. We need to preserve only using this naming strategy for names coming from chip->names[], the descripor->name field is for the new interface.
-
Andy Shevchenko authored
This patch adds a support of the expandes found on Intel Galileo Gen2 board. The platform information comes from ACPI. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of using id->driver_data directly we copied it to the internal structure. This will help to adapt driver for ACPI use. Signed-off-by:
-
Heiner Kallweit authored
Use the ERRPTR standard way to return an error code in a pointer thus simplifiying the code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Replace devm_request_mem_region / devm_ioremap with devm_ioremap_resource. Signed-off-by:
-
Heiner Kallweit authored
If bgpio_map returns NULL then err should always be set. Signed-off-by:
-
- 02 Oct, 2015 17 commits
-
-
Thierry Reding authored
The TCA9539 is almost identical to the PCA9555 and software-compatible with this driver. It exposes 16 general purpose I/O pins in two 8-bit configurations. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Julia Lawall authored
The function __max730x_remove is called from the remove functions of drivers/gpio/gpio-max7300.c and drivers/gpio/gpio-max7301.c. In both cases, the probe function allocates ts using devm_kzalloc. Explicitly freeing such a value with kfree will cause a double free. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
Grygorii Strashko authored
This patch converts TI OMAP GPIO driver to use generic irq handler instead of chained IRQ handler. This way OMAP GPIO driver will be compatible with RT kernel where it will be forced thread IRQ handler while in non-RT kernel it still will be executed in HW IRQ context. As part of this change the IRQ wakeup configuration is applied to GPIO Bank IRQ as it now will be under control of IRQ PM Core during suspend. There are also additional benefits: - on-RT kernel there will be no complains any more about PM runtime usage in atomic context "BUG: sleeping function called from invalid context"; - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic will be visible; - GPIO bank IRQs could be configured through IRQ proc_fs interface and, as result, could be a part of IRQ balancing process if needed; - GPIO bank IRQs will be under control of IRQ PM Core during suspend to RAM. Disadvantage: - additional runtime overhed as call chain till omap_gpio_irq_handler() will be longer now - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning in handle_irq_event_percpu() WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 handle_irq_event_percpu+0x51c/0x638() This patch doesn't fully follows recommendations provided by Sebastian Andrzej Siewior [1], because It's required to go through and check all GPIO IRQ pin states as fast as possible and pass control to handle_level_irq or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions specific for IRQ triggering type and wakeup corresponding registered threaded IRQ handler (at least it's expected to be threaded). IRQs can be lost if handle_nested_irq() will be used, because excecution time of some pin specific GPIO IRQ handler can be very significant and require accessing ext. devices (I2C). Idea of such kind reworking was also discussed in [2]. [1] http://www.spinics.net/lists/linux-omap/msg120665.html [2] http://www.spinics.net/lists/linux-omap/msg119516.htmlTested-by:Tony Lindgren <tony@atomide.com> Tested-by:
Austin Schuh <austin@peloton-tech.com> Signed-off-by:
Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by:
-
Grygorii Strashko authored
The PM runtime API can't be used in atomic contex on -RT even if it's configured as irqsafe. As result, below error report can be seen when PM runtime API called from IRQ chip's callbacks irq_startup/irq_shutdown/irq_set_type, because they are protected by RAW spinlock: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: insmod 3 locks held by insmod/96: #0: (&dev->mutex){......}, at: [<c04752c8>] __driver_attach+0x54/0xa0 #1: (&dev->mutex){......}, at: [<c04752d4>] __driver_attach+0x60/0xa0 #2: (class){......}, at: [<c00a408c>] __irq_get_desc_lock+0x60/0xa4 irq event stamp: 1834 hardirqs last enabled at (1833): [<c06ab2a4>] _raw_spin_unlock_irqrestore+0x88/0x90 hardirqs last disabled at (1834): [<c06ab068>] _raw_spin_lock_irqsave+0x2c/0x64 softirqs last enabled at (0): [<c003d220>] copy_process.part.52+0x410/0x19d8 softirqs last disabled at (0): [< (null)>] (null) Preemption disabled at:[< (null)>] (null) CPU: 1 PID: 96 Comm: insmod Tainted: G W O 4.1.3-rt3-00618-g57e2387-dirty #184 Hardware name: Generic DRA74X (Flattened Device Tree) [<c00190f4>] (unwind_backtrace) from [<c0014734>] (show_stack+0x20/0x24) [<c0014734>] (show_stack) from [<c06a62ec>] (dump_stack+0x88/0xdc) [<c06a62ec>] (dump_stack) from [<c006ca44>] (___might_sleep+0x198/0x2a8) [<c006ca44>] (___might_sleep) from [<c06ab6d4>] (rt_spin_lock+0x30/0x70) [<c06ab6d4>] (rt_spin_lock) from [<c04815ac>] (__pm_runtime_resume+0x68/0xa4) [<c04815ac>] (__pm_runtime_resume) from [<c04123f4>] (omap_gpio_irq_type+0x188/0x1d8) [<c04123f4>] (omap_gpio_irq_type) from [<c00a64e4>] (__irq_set_trigger+0x68/0x130) [<c00a64e4>] (__irq_set_trigger) from [<c00a7bc4>] (irq_set_irq_type+0x44/0x6c) [<c00a7bc4>] (irq_set_irq_type) from [<c00abbf8>] (irq_create_of_mapping+0x120/0x174) [<c00abbf8>] (irq_create_of_mapping) from [<c0577b74>] (of_irq_get+0x48/0x58) [<c0577b74>] (of_irq_get) from [<c0540a14>] (i2c_device_probe+0x54/0x15c) [<c0540a14>] (i2c_device_probe) from [<c04750dc>] (driver_probe_device+0x184/0x2c8) [<c04750dc>] (driver_probe_device) from [<c0475310>] (__driver_attach+0x9c/0xa0) [<c0475310>] (__driver_attach) from [<c0473238>] (bus_for_each_dev+0x7c/0xb0) [<c0473238>] (bus_for_each_dev) from [<c0474af4>] (driver_attach+0x28/0x30) [<c0474af4>] (driver_attach) from [<c0474760>] (bus_add_driver+0x154/0x200) [<c0474760>] (bus_add_driver) from [<c0476348>] (driver_register+0x88/0x108) [<c0476348>] (driver_register) from [<c0541600>] (i2c_register_driver+0x3c/0x90) [<c0541600>] (i2c_register_driver) from [<bf003018>] (pcf857x_init+0x18/0x24 [gpio_pcf857x]) [<bf003018>] (pcf857x_init [gpio_pcf857x]) from [<c000998c>] (do_one_initcall+0x128/0x1e8) [<c000998c>] (do_one_initcall) from [<c06a4220>] (do_init_module+0x6c/0x1bc) [<c06a4220>] (do_init_module) from [<c00dd0c8>] (load_module+0x18e8/0x21c4) [<c00dd0c8>] (load_module) from [<c00ddaa0>] (SyS_init_module+0xfc/0x158) [<c00ddaa0>] (SyS_init_module) from [<c000ff40>] (ret_fast_syscall+0x0/0x54) The IRQ chip interface defines only two callbacks which are executed in non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move PM runtime calls there. Tested-by: -
Linus Walleij authored
It is customary for GPIO controllers to support open drain/collector and open source/emitter configurations. Add standard GPIO line flags to account for this and augment the documentation to say that these are the most generic bindings. Several people approached me to add new flags to the lines, and this makes sense, but let's first bind up the most common cases before we start to add exotic stuff. Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended wiring such as open drain/source and open collector/emitter. Cc: Tony Lindgren <tony@atomide.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: -
Diego Elio Pettenò authored
This patch adds support for the GPIOs found on the ITE super-I/O chips IT87xx. Signed-off-by:
Diego Elio Pettenò <flameeyes@flameeyes.eu> Signed-off-by:
Christophe Vu-Brugier <cvubrugier@fastmail.fm> Signed-off-by:
-
Dirk Behme authored
The parameter offset is an unsigned, so it makes no sense to compare it for >= 0. Fix the compiler warning regarding this by removing this comparison. As the macro GPIO_OFFSET_VALID is only used at this single place, simplify the code by dropping the macro completely and dropping the invert, too. No functional change. Signed-off-by:
Dirk Behme <dirk.behme@gmail.com> Acked-by:
-
Richard Fitzgerald authored
Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
-
Nicholas Krause authored
This fixes error checking in the function device_pca957x_init to properly check and return error code values from the calls to the function pca953x_write_regs if they fail as to properly signal callers when a error occurs due a failure when writing registers for this gpio based device. Signed-off-by:
Nicholas Krause <xerofoify@gmail.com> Reviewed-by:
-
Alban Bedel authored
Turn the ath79 driver into a true driver supporting multiple instances. While at it also removed unneed includes and make use of the BIT() macro. Signed-off-by:
Alban Bedel <albeu@free.fr> Signed-off-by:
-
Stephen Boyd authored
Remove this driver now that Bjorn has introduced a pinctrl driver for msm8660 and the dts files have been updated with the pinctrl compatibles. Cc: Andy Gross <agross@codeaurora.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Linus Walleij authored
The state container of the Zynq GPIO driver is sometimes extracted from the gpio_chip exploiting the fact that offsetof() the struct gpio_chip inside the struct zynq_gpio is 0, so the container_of() is in practice a noop. However if a member is added to struct zynq_gpio in front of struct gpio_chip, things will break. Using proper container_of() avoids this problem. Semantically this is a noop, the compiler will optimize it away, but syntactically it makes me happier. Also replace some explicit container_of() calls with the helper function. Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Ezra Savard <ezra.savard@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com> Acked-by:
Harini Katakam <harinik@xilinx.com> Signed-off-by:
-
Linus Walleij authored
The state container of the vf610 GPIO driver is sometimes extracted from the gpio_chip exploiting the fact that offsetof() the struct gpio_chip inside the struct vf610_gpio_port is 0, so the container_of() is in practice a noop. However if a member is added to struct vf610_gpio_port in front of struct gpio_chip, things will break. Using proper container_of() avoids this problem. Semantically this is a noop, the compiler will optimize it away, but syntactically it makes me happier. Also replace some explicit container_of() calls with the helper function. Acked-by:
-
Linus Walleij authored
The state container of the sx150x GPIO driver is sometimes extracted from the gpio_chip exploiting the fact that offsetof() the struct gpio_chip inside the struct sx150x_chip is 0, so the container_of() is in practice a noop. However if a member is added to struct sx150_chip in front of struct gpio_chip, things will break. Using proper container_of() avoids this problem. Semantically this is a noop, the compiler will optimize it away, but syntactically it makes me happier. Cc: Wei Chen <Wei.Chen@csr.com> Signed-off-by: -
Linus Walleij authored
The state container of the Altera GPIO driver is extracted from the gpio_chip exploiting the fact that offsetof() the struct gpio_chip inside the struct of_mm_gpio_chip are both 0, so the container_of() is in practice a noop. However if a member is added to struct altera_gpio_chip in front of struct of_mm_gpio_chip, things will break. Using proper container_of() avoids this problem. Semantically this is a noop, the compiler will optimize it away, but syntactically it makes me happier. Cc: Tien Hock Loh <thloh@altera.com> Signed-off-by: -
Linus Walleij authored
The state container of the etraxfs GPIO driver is extracted from the gpio_chip exploiting the fact that offsetof() the struct gpio_chip inside the struct bgpio_chip are both 0, so the container_of() is in practice a noop. However if a member is added to struct etraxfs_gpio_chip in front of struct bgpio_chip, things will break. Using proper container_of() avoids this problem. Semantically this is a noop, the compiler will optimize it away, but syntactically it makes me happier. Acked-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
-
Linus Walleij authored
I couldn't follow this code flow. Make it dirt simple to figure out what is going on and get proper debug prints. Warn if we set up an IRQ without any trigger. Should make no semantic difference. Signed-off-by:
-
- 24 Sep, 2015 6 commits
-
-
Linus Walleij authored
This refactors the changes to the GPIO line naming mechanism to not have so widespread effects, instead we conclude the patch series by having created a name attribute in the GPIO descriptor, that need not be globally unique, and it will be initialized from the old .names array in struct gpio_chip if it exists, then used in the legacy sysfs code like the array was used previously. The associated changes to name lines from the device tree are controversial and need to stand alone from this. Resulting changes: 1. Remove the export and the header for the gpio_name_to_desc() as so far the only use is inside gpiolib.c. Staticize gpio_name_to_desc() and move it above the only function using it. 2. Only print a warning if there are two GPIO lines with the same name. The reason is to preserve current behaviour: before the previous changes to the naming mechanism this would not reject probing the driver, instead the error would occur when trying to export the line in sysfs, so restore this behaviour, but print a friendly warning if names collide. Cc: Johan Hovold <johan@kernel.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: -
Markus Pargmann authored
Add some information about gpio names to the debugfs gpio file. name and label of a GPIO are then displayed next to each other. This way it is easy to see what the real name of GPIO is and what the driver requested it for. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> [Dropped unsolicited sysfs ABI patch hunk] Signed-off-by:
-
Markus Pargmann authored
The name is now stored in the gpio descriptor as well, for example to allow to store names from DT. This patch changes the sysfs gpio files to use the gpio descriptor name. Signed-off-by:
-
Markus Pargmann authored
This patch adds GPIO names to the GPIO descriptors when initializing the gpiochip. It also introduces a check whether any of the new names will conflict with an existing GPIO name. Signed-off-by:
-
Markus Pargmann authored
The latest gpio hogging mechanism assigns each gpio a 'line-name' in the devicetree. The 'name' field is different from the 'label' field. 'label' is only used for requested GPIOs to describe its current use by driver or userspace. The 'name' field describes the GPIO itself, not the use. This is most likely identical to the label in the schematic on the GPIO line and should help to find this particular GPIO. This is equivalent to the gpiochip->names array. However names should be stored in the GPIO descriptor. We will use gpiochip->names in the future only as initializer for the GPIO descriptors for drivers that assign GPIO names hardcoded. All other GPIO names will be parsed from DT and directly assigned to the GPIO descriptor. This patch adds a helper function to find gpio descriptors by name instead of gpio number. Signed-off-by:
-
Markus Pargmann authored
The gpio hogging functions are currently only used for gpio-hogging. But these functions are widely generic ones which parse gpio device nodes in the DT. Signed-off-by:
-
- 20 Sep, 2015 2 commits
-
-
Linus Torvalds authored
-
git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: "Three fixes and a resulting cleanup for -rc2: - Andre Przywara reported that he was seeing a warning with the new cast inside DMA_ERROR_CODE's definition, and fixed the incorrect use. - Doug Anderson noticed that kgdb causes a "scheduling while atomic" bug. - OMAP5 folk noticed that their Thumb-2 compiled X servers crashed when enabling support to cover ARMv6 CPUs due to a kernel bug leaking some conditional context into the signal handler" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints ARM: 8437/1: dma-mapping: fix build warning with new DMA_ERROR_CODE definition ARM: get rid of needless #if in signal handling code ARM: fix Thumb2 signal handling when ARMv6 is enabled
-
