summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-10-02gpio: Slightly more helpful debugfsLinus Walleij
This at least makes debugfs print if the line is active high or low. That is pretty helpful as what we display as "lo" or "hi" is the raw physical level of the line. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: omap: Remove set but not used variable 'dev'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpio/gpio-omap.c: In function 'gpio_omap_cpu_notifier': drivers/gpio/gpio-omap.c:1327:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: omap: drop omap_gpio_listGrygorii Strashko
omap_gpio_list is unused so drop it. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01Accept partial 'gpio-line-names' property.Christophe Blaess
Documentation/devicetree/bindings/gpio/gpio.txt says: "The names are assigned starting from line offset 0 from left to right from the passed array. An incomplete array (where the number of passed named are less than ngpios) will still be used up until the last provided valid line index". This patch makes it actually work this way. Signed-off-by: Christophe Blaess <christophe.blaess@logilin.fr> Signed-off-by: Patrick Boettcher <p@yai.se> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: omap: get rid of the conditional PM runtime callsGrygorii Strashko
OMAP GPIO driver is checking !BANK_USED() used condition before calling PM runtime API, because of PM runtime calls in omap2_gpio_prepare/resume_for_idle(). It's not required any more since "omap gpio add level idle, cpu_pm and drop runtime_irq_safe" series [1] from Tony Lindgren was accepted and PM runtime management was enabled in IRQ chip core by commit be45beb2df69 ("genirq: Add runtime power management support for IRQ chips") . As result safely drop !BANK_USED() checks from omap_gpio_request/free(), omap_gpio_irq_bus_lock/unlock() and enable PM runtime management for OMAP GPIO IRQ chip. [1] https://www.spinics.net/lists/arm-kernel/msg677583.html Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: htc-egpio: Remove set but not used variable 'bit'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpio/gpio-htc-egpio.c: In function 'egpio_set': drivers/gpio/gpio-htc-egpio.c:192:20: warning: variable 'bit' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: Restore indentation of continued linesGeert Uytterhoeven
Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpio: Propagate errors from gpiod_set_array_value_complex()Geert Uytterhoeven
Internal helper function gpiod_set_array_value_complex() was changed to return an error value, but not all gpiolib callers were updated to propagate the new error up. Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01Documentation: gpio: Fix return type of gpiod_set_raw_array_value*()Geert Uytterhoeven
The return type of gpiod_set_raw_array_value() and gpiod_set_raw_array_value_cansleep() was changed from void to int, but the doc update was forgotten. Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-10-01gpiolib: Fix incorrect use of find_next_zero_bit()Janusz Krzysztofik
Commit b17566a6b08b ("gpiolib: Implement fast processing path in get/set array"), already fixed to some extent with commit 5d581d7e8cdc ("gpiolib: Fix missing updates of bitmap index"), introduced a new mode of processing bitmaps where bits applicable for fast bitmap processing path are supposed to be skipped while iterating bits which don't apply. Unfortunately, find_next_zero_bit() function supposed to skip over those fast bits is always called with a 'start' argument equal to an index of last zero bit found and returns that index value again an again, causing an infinite loop. Fix it by incrementing the index uncoditionally before find_next_zero_bit() is optionally called. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-28gpio: new driver to work with a 8x12 sioxUwe Kleine-König
This driver controls a SIOX device that provides 20 I/O lines. The first twelve are fixed inputs, the remaining eight are outputs. Acked-by: Gavin Schenk <g.schenk@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25dt-bindings: gpio: rcar: Add r8a7744 (RZ/G1N) supportBiju Das
Renesas RZ/G1N (R8A7744) SoC GPIO blocks are identical to the R-Car Gen2 family. Add support for its GPIO controllers. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25gpio: Add comments on single direction chipsLinus Walleij
A patch from Ricardo got me thinking about some gpio chip semantics so let's drop in some comments to make things more clear around that. Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25gpiolib: Fix gpio_direction_* for single direction GPIOsRicardo Ribalda Delgado
GPIOs with no programmable direction are not required to implement direction_output nor direction_input. If we try to set an output direction on an output-only GPIO or input direction on an input-only GPIO simply return 0. This allows this single direction GPIO to be used by libgpiod. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25gpio: Rename devres implementation fileLinus Walleij
All the other core files are named "gpiolib-<something>" so let's rename the devres as well so we have some logical namespacing here. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25gpio: Use SPDX header for core libraryLinus Walleij
Use the SPDX headers and cut down on boilerplate to indicate the license in the core gpiolib implementation. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-25Merge branch 'ib-omap' into develLinus Walleij
2018-09-24gpio: omap: Get rid of pm_runtime_irq_safe()Tony Lindgren
If a gpio instance has any GPIO bits requested we do a pm_runtime_get() on the device. Now with cpu_pm handling the deeper SoC idle state quirks, let's just remove pm_runtime_irq_safe() call and add a warning in case we ever happen to encounter it. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-24gpio: omap: Remove custom PM calls and use cpu_pm insteadTony Lindgren
For a long time the gpio-omap custom PM calls have been annoying me so let's replace them with cpu_pm instead. This will enable GPIO PM for deeper idle states on omap4. And we can handle GPIO PM for omap2/3/4 in the same way. Note that with this patch we are also slightly changing GPIO PM to be less aggressive for omap3 and only will idle GPIO when PER context may be lost. For omap2, we don't need to save context and don't want to remove any triggering so let's add a quirk flag for that. Let's do this all in a single patch to avoid a situation where old custom calls still are used with new code. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-24gpio: omap: Add level wakeup handling for omap4 based SoCsTony Lindgren
I noticed that unlike omap2 and 3 based SoCs, omap4 based SoCs keep the GPIO clocks enabled for GPIO level interrupts with wakeup enabled. This blocks deeper idle states as the whole domain will stay busy. The GPIO functional clock seems to stay enabled if the wakeup register is enabled and a level interrupt is triggered. In that case the only way to have the GPIO module idle is to reset it. It is possible this has gone unnoticed with OSWR (Open SWitch Retention) and off mode during idle resetting GPIO context most GPIO instances in the earlier Android trees for example. Looks like the way to deal with this is to have omap4 based SoCs only set wake for the duration of idle for level interrupts, and clear level registers for the idle. With level interrupts we can do this as the level interrupt from device will be still there on resume. I've taken the long path to fixing this to avoid yet more hard to read code. I've set up a quirks flag, and a struct for function pointers so we can use these to clean up other quirk handling easier in the later patches. The current level quirk handling is moved to the new functions. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-24gpiolib: Fix array members of same chip processed separatelyJanusz Krzysztofik
New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays matching GPIO hardware") forcibly tries to find an array member which has its array index number equal to its hardware pin number and set up an array info for possible fast bitmap processing of all arrray pins belonging to that chip which also satisfy that numbering rule. Depending on array content, it may happen that consecutive array members which belong to the same chip but don't have array indexes equal to their pin hardware numbers will be split into groups, some of them processed together via the fast bitmap path, and rest of them separetely. However, applications may expect all those pins being processed together with a single call to .set_multiple() chip callback, like that was done before the change. Limit applicability of fast bitmap processing path to cases where all pins of consecutive array members starting from 0 which belong to the same chip have their hardware numbers equal to their corresponding array indexes. That should still speed up processing of applications using whole GPIO banks as I/O ports, while not breaking simultaneous manipulation of consecutive pins of the same chip which don't follow the equal numbering rule. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-24gpiolib: Fix missing updates of bitmap indexJanusz Krzysztofik
In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast processing path in get/set array"), bitmap index is not updated with next found zero bit position as it should while skipping over pins already processed via fast bitmap path, possibly resulting in an infinite loop. Fix it. Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-24gpio: htc-egpio: Unique label per chipLinus Walleij
Give the HTC EGPIO chips unique names, htc-egpio-0, htc-egpio-1 etc, so that it gets possible to associate machine descriptor tables with individual chips. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20Merge branch 'ib-array-bitmaps' into develLinus Walleij
2018-09-20gpio: OF: Remove bad practice examplesLinus Walleij
We remove the references to anything but two-cell GPIO specifiers and just mention that controllers need to specify their bindings and that we strongly recommend two-cell bindings. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: OF: Cut painful BNF experiments from bindingsLinus Walleij
In 2011 the commit bf859f84a19f ("gpio/dt: Refine GPIO device tree binding") introduced an experimental BNF notation for defining a regular grammar for the GPIO phandles used by different devices. This was an interesting approach, and shows that we have long nutured the idea to formally verify device tree files using regular grammar. Most if not all other bindings use natural language to define the bindings, and the recent thinking for verifying device tree files is to use JSON schemas in separate definitions. Cut the BNF business and replace it with natural language so that it becomes more human-readable for now. Cc: devicetree@vger.kernel.org Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Kumar Gala <galak@kernel.crashing.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: davinci: Move driver local definitions to driverAndrew F. Davis
These defines, structs and inline functions are used only internally by the driver, they do not belong in platform_data. Move them. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: davinci: Remove unneeded GPIO macroAndrew F. Davis
This macro does nothing and has only one user, remove it. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: davinci: Allocate the correct amount of memory for controllerAndrew F. Davis
Previously we created a controller structure per bank of GPIO pins. This has since been changed to one per controller, but the allocation size was not changed. Fix this here. This also leaves the variable 'nbank' unused, instead of removing it, move it down and use it to clean up a loop. For loops with multiple initializers and/or iteration expressions, especially ones that don't use those loop counters are quite hard to follow, fix this. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: davinci: Use dev name for label and automatic base selectionAndrew F. Davis
Use dev_name to get a unique label and use -1 for a base to get our selection automatically. We pull in all GPIOs per chip now so this does not have the effect of out of order labels like before. We do these both together so we can drop all the static data in one patch. This also lets us normalize the return paths as we don't need any cleanup after this change. Signed-off-by: Andrew F. Davis <afd@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-20gpio: davinci: Remove unused member of davinci_gpio_controllerAndrew F. Davis
This was added as part of the patch in the fixes below, but was not needed or used, remove this here. Fixes: 8e11047b8f3c ("gpio: davinci: Add support for multiple GPIO controllers") Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: Get rid of legacy headerLinus Walleij
A bunch of core gpiolib files still include the <linux/gpio.h> legacy API header for no good reason. After this only the gpiolib-legacy.c file includes it, which is fine. The sysfs ABI code has a pointless wrapper function around gpio_to_desc() we can just loose. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: wm8xxx: Cut down on boilerplateLinus Walleij
Just use the SPDX license tag for these drivers. Cc: patches@opensource.cirrus.com Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Mark Brown <broonie@kernel.org> Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: wm8xxx: Use the right headerLinus Walleij
These are GPIO drivers so just include <linux/gpio/driver.h>. Cc: patches@opensource.cirrus.com Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Mark Brown <broonie@kernel.org> Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: xlp: Cut down on boilerplateLinus Walleij
Just use the SPDX license tag for this file. Cc: Kamlakant Patel <kamlakant.patel@cavium.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: xlp: Include the right headerLinus Walleij
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Kamlakant Patel <kamlakant.patel@cavium.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: vx855: Cut down on boilerplateLinus Walleij
Just use the SPDX header for the license. Cc: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: vx855: Include the right headerLinus Walleij
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: viperboard: Cut down on boilerplateLinus Walleij
Just use the SPDX header for the license. Cc: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: viperboard: Include the right headerLinus Walleij
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: xtensa: Cut down on boilerplateLinus Walleij
Just use the SPDX header for the license. Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: xtensa: Include the right headerLinus Walleij
This is a GPIO driver so include only <linux/gpio/driver.h>. Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: vr41xx: Delete vr41xx_gpio_pullupdown() callbackLinus Walleij
This API is not used anywhere in the kernel and has remained unused for years after being introduced. Over time, we have developed a subsystem to deal with pin control and this now managed pull up/down. Delete the old and unused API. If this platform needs it, we should implement a proper pin controller for it instead. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Acked-by: Paul Burton <paul.burton@mips.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: vr41xx: Cut down on boilerplateLinus Walleij
This switches this file to use the SPDX license tag. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpio: vr41xx: Include the right headerLinus Walleij
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Yoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-17gpiolib: check if irqchip already has the irq hook replacementsHans Verkuil
Some drivers use a single irqchip for multiple gpiochips. As a result the irqchip hooks are overridden for the first gpiochip that was added, but for the other gpiochip instances this should not happen again, otherwise we would go into an infinite recursion. Check for this, but also log a message that the driver should be fixed since this is bad practice. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-14gpiolib: use better errno if get_direction is not availableWolfram Sang
EINVAL is very generic, use ENOTSUPP in case the gpiochip does not provide this function. While removing the assignment from the 'status' variable, use better indentation in the declaration block. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-13gpiolib: Implement fast processing path in get/set arrayJanusz Krzysztofik
Certain GPIO descriptor arrays returned by gpio_get_array() may contain information on direct mapping of array members to pins of a single GPIO chip in hardware order. In such cases, bitmaps of values can be passed directly from/to the chip's .get/set_multiple() callbacks without wasting time on iterations. Add respective code to gpiod_get/set_array_bitmap_complex() functions. Pins not applicable for fast path are processed as before, skipping over the 'fast' ones. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-13gpiolib: Pass array info to get/set array functionsJanusz Krzysztofik
In order to make use of array info obtained from gpiod_get_array() and speed up processing of arrays matching single GPIO chip layout, that information must be passed to get/set array functions. Extend the functions' API with that additional parameter and update all users. Pass NULL if a user builds an array itself from single GPIOs. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-09-13gpiolib: Identify arrays matching GPIO hardwareJanusz Krzysztofik
Certain GPIO array lookup results may map directly to GPIO pins of a single GPIO chip in hardware order. If that condition is recognized and handled efficiently, significant performance gain of get/set array functions may be possible. While processing a request for an array of GPIO descriptors, identify those which represent corresponding pins of a single GPIO chip. Skip over pins which require open source or open drain special processing. Moreover, identify pins which require inversion. Pass a pointer to that information with the array to the caller so it can benefit from enhanced performance as soon as get/set array functions can accept and make efficient use of it. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>