Skip to content

L
linux
Switch branch/tag
  1. 16 Oct, 2018 1 commit
    • Stephen Boyd's avatar
      gpio: Drop parent irq assignment during cascade setup · 9cb7cf9c
      Stephen Boyd authored 
      We want to set the irq parent for interrupts that we're setting up to be
cascaded from another interrupt controller, but we may or may not have
already mapped the gpiochip irqs into the kernel's virtual irq number
space at this point. If we have mapped irqs before calling here, then
we've gone through gpiochip_irq_map() and called irq_set_parent()
already. If we haven't mapped irqs, then the gpiochip is dynamically
mapping irqs and we can rely on gpiochip_irq_map() or the gpio driver's
irqdomain ops to setup the irq parent properly.

Either way, setting the parent here when cascading the gpiochip doesn't
make much sense because it should be done at irq mapping time. In the
dynamic mapping case, this code is mapping virq 0 to some parent virq in
a loop. While that's benign, let's drop this code to simplify.

Cc: Evan Green <evgreen@chromium.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      9cb7cf9c
  3. 15 Oct, 2018 2 commits
  5. 12 Oct, 2018 1 commit
  7. 10 Oct, 2018 8 commits
  9. 03 Oct, 2018 1 commit
  11. 02 Oct, 2018 1 commit
  13. 01 Oct, 2018 9 commits
  15. 28 Sep, 2018 1 commit
  17. 25 Sep, 2018 6 commits
  19. 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
  21. 20 Sep, 2018 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7