aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/gpio (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-04-05gpio: support native single-ended hardware driversLinus Walleij1-1/+24
Some GPIO controllers has a special hardware bit we can flip to support open drain / source. This means that on these hardwares we do not need to emulate OD/OS by setting the line to input instead of actively driving it high/low. Add an optional vtable callback to the driver set_single_ended() so that driver can implement this in hardware if they have it. We may need a pinctrl_gpio_set_config() call at some point to propagate this down to a backing pin control device on systems with split GPIO/pin control. Reported-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-23gpio: Add devm_ apis for gpiochip_add_data and gpiochip_removeLaxman Dewangan1-0/+4
Add device managed APIs devm_gpiochip_add_data() and devm_gpiochip_remove() for the APIs gpiochip_add_data() and gpiochip_remove(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
2016-02-19gpio: store reflect the label to userspaceLinus Walleij1-1/+2
The gpio_chip label is useful for userspace to understand what kind of GPIO chip it is dealing with. Let's store a copy of this label in the gpio_device, add it to the struct passed to userspace for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-16gpio: create an API to detect open drain/source on linesLinus Walleij1-0/+4
My left hand merges code to privatize the descriptor handling while my right hand merges drivers that poke around and disrespect with the same gpiolib internals. So let's expose the proper APIs for drivers to ask the gpiolib core if a line is marked as open drain or open source and get some order around things so this driver compiles again. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-16gpio: move the subdriver data pointer into gpio_deviceLinus Walleij1-6/+1
We move to manage this pointer under gpiolib control rather than leave it in the subdevice's gpio_chip. We can not NULL it after gpiochip_remove so at to keep things tight. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-16gpio: move the pin ranges into gpio_deviceLinus Walleij1-9/+0
Instead of keeping this reference to the pin ranges in the client driver-supplied gpio_chip, move it to the internal gpio_device as the drivers have no need to inspect this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-11gpio/pinctrl: sunxi: stop poking around in private varsLinus Walleij1-0/+1
This kind of hacks disturbs the refactoring of the gpiolib. The descriptor table belongs to the gpiolib, if we want to know something about something in it, use or define the proper accessor functions. Let's add this gpiochip_lins_is_irq() to do what the sunxi driver is trying at so we can privatize the descriptors properly. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-11gpio: move descriptors into gpio_deviceLinus Walleij1-2/+0
We need gpio_device to hold the descriptors so that they can be lifecycled with the struct gpio_device held from userspace. Move the descriptor array into gpio_device. Also rename it from "desc" (singularis) to "descs" (pluralis) to reflect the fact that it is an array. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-11gpio: move sysfs mock device to the gpio_deviceLinus Walleij1-2/+0
Since gpio_device is the struct that survives if the backing gpio_chip is removed, move the sysfs mock device to this state container so it becomes part of the dangling state of the GPIO device on removal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-09gpio: make the gpiochip a real deviceLinus Walleij1-3/+4
GPIO chips have been around for years, but were never real devices, instead they were piggy-backing on a parent device (such as a platform_device or amba_device) but this was always optional. GPIO chips could also exist without any device at all, with its struct device *parent (ex *dev) pointer being set to null. When sysfs was in use, a mock device would be created, with the optional parent assigned, or just floating orphaned with NULL as parent. If sysfs is active, it will use this device as parent. We now create a gpio_device struct containing a real struct device and move the subsystem over to using that. The list of struct gpio_chip:s is augmented to hold struct gpio_device:s and we find gpio_chips:s by first looking up the struct gpio_device. The struct gpio_device is designed to stay around even if the gpio_chip is removed, so as to satisfy users in userspace that need a backing data structure to hold the state of the session initiated with e.g. a character device even if there is no physical chip anymore. From this point on, gpiochips are devices. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-13gpio: generic: make bgpio_pdata always visibleArnd Bergmann1-2/+2
Board files that define their own bgpio_pdata are broken when CONFIG_GPIO_GENERIC is disabled and the bgpio_pdata structure definition is hidden by the #ifdef: arch/arm/mach-clps711x/board-autcpu12.c:148:15: error: variable 'autcpu12_mmgpio_pdata' has initializer but incomplete type static struct bgpio_pdata autcpu12_mmgpio_pdata __initdata = { arch/arm/mach-clps711x/board-autcpu12.c:149:2: error: unknown field 'base' specified in initializer .base = AUTCPU12_MMGPIO_BASE, Since the board files should generally not care what drivers are enabled, this makes the structure definition visible again. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0f4630f3720e ("gpio: generic: factor into gpio_chip struct") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-05gpio: generic: factor into gpio_chip structLinus Walleij1-0/+54
The separate struct bgpio_chip has been a pain to handle, both by being confusingly similar in name to struct gpio_chip and for being contained inside a struct so that struct gpio_chip is contained in a struct contained in a struct, making several steps of dereferencing necessary. Make things simpler: include the fields directly into <linux/gpio/driver.h>, #ifdef:ed for CONFIG_GENERIC_GPIO, and get rid of the <linux/basic_mmio_gpio.h> altogether. Prefix some of the member variables with bgpio_* and add proper kerneldoc while we're at it. Modify all users to handle the change and use a struct gpio_chip directly. And while we're at it: replace all container_of() dereferencing by gpiochip_get_data() and registering the gpio_chip with gpiochip_add_data(). Cc: arm@kernel.org Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Kukjin Kim <kgene@kernel.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Olof Johansson <olof@lixom.net> Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Rabin Vincent <rabin@rab.in> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-01-05gpio: add a data pointer to gpio_chipLinus Walleij1-1/+13
This adds a void * pointer to gpio_chip so that driver can assign and retrieve some states. This is done to get rid of container_of() calls for gpio_chips embedded inside state containers, so we can remove the need to have the gpio_chip or later (planned) struct gpio_device be dynamically allocated at registration time, so that its struct device can be properly reference counted and not bound to its parent device (e.g. a platform_device) but instead live on after unregistration if it is opened by e.g. a char device or sysfs. The data is added with the new function gpiochip_add_data() and for compatibility we add static inline wrapper function gpiochip_add() that will call gpiochip_add_data() with NULL as argument. The latter will be removed once we have exorcised gpiochip_add() from the kernel. gpiochip_get_data() is added as a static inline accessor for drivers to quickly get their data out. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-12-26gpio: update gpiochip .get() callback descriptionVladimir Zapolskiy1-2/+1
Since gpiochip .get() callback may return a negative error value, it strictly limits the range of possible non-error returned values to a subset of [30:0] bitmask, however on practice on success all gpiochip drivers return either 0 for low signal or 1 for high signal, this is assured by "gpio: *: Be sure to clamp return value" series of changes. To avoid any confusion, misinterpretation and potential errors while developing gpiochip drivers in future convert this implicit assumption to a mandatory rule. For output signals with unknown output signal state gpiochip drivers should return a negative error instead of 0. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-19gpio: change member .dev to .parentLinus Walleij1-2/+2
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-16gpiolib: provide generic request/free implementationsJonas Gorski1-0/+3
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: Jonas Gorski <jogo@openwrt.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-24gpio: keep the GPIO line names internalLinus Walleij1-6/+0
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: Linus Walleij <linus.walleij@linaro.org>
2015-09-24gpio: Introduce gpio descriptor 'name'Markus Pargmann1-0/+7
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 <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-04Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-0/+1
Pull drm updates from Dave Airlie: "This is the main pull request for the drm for 4.3. Nouveau is probably the biggest amount of changes in here, since it missed 4.2. Highlights below, along with the usual bunch of fixes. All stuff outside drm should have applicable acks. Highlights: - new drivers: freescale dcu kms driver - core: more atomic fixes disable some dri1 interfaces on kms drivers drop fb panic handling, this was just getting more broken, as more locking was required. new core fbdev Kconfig support - instead of each driver enable/disabling it struct_mutex cleanups - panel: more new panels cleanup Kconfig - i915: Skylake support enabled by default legacy modesetting using atomic infrastructure Skylake fixes GEN9 workarounds - amdgpu: Fiji support CGS support for amdgpu Initial GPU scheduler - off by default Lots of bug fixes and optimisations. - radeon: DP fixes misc fixes - amdkfd: Add Carrizo support for amdkfd using amdgpu. - nouveau: long pending cleanup to complete driver, fully bisectable which makes it larger, perfmon work more reclocking improvements maxwell displayport fixes - vmwgfx: new DX device support, supports OpenGL 3.3 screen targets support - mgag200: G200eW support G200e new revision support - msm: dragonboard 410c support, msm8x94 support, msm8x74v1 support yuv format support dma plane support mdp5 rotation initial hdcp - sti: atomic support - exynos: lots of cleanups atomic modesetting/pageflipping support render node support - tegra: tegra210 support (dc, dsi, dp/hdmi) dpms with atomic modesetting support - atmel: support for 3 more atmel SoCs new input formats, PRIME support. - dwhdmi: preparing to add audio support - rockchip: yuv plane support" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (1369 commits) drm/amdgpu: rename gmc_v8_0_init_compute_vmid drm/amdgpu: fix vce3 instance handling drm/amdgpu: remove ib test for the second VCE Ring drm/amdgpu: properly enable VM fault interrupts drm/amdgpu: fix warning in scheduler drm/amdgpu: fix buffer placement under memory pressure drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic drm/amdgpu: fix typo in dce11 watermark setup drm/amdgpu: fix typo in dce10 watermark setup drm/amdgpu: use top down allocation for non-CPU accessible vram drm/amdgpu: be explicit about cpu vram access for driver BOs (v2) drm/amdgpu: set MEC doorbell range for Fiji drm/amdgpu: implement burst NOP for SDMA drm/amdgpu: add insert_nop ring func and default implementation drm/amdgpu: add amdgpu_get_sdma_instance helper function drm/amdgpu: add AMDGPU_MAX_SDMA_INSTANCES drm/amdgpu: add burst_nop flag for sdma drm/amdgpu: add count field for the SDMA NOP packet v2 drm/amdgpu: use PT for VM sync on unmap drm/amdgpu: make wait_event uninterruptible in push_job ...
2015-08-26gpiolib: add description for gpio irqchip fields in struct gpio_chipGrygorii Strashko1-0/+11
Add missed description for GPIO irqchip fields in struct gpio_chip. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-17gpiolib: irqchip: use different lockdep class for each gpio irqchipGrygorii Strashko1-5/+21
Since IRQ chip helpers were introduced drivers lose ability to register separate lockdep classes for each registered GPIO IRQ chip and the gpiolib now is using shared lockdep class for all GPIO IRQ chips (gpiochip_irq_lock_class). As result, lockdep will produce warning when there are min two stacked GPIO chips and all of them are interrupt controllers. HW configuration which generates lockdep warning (TI dra7-evm): [SOC GPIO bankA.gpioX] <- irq - [pcf875x.gpioY] <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq); The issue was reported in [1] and discussed [2]. ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted --------------------------------------------- sh/63 is trying to acquire lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 but task is already holding lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(class); lock(class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by sh/63: #0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164 #1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0 #2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0 #3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4 #4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398 #5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94 #6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 stack backtrace: CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55 Hardware name: Generic DRA74X (Flattened Device Tree) [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14) [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c) [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20) [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128) [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c) [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94) [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc) [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54) [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc) [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4) [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124) [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398) [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4) [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728) [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4) [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8) [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0) [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8) [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164) [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c) [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54) Lets fix it by using separate lockdep class for each registered GPIO IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros. The implementation of this patch inspired by solution done by Nicolas Boichat for regmap [3] [1] http://www.spinics.net/lists/linux-gpio/msg05844.html [2] http://www.spinics.net/lists/linux-gpio/msg06021.html [3] http://www.spinics.net/lists/arm-kernel/msg429834.html Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roger Quadros <rogerq@ti.com> Reported-by: Roger Quadros <rogerq@ti.com> Tested-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-13Merge tag 'v4.2-rc4' into develLinus Walleij1-1/+1
Linux 4.2-rc4
2015-07-21gpiolib: Add support for removing registered consumer lookup tableShobhit Kumar1-0/+1
In case we unload and load a driver module again that is registering a lookup table, without this it will result in multiple entries. Provide an option to remove the lookup table on driver unload Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-16gpio: Remove double "base" in commentGeert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-06gpio: make flags mandatory for gpiod_get functionsUwe Kleine-König1-59/+23
Now that all[1] users of the gpiod_get functions are converted to make use of the up to now optional flags parameter, make it mandatory which allows to remove some cpp magic. [1] all but etraxfs-uart which is broken anyhow and I'm allowed to ignore it by Jesper Nilsson :-) Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
2015-07-01Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-ledsLinus Torvalds1-0/+15
Pull LED subsystem updates from Bryan Wu: "In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits) leds:lp55xx: fix firmware loading error leds: fix max77693-led build errors leds: fix aat1290 build errors leds: aat1290: pass flags parameter to devm_gpiod_get leds: ktd2692: pass flags parameter to devm_gpiod_get drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c leds: aat1290: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: max77693: add support for V4L2 Flash sub-device media: Add registration helpers for V4L2 flash sub-devices v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Documentation: leds: Add description of v4l2-flash sub-device leds: add BCM6358 LED driver leds: add DT binding for BCM6358 LED controller leds: fix brightness changing when software blinking is active Documentation: leds-lp5523: describe master fader attributes leds: lp5523: add master_fader support leds: leds-gpio: Allow compile test if !GPIOLIB leds: leds-gpio: Add missing #include <linux/of.h> gpiolib: Add missing dummies for the unified device properties interface ...
2015-06-01gpiolib: rename gpiod_set_array to gpiod_set_array_valueRojhalat Ibrahim1-18/+19
There have been concerns that the function names gpiod_set_array() and gpiod_get_array() might be confusing to users. One might expect gpiod_get_array() to return array values, while it is actually the array counterpart of gpiod_get(). To be consistent with the single descriptor API we could rename gpiod_set_array() to gpiod_set_array_value(). This makes some function names a bit lengthy: gpiod_set_raw_array_value_cansleep(). Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-25gpiolib: Add missing dummies for the unified device properties interfaceGeert Uytterhoeven1-0/+15
If GPIOLIB=n: drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: drivers/leds/leds-gpio.c:187: error: implicit declaration of function ‘devm_get_gpiod_from_child’ drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from integer without a cast Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child() for the !GPIOLIB case to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: 40b7318319281b1b ("gpio: Support for unified device properties interface") Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-14gpio: discourage passing base to gpio_chipLinus Walleij1-2/+6
Passing a fixed base in struct gpio_chip is done for legacy systems that cannot handle dynamic allocation. Discourage this behaviour in the kerneldoc. Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-13gpiolib: cleanup chained handler and dataDmitry Eremin-Solenikov1-0/+1
Clean up chained handler and handler data if they were set by gpiochip_set_chained_irqchip(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-12gpio: remove gpiod_sysfs_set_active_lowJohan Hovold1-6/+0
Remove gpiod_sysfs_set_active_low (and gpio_sysfs_set_active_low) which allowed code to change the polarity of a gpio line even after it had been exported through sysfs. Drivers should not care, and generally does not know, about gpio-line polarity which is a hardware feature that needs to be described by firmware. It is currently possible to define gpio-line polarity in device-tree and acpi firmware or using platform data. Userspace can also change the polarity through sysfs. Note that drivers using the legacy gpio interface could still use GPIOF_ACTIVE_LOW to change the polarity before exporting the gpio. There are no in-kernel users of this interface. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Harry Wei <harryxiyou@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@zh-kernel.org Cc: linux-arch@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-12gpio: sysfs: clean up chip class-device handlingJohan Hovold1-2/+2
Clean gpio-chip class device registration and deregistration. The class device is registered when a gpio-chip is added (or from gpiolib_sysfs_init post-core init call), and deregistered when the chip is removed. Store the class device in struct gpio_chip directly rather than do a class-device lookup on deregistration. This also removes the need for the exported flag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-19gpio: move pincontrol calls to <linux/gpio/driver.h>Linus Walleij1-0/+48
These functions do not belong in <asm-generic/gpio.h> since the split into separate GPIO headers under <linux/gpio/*>. Move them to <linux/gpio/driver.h> as is apropriate. Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-05gpiolib: add devm_gpiod_get_array and devm_gpiod_put_array functionsRojhalat Ibrahim1-0/+30
Add device managed variants of gpiod_get_array() / gpiod_put_array() functions for conveniently obtaining and disposing of an entire array of GPIOs with one function call. Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-05gpiolib: add gpiod_get_array and gpiod_put_array functionsRojhalat Ibrahim1-0/+46
Introduce new functions for conveniently obtaining and disposing of an entire array of GPIOs with one function call. ACPI parts tested by Mika Westerberg, DT parts tested by Rojhalat Ibrahim. Change log: v5: move the ACPI functions to gpiolib-acpi.c v4: - use shorter names for members of struct gpio_descs - rename lut_gpio_count to platform_gpio_count for clarity - add check for successful memory allocation - use ERR_CAST() v3: - rebase on current linux-gpio devel branch - fix ACPI GPIO counting - allow for zero-sized arrays - make the flags argument mandatory for the new functions - clarify documentation v2: change interface Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-04gpio: add parameter to allow the use named gpiosOlliver Schinagl1-0/+1
The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Acked-by: Bryan Wu <cooloney@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-15gpio: Make the vararg hacks not pass magic valuesOlliver Schinagl1-8/+9
Right now, in consumer.h, there's some vararg hacks that pass 0 as the flags. What actually is passed however is GPIOD_ASIS, which naturally is also 0. Using the define/enum rather then the magic 0 makes it the define more readable to a passer by. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-12-14Merge tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds2-3/+45
Pull take two of the GPIO updates: "Same stuff as last time, now with a fixup patch for the previous compile error plus I ran a few extra rounds of compile-testing. This is the bulk of GPIO changes for the v3.19 series: - A new API that allows setting more than one GPIO at the time. This is implemented for the new descriptor-based API only and makes it possible to e.g. toggle a clock and data line at the same time, if the hardware can do this with a single register write. Both consumers and drivers need new calls, and the core will fall back to driving individual lines where needed. Implemented for the MPC8xxx driver initially - Patched the mdio-mux-gpio and the serial mctrl driver that drives modems to use the new multiple-setting API to set several signals simultaneously - Get rid of the global GPIO descriptor array, and instead allocate descriptors dynamically for each GPIO on a certain GPIO chip. This moves us closer to getting rid of the limitation of using the global, static GPIO numberspace - New driver and device tree bindings for 74xx ICs - New driver and device tree bindings for the VF610 Vybrid - Support the RCAR r8a7793 and r8a7794 - Guidelines for GPIO device tree bindings trying to get things a bit more strict with the advent of combined device properties - Suspend/resume support for the MVEBU driver - A slew of minor fixes and improvements" * tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (33 commits) gpio: mcp23s08: fix up compilation error gpio: pl061: document gpio-ranges property for bindings file gpio: pl061: hook request if gpio-ranges avaiable gpio: mcp23s08: Add option to configure IRQ output polarity as active high gpio: fix deferred probe detection for legacy API serial: mctrl_gpio: use gpiod_set_array function mdio-mux-gpio: Use GPIO descriptor interface and new gpiod_set_array function gpio: remove const modifier from gpiod_get_direction() gpio: remove gpio_descs global array gpio: mxs: implement get_direction callback gpio: em: Use dynamic allocation of GPIOs gpio: Check if base is positive before calling gpio_is_valid() gpio: mcp23s08: Add simple IRQ support for SPI devices gpio: mcp23s08: request a shared interrupt gpio: mcp23s08: Do not free unrequested interrupt gpio: rcar: Add r8a7793 and r8a7794 support gpio-mpc8xxx: add mpc8xxx_gpio_set_multiple function gpiolib: allow simultaneous setting of multiple GPIO outputs gpio: mvebu: add suspend/resume support gpio: gpio-davinci: remove duplicate check on resource ..
2014-11-28gpio: remove const modifier from gpiod_get_direction()Alexandre Courbot1-1/+1
Although gpiod_get_direction() can be considered side-effect free for consumers, its internals involve setting or clearing bits in the affected GPIO descriptor, for which we need to force-cast the const descriptor variable to non-const. This could lead to incorrect behavior if the compiler decides to optimize here, so remove this const attribute. The intent is to make gpiod_get_direction() private anyway, so it does not really matter. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-11-27gpiolib: allow simultaneous setting of multiple GPIO outputsRojhalat Ibrahim2-0/+42
Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer interface which allow setting multiple outputs with just one function call. Also add an optional set_multiple function to the driver interface. Without an implementation of that function in the chip driver outputs are set sequentially. Implementing the set_multiple function in a chip driver allows for: - Improved performance for certain use cases. The original motivation for this was the task of configuring an FPGA. In that specific case, where 9 GPIO lines have to be set many times, configuration time goes down from 48 s to 20 s when using the new function. - Simultaneous glitch-free setting of multiple pins on any kind of parallel bus attached to GPIOs provided they all reside on the same chip and bank. Limitations: Performance is only improved for normal high-low outputs. Open drain and open source outputs are always set separately from each other. Those kinds of outputs could probably be accelerated in a similar way if we could forgo the error checking when setting GPIO directions. Change log: v6: - rebase on current linux-gpio devel branch v5: - check can_sleep property per chip - remove superfluous checks - supplement documentation v4: - add gpiod_set_array function for setting logical values - change interface of the set_multiple driver function to use unsigned long as type for the bit fields - use generic bitops (which also use unsigned long for bit fields) - do not use ARCH_NR_GPIOS any more v3: - add documentation - change commit message v2: - use descriptor interface - allow arbitrary groups of GPIOs spanning multiple chips Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-11-04gpio: Support for unified device properties interfaceMika Westerberg1-0/+7
Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-28gpio: rename gpio_lock_as_irq to gpiochip_lock_as_irqAlexandre Courbot1-2/+2
This function actually operates on a gpio_chip, so its prefix should reflect that fact for consistency with other functions defined in gpio/driver.h. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-09Merge tag 'gpio-v3.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-2/+6
Pull GPIO changes from Linus Walleij: "This is the bulk of GPIO changes for the v3.18 development cycle: - Increase the default ARCH_NR_GPIO from 256 to 512. This was done to avoid having a custom <asm/gpio.h> header for the x86 architecture - GPIO is custom and complicated enough as it is already! We want to move to a radix to store the descriptors going forward, and finally get rid of this fixed array size altogether. - Endgame patching of the gpio_remove() semantics initiated by Abdoulaye Berthe. It is not accepted by the system that the removal of a GPIO chip fails during eg reboot or shutdown, and therefore the return value has now painfully been refactored away. For special cases like GPIO expanders on a hot-pluggable bus like USB, we may later add some gpiochip_try_remove() call, but for the cases we have now, return values are moot. - Some incremental refactoring of the gpiolib core and ACPI GPIO library for more descriptor usage. - Refactor the chained IRQ handler set-up method to handle also threaded, nested interrupts and set up the parent IRQ correctly. Switch STMPE and TC3589x drivers to use this registration method. - Add a .irq_not_threaded flag to the struct gpio_chip, so that also GPIO expanders that block but are still not using threaded IRQ handlers. - New drivers for the ARM64 X-Gene SoC GPIO controller. - The syscon GPIO driver has been improved to handle the "DSP GPIO" found on the TI Keystone 2 SoC:s. - ADNP driver switched to use gpiolib irqchip helpers. - Refactor the DWAPB driver to support being instantiated from and MFD cell (platform device). - Incremental feature improvement in the Zynq, MCP23S08, DWAPB, OMAP, Xilinx and Crystalcove drivers. - Various minor fixes" * tag 'gpio-v3.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (52 commits) gpio: pch: Build context save/restore only for PM pinctrl: abx500: get rid of unused variable gpio: ks8695: fix 'else should follow close brace '}'' gpio: stmpe: add verbose debug code gpio: stmpe: fix up interrupt enable logic gpio: staticize xway_stp_init() gpio: handle also nested irqchips in the chained handler set-up gpio: set parent irq on chained handlers gpiolib: irqchip: use irq_find_mapping while removing irqchip gpio: crystalcove: support virtual GPIO pinctrl: bcm281xx: make Kconfig dependency more strict gpio: kona: enable only on BCM_MOBILE or for compile testing gpio, bcm-kona, LLVMLinux: Remove use of __initconst gpio: Fix ngpio in gpio-xilinx driver gpio: dwapb: fix pointer to integer cast gpio: xgene: Remove unneeded #ifdef CONFIG_OF guard gpio: xgene: Remove unneeded forward declation for struct xgene_gpio gpio: xgene: Fix missing spin_lock_init() gpio: ks8695: fix switch case indentation gpiolib: add irq_not_threaded flag to gpio_chip ...
2014-10-07Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivialLinus Torvalds1-2/+2
Pull "trivial tree" updates from Jiri Kosina: "Usual pile from trivial tree everyone is so eagerly waiting for" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits) Remove MN10300_PROC_MN2WS0038 mei: fix comments treewide: Fix typos in Kconfig kprobes: update jprobe_example.c for do_fork() change Documentation: change "&" to "and" in Documentation/applying-patches.txt Documentation: remove obsolete pcmcia-cs from Changes Documentation: update links in Changes Documentation: Docbook: Fix generated DocBook/kernel-api.xml score: Remove GENERIC_HAS_IOMAP gpio: fix 'CONFIG_GPIO_IRQCHIP' comments tty: doc: Fix grammar in serial/tty dma-debug: modify check_for_stack output treewide: fix errors in printk genirq: fix reference in devm_request_threaded_irq comment treewide: fix synchronize_rcu() in comments checkstack.pl: port to AArch64 doc: queue-sysfs: minor fixes init/do_mounts: better syntax description MIPS: fix comment spelling powerpc/simpleboot: fix comment ...
2014-09-24gpiolib: add irq_not_threaded flag to gpio_chipOctavian Purdila1-0/+3
Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set operation but do not need a threaded irq handler. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-23gpio: gpiolib: set gpiochip_remove retval to voidabdoulaye berthe1-1/+1
This avoids handling gpiochip remove error in device remove handler. Signed-off-by: Abdoulaye Berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-05gpio: fix 'CONFIG_GPIO_IRQCHIP' commentsPaul Bolle1-2/+2
These two typos were introduced in commit 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib"). The correct symbol name is CONFIG_GPIOLIB_IRQCHIP. [jkosina@suse.cz: add changelog] Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-09-02gpio: move varargs hack outside #ifdef GPIOLIBLinus Walleij1-45/+60
commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 "gpio: add flags argument to gpiod_get*() functions" added a dynamic flags argument to all the GPIOD getter functions, however this did not cover the stubs so when people used gpiod stubs to compile out descriptor code, compilation failed. Solve this by: - Also rename all the stub functions __gpiod_* - Moving the vararg hack outside of #ifdef CONFIG_GPIOLIB so these will always be available. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-08-29gpio: change gpiochip_request_own_desc() prototypeAlexandre Courbot1-1/+2
The current prototype of gpiochip_request_own_desc() requires to obtain a pointer to a descriptor. This is in contradiction to all other GPIO request schemes, and imposes an extra step of obtaining a descriptor to drivers. Most drivers actually cannot even perform that step since the function that does it (gpichip_get_desc()) is gpiolib-private. Change gpiochip_request_own_desc() to return a descriptor from a (chip, hwnum) tuple and update users of this function (currently gpiolib-acpi only). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-08-21gpio: move GPIOD flags outside #ifdefLinus Walleij1-2/+2
The GPIOD flags are defined inside the #ifdef CONFIG_GPIOLIB switch, making the gpiolib stubs fail if these flags are used by a consumer. This is not correct: the stubs should compile fine without GPIOLIB. Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>