Skip to content

GitLab

I
ipipe-ppc32
Switch branch/tag
  1. 14 Aug, 2017 1 commit
    • Gregory CLEMENT's avatar
      gpio: mvebu: Fix cause computation in irq handler · 3f13b6a2
      Gregory CLEMENT authored 
      When switching to regmap, the way to compute the irq cause was
reorganized. However while doing it, a typo was introduced: a 'xor'
replaced a 'and'.

This lead to wrong behavior in the interrupt handler ans one of the
symptom was wrong irq handler called on the Armada 388 GP:
"->handle_irq():  c016303c,
handle_bad_irq+0x0/0x278
->irq_data.chip(): c0b0ec0c,
0xc0b0ec0c
->action():   (null)
   IRQ_NOPROBE set
 IRQ_NOREQUEST set
unexpected IRQ trap at vector 00
irq 0, desc: ee804800, depth: 1, count: 0, unhandled: 0"

Fixes: 2233bf7a ("gpio: mvebu: switch to regmap for register access")
Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3f13b6a2
  3. 20 Jun, 2017 1 commit
  5. 16 Jun, 2017 2 commits
  7. 09 Jun, 2017 2 commits
  9. 23 May, 2017 2 commits
  11. 24 Apr, 2017 1 commit
  13. 23 Mar, 2017 1 commit
  15. 16 Mar, 2017 6 commits
  17. 11 Jan, 2017 1 commit
  19. 01 Nov, 2016 1 commit
    • Jason Gunthorpe's avatar
      gpio/mvebu: Use irq_domain_add_linear · 812d4788
      Jason Gunthorpe authored 
      This fixes the irq allocation in this driver to not print:
 irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
 irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated

Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.

Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy

Fixes: ce931f57 ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      812d4788
  21. 31 Mar, 2016 1 commit
    • Paul Gortmaker's avatar
      gpio: mvebu: make explicitly non-modular · ed329f3a
      Paul Gortmaker authored 
      The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config GPIO_MVEBU
drivers/gpio/Kconfig:   def_bool y

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      ed329f3a
  23. 23 Feb, 2016 1 commit
  25. 05 Jan, 2016 1 commit
  27. 19 Nov, 2015 1 commit
    • Linus Walleij's avatar
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij authored 
      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: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: default avatarLee Jones <lee.jones@linaro.org>
Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      58383c78
  29. 16 Oct, 2015 1 commit
  31. 16 Sep, 2015 1 commit
    • Thomas Gleixner's avatar
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner authored 
      Most interrupt flow handlers do not use the irq argument. Those few
which use it can retrieve the irq number from the irq descriptor.

Remove the argument.

Search and replace was done with coccinelle and some extra helper
scripts around it. Thanks to Julia for her help!
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
      bd0b9ac4
  33. 14 Jul, 2015 3 commits
  35. 08 Apr, 2015 1 commit
    • Gregory CLEMENT's avatar
      gpio: mvebu: Fix mask/unmask managment per irq chip type · 61819549
      Gregory CLEMENT authored 
      Level IRQ handlers and edge IRQ handler are managed by tow different
sets of registers. But currently the driver uses the same mask for the
both registers. It lead to issues with the following scenario:

First, an IRQ is requested on a GPIO to be triggered on front. After,
this an other IRQ is requested for a GPIO of the same bank but
triggered on level. Then the first one will be also setup to be
triggered on level. It leads to an interrupt storm.

The different kind of handler are already associated with two
different irq chip type. With this patch the driver uses a private
mask for each one which solves this issue.

It has been tested on an Armada XP based board and on an Armada 375
board. For the both boards, with this patch is applied, there is no
such interrupt storm when running the previous scenario.

This bug was already fixed but in a different way in the legacy
version of this driver by Evgeniy Dushistov:
9ece8839 "ARM: orion: Fix for certain
sequence of request_irq can cause irq storm". The fact the new version
of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012Reported-by: default avatarEvgeniy A. Dushistov <dushistov@mail.ru>
Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.7 +
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      61819549
  37. 15 Jan, 2015 2 commits
  39. 03 Nov, 2014 1 commit
  41. 20 Oct, 2014 1 commit
  43. 09 May, 2014 3 commits
  45. 12 Feb, 2014 1 commit
    • Thomas Petazzoni's avatar
      gpio: mvebu: use chained_irq_{enter,exit} for GIC compatibility · 01ca59f1
      Thomas Petazzoni authored 
      On currently supported SoCs, the GPIO block used on Marvell EBU SoCs
is always connected to the Marvell MPIC. However, we are going to
introduce the support for newer Marvell EBU SoCs that use the
Cortex-A9 core, and therefore use the GIC as their main interrupt
controller, to which the GPIO block controlled by the gpio-mvebu
driver is connected.

The GIC interrupt controller driver uses the fasteoi flow handler. In
order to ensure that the eoi hook of the GIC driver gets called, the
GPIO driver should call chained_irq_enter() and chained_irq_exit() in
its handler. Without this, the first GPIO interrupt locks up the
system because it doesn't get acked at the GIC level.

This change is similar to for example commit
0d978eb7 ("gpio: davinci: use
chained_irq_enter/chained_irq_exit API").
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: default avatarJason Cooper <jason@lakedaemon.net>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      01ca59f1
  47. 02 Jan, 2014 1 commit
  49. 04 Dec, 2013 1 commit
    • Linus Walleij's avatar
      gpio/pinctrl: make gpio_chip members typed boolean · 9fb1f39e
      Linus Walleij authored 
      This switches the two members of struct gpio_chip that were
defined as unsigned foo:1 to bool, because that is indeed what
they are. Switch all users in the gpio and pinctrl subsystems
to assign these values with true/false instead of 0/1. The
users outside these subsystems will survive since true/false
is 1/0, atleast we set some kind of more strict typing example.
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      9fb1f39e
  51. 25 Nov, 2013 1 commit
  53. 16 Aug, 2013 1 commit