Skip to content

L
linux
Switch branch/tag
  1. 25 Sep, 2018 2 commits
  3. 24 Sep, 2018 6 commits
    • Tony Lindgren's avatar
      gpio: omap: Get rid of pm_runtime_irq_safe() · 5284521a
      Tony Lindgren authored 
      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: default avatarTony Lindgren <tony@atomide.com>
Acked-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      5284521a
    • Tony Lindgren's avatar
      gpio: omap: Remove custom PM calls and use cpu_pm instead · b764a586
      Tony Lindgren authored 
      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: default avatarTony Lindgren <tony@atomide.com>
Acked-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b764a586
    • Tony Lindgren's avatar
      gpio: omap: Add level wakeup handling for omap4 based SoCs · ec0daae6
      Tony Lindgren authored 
      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: default avatarTony Lindgren <tony@atomide.com>
Acked-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
Tested-by: default avatarKeerthy <j-keerthy@ti.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ec0daae6
    • Janusz Krzysztofik's avatar
      gpiolib: Fix array members of same chip processed separately · c4c958aa
      Janusz Krzysztofik authored 
      New code introduced by commit bf9346f5 ("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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c4c958aa
    • Janusz Krzysztofik's avatar
      gpiolib: Fix missing updates of bitmap index · 35ae7f96
      Janusz Krzysztofik authored 
      In new code introduced by commit b17566a6 ("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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      35ae7f96
    • Linus Walleij's avatar
      gpio: htc-egpio: Unique label per chip · 212d7069
      Linus Walleij authored 
      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: default avatarLinus Walleij <linus.walleij@linaro.org>
      212d7069
  5. 20 Sep, 2018 8 commits
  7. 17 Sep, 2018 15 commits
  9. 14 Sep, 2018 1 commit
  11. 13 Sep, 2018 6 commits
    • Janusz Krzysztofik's avatar
      gpiolib: Implement fast processing path in get/set array · b17566a6
      Janusz Krzysztofik authored 
      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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b17566a6
    • Janusz Krzysztofik's avatar
      gpiolib: Pass array info to get/set array functions · 77588c14
      Janusz Krzysztofik authored 
      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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      77588c14
    • Janusz Krzysztofik's avatar
      gpiolib: Identify arrays matching GPIO hardware · bf9346f5
      Janusz Krzysztofik authored 
      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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      bf9346f5
    • Janusz Krzysztofik's avatar
      gpiolib: Pass bitmaps, not integer arrays, to get/set array · b9762beb
      Janusz Krzysztofik authored 
      Most users of get/set array functions iterate consecutive bits of data,
usually a single integer, while processing array of results obtained
from, or building an array of values to be passed to those functions.
Save time wasted on those iterations by changing the functions' API to
accept bitmaps.

All current users are updated as well.

More benefits from the change are expected as soon as planned support
for accepting/passing those bitmaps directly from/to respective GPIO
chip callbacks if applicable is implemented.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
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: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b9762beb
    • Uwe Kleine-König's avatar
      gpiolib: Don't support irq sharing for userspace · fa38869b
      Uwe Kleine-König authored 
      This concerns gpio edge detection for GPIO IRQs used from
userspace for GPIO event listeners.

Trying to work out the right event if it's not sure that the
examined gpio actually moved is impossible.

Consider two gpios "gpioA" and "gpioB" that share an interrupt.
gpioA's irq should trigger on any edge, gpioB's on a falling edge.
If now the common irq fires and both gpio lines are high, there
are several possibilities that could have happend:

 a) gpioA just had a low-to-high edge
 b) gpioB just had a high-to-low-to-high spike
 c) a combination of both a) and b)

While c) is unlikely (in most setups) a) and b) alone are bad
enough. Currently the code assumes case a) unconditionally and
doesn't report an event for gpioB. Note that even if there is no
irq sharing involved a spike for a gpio might not result in an
event if it's configured to trigger for a single edge only.

The only way to improve this is to drop support for interrupt
sharing. This way a spike results in an event for the right gpio
at least. Note that apart from dropping IRQF_SHARED this
effectively undoes commit df1e76f2
("gpiolib: skip unwanted events, don't convert them to opposite edge").

This obviously breaks setups that rely on interrupt sharing,
but given that this cannot be reliable, this is probably an
acceptable trade-off.
Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
[Assuming there are no users of interrupt sharing yet]
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fa38869b
    • Geert Uytterhoeven's avatar
      gpio: uapi: Grammar s/array/array of/ · 0b35cd7b
      Geert Uytterhoeven authored 
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      0b35cd7b
  13. 12 Sep, 2018 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7