1. 23 5月, 2017 1 次提交
  2. 25 4月, 2017 1 次提交
  3. 25 11月, 2016 1 次提交
    • L
      gpio: simplify adding threaded interrupts · d245b3f9
      Linus Walleij 提交于
      This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when
      using threaded interrupts: add a new call
      gpiochip_irqchip_add_nested() to indicate that we're dealing
      with a nested rather than a chained irqchip, then create a
      separate gpiochip_set_nested_irqchip() to mirror
      the gpiochip_set_chained_irqchip() call to connect the
      parent and child interrupts.
      
      In the nested case gpiochip_set_nested_irqchip() does nothing
      more than call irq_set_parent() on each valid child interrupt,
      which has little semantic effect in the kernel, but this is
      probably still formally correct.
      
      Update all drivers using nested interrupts to use
      gpiochip_irqchip_add_nested() so we can now see clearly
      which these users are.
      
      The DLN2 driver can drop its specific hack with
      .irq_not_threaded as we now recognize whether a chip is
      threaded or not from its use of gpiochip_irqchip_add_nested()
      signature rather than from inspecting .can_sleep.
      
      We rename the .irq_parent to .irq_chained_parent since this
      parent IRQ is only really kept around for the chained
      interrupt handlers.
      
      Cc: Lars Poeschel <poeschel@lemonage.de>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Daniel Baluta <daniel.baluta@intel.com>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
      Cc: Semen Protsenko <semen.protsenko@globallogic.com>
      Cc: Alexander Stein <alexander.stein@systec-electronic.com>
      Cc: Phil Reid <preid@electromag.com.au>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      d245b3f9
  4. 07 6月, 2016 1 次提交
    • K
      gpio: pcf857x: restore the initial line state of all pcf lines · adc28475
      Kishon Vijay Abraham I 提交于
      The reset values for all the PCF lines are high and hence on
      shutdown we should drive all the lines high in order to
      bring it to the reset state.
      
      This is actually required since PCF doesn't have a reset
      line and even after warm reset (by invoking "reboot" in
      prompt) the PCF lines maintains it's previous programmed
      state. This becomes a problem if the boards are designed to
      work with the default initial state.
      
      DRA7XX_evm uses PCF8575 and one of the PCF output lines
      feeds to MMC/SD VDD and this line should be driven high in order
      for the MMC/SD to be detected.  This line is modelled as
      regulator and the hsmmc driver takes care of enabling and
      disabling it. In the case of 'reboot', during shutdown path
      as part of it's cleanup process the hsmmc driver disables
      this regulator. This makes MMC *boot* not functional.
      
      Fix it by driving all the pcf lines high.
      
      This patch was sent long back
      (https://patchwork.ozlabs.org/patch/420382/)
      But there was a concern that contention might occur if the
      PCF shutdown handler is invoked before the shutdown handler
      of the PCF's consumers. In that case PCF shutdown handler can't
      drive all the pcf lines high without knowing if the PCF
      consumers are still active.
      
      However commit 52cdbdd4 ("driver core: correct device's
      shutdown order") will make sure shutdown handler of PCF's
      consumers are invoked before invoking the shutdown
      handler of PCF. So it should be safe to merge this now.
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      adc28475
  5. 23 2月, 2016 1 次提交
  6. 05 1月, 2016 1 次提交
    • L
      gpio: pcf857x: use gpiochip data pointer · 597358e4
      Linus Walleij 提交于
      This makes the driver use the data pointer added to the gpio_chip
      to store a pointer to the state container instead of relying on
      container_of().
      
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: George Cherian <george.cherian@ti.com>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      597358e4
  7. 27 12月, 2015 1 次提交
    • L
      gpio: pcf857x: Be sure to clamp return value · 40f80580
      Linus Walleij 提交于
      As we want gpio_chip .get() calls to be able to return negative
      error codes and propagate to drivers, we need to go over all
      drivers and make sure their return values are clamped to [0,1].
      We do this by using the ret = !!(val) design pattern.
      
      Also start returning the error code if something fails, as the
      end of the series augment the core to support this.
      
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: George Cherian <george.cherian@ti.com>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      40f80580
  8. 11 12月, 2015 1 次提交
  9. 30 11月, 2015 1 次提交
  10. 19 11月, 2015 1 次提交
    • L
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij 提交于
      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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      58383c78
  11. 16 7月, 2015 1 次提交
  12. 16 6月, 2015 1 次提交
    • G
      gpio: pcf857x: handle only enabled irqs · 84f28998
      Grygorii Strashko 提交于
      Now pcf857x_irq() IRQ's dispatcher will try to run nested
      IRQ handlers for each GPIO pin which state has changed.
      Such IRQs are, actually, spurious and nested IRQ handlers
      have to be called only for IRQs wich were enabled by users.
      This is not critical issue - just  /proc/interrupts
      will display counters for unused IRQS:
      399:          4          0   pcf857x   0 Edge
      428:          1          0   pcf857x  13 Edge
      430:          1          0   pcf857x  15 Edge
      
      Hence, fix it by adding irq_enabled field in struct pcf857x to track
      enabled GPIO IRQs and corresponding callbacks in pcf857x_irq_chip.
      
      Similar functionality was presented in pcf857x driver, commit
      21fd3cd1 ('gpio: pcf857x: call the gpio user handler iff...')
      
      and then it was removed by commit
       a39294bd ('gpio: pcf857x: Switch to use gpiolib irqchip...')
      
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Fixes: a39294bd ('gpio: pcf857x: Switch to use gpiolib irqchip helpers')
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      84f28998
  13. 01 6月, 2015 1 次提交
  14. 04 3月, 2015 2 次提交
    • G
      gpio: pcf857x: Propagate wake-up setting to parent irq controller · b80eef95
      Geert Uytterhoeven 提交于
      The pcf857x GPIO and interrupt controller uses dummy_irq_chip, which
      does not implement irq_chip.irq_set_wake() and does not set
      IRQCHIP_SKIP_SET_WAKE.
      
      This causes two s2ram issues if wake-up is enabled for the pcf857x GPIO
      pins:
        1. During resume from s2ram, the following warning is printed:
      
           WARNING: CPU: 0 PID: 1046 at kernel/irq/manage.c:537 irq_set_irq_wake+0x9c/0xf8()
           Unbalanced IRQ 113 wake disable
      
        2. Wake-up through the pcf857x GPIO pins may fail, as the parent
           interrupt controller may be suspended.
      
      Migrate the pcf857x GPIO and interrupt controller from dummy_irq_chip to
      its own irq_chip. This irq chip implements irq_chip.irq_set_wake() to
      propagate its wake-up setting to the parent interrupt controller.
      
      This fixes wake-up through gpio-keys on sh73a0/kzm9g, where the pcf857x
      interrupt is cascaded to irq-renesas-intc-irqpin, and the latter must
      not be suspended when wake-up is enabled.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      b80eef95
    • G
      gpio: pcf857x: Switch to use gpiolib irqchip helpers · a39294bd
      Geert Uytterhoeven 提交于
      Switch the PCF857x GPIO driver to use the gpiolib irqchip helpers.
      This driver uses a nested threaded interrupt, hence handle_nested_irq()
      and gpiochip_set_chained_irqchip() must be used.
      
      Note that this removes the checks added in commit 21fd3cd1
      ("gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done"),
      as the interrupt mappings are no longer created on-demand by the driver,
      but by gpiochip_irqchip_add() during initialization.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a39294bd
  15. 22 7月, 2014 1 次提交
  16. 28 5月, 2014 2 次提交
    • G
      gpio: pcf857x: Add IRQF_SHARED when request irq · 5795cf35
      George Cherian 提交于
      It's quite possible that multiple pcf857x can be hooked up
      to the same interrupt line with the processor. So add IRQF_SHARED
      in request irq..
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      5795cf35
    • G
      gpio: pcf857x: Avoid calling irq_domain_cleanup twice · e6b698f6
      George Cherian 提交于
      Currently irq_domain_cleanup is called twice if irq_domain_init fails.
      This causes the following crash.
      
      Unable to handle kernel paging request at virtual address 00100104
      pgd = c0004000
      [00100104] *pgd=00000000
      Internal error: Oops: 805 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.12.15-01889-gedd10a8-dirty #4
      Workqueue: deferwq deferred_probe_work_func
      task: ed0ee800 ti: ed116000 task.ti: ed116000
      PC is at irq_domain_remove+0x3c/0x8c
      LR is at 0x0
      pc : [<c0089734>]    lr : [<00000000>]    psr: a0000013
      sp : ed117b50  ip : 00100100  fp : ed117b64
      r10: ed5d1a04  r9 : 00000008  r8 : 00000000
      r7 : ffffffea  r6 : ed5d1a20  r5 : ed5d1a00  r4 : ed5e7540
      r3 : 00200200  r2 : 00100100  r1 : c08aa180  r0 : 00200200
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c53c7d  Table: 8000406a  DAC: 00000017
      Process kworker/u4:0 (pid: 6, stack limit = 0xed116248)
      Stack: (0xed117b50 to 0xed118000)
      7b40:                                     0000016b ed5d5f10 ed117b74 ed117b68
      7b60: c02c8910 c0089704 ed117bb4 ed117b78 c02c8e14 c02c8900 ed5d1a04 ed5d4e80
      ...
      <snip>
      ...
      fe0: 00000000 00000000 00000000 00000000 00000013 00000000 384a13ea 1590210a
      Backtrace:
      [<c00896f8>] (irq_domain_remove+0x0/0x8c) from [<c02c8910>] (pcf857x_irq_domain_cleanup+0x1c/0x20)
       r4:ed5d5f10 r3:0000016b
      [<c02c88f4>] (pcf857x_irq_domain_cleanup+0x0/0x20) from [<c02c8e14>] (pcf857x_probe+0x2a8/0x364)
      [<c02c8b6c>] (pcf857x_probe+0x0/0x364) from [<c04787ac>] (i2c_device_probe+0x80/0xc0)
      [<c047872c>] (i2c_device_probe+0x0/0xc0) from [<c036c33c>] (driver_probe_device+0x104/0x240)
       r6:00000000 r5:ed5d1a20 r4:c08c709c r3:c047872c
      [<c036c238>] (driver_probe_device+0x0/0x240) from [<c036c558>] (__device_attach+0x48/0x4c)
       r7:ed4fc480 r6:c036c510 r5:ed5d1a20 r4:c0866bb8
      [<c036c510>] (__device_attach+0x0/0x4c) from [<c036a6d8>] (bus_for_each_drv+0x4c/0x94)
       r5:ed5d1a20 r4:00000000
      [<c036a68c>] (bus_for_each_drv+0x0/0x94) from [<c036c1f4>] (device_attach+0x78/0x90)
       r6:c087fe50 r5:ed5d1a54 r4:ed5d1a20
      [<c036c17c>] (device_attach+0x0/0x90) from [<c036b76c>] (bus_probe_device+0x8c/0xb4)
       r6:c087fe50 r5:ed5d1a20 r4:ed5d1a20 r3:ed17e1c0
      [<c036b6e0>] (bus_probe_device+0x0/0xb4) from [<c0369888>] (device_add+0x34c/0x624)
       r6:ed5d1a28 r5:00000000 r4:ed5d1a20 r3:fffffffe
      [<c036953c>] (device_add+0x0/0x624) from [<c0369b7c>] (device_register+0x1c/0x20)
      ...
      <snip>
      ...
      [<c0060844>] (process_one_work+0x0/0x37c) from [<c0061040>] (worker_thread+0x13c/0x3c4)
      [<c0060f04>] (worker_thread+0x0/0x3c4) from [<c00670ec>] (kthread+0xac/0xb8)
      [<c0067040>] (kthread+0x0/0xb8) from [<c00148b8>] (ret_from_fork+0x14/0x3c)
       r7:00000000 r6:00000000 r5:c0067040 r4:ed105d20
      Code: e59fc04c e591e000 e59f0048 e154000e (e5823004)
      ---[ end trace 59dd1e90032c4217 ]---
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      e6b698f6
  17. 04 12月, 2013 1 次提交
    • L
      gpio/pinctrl: make gpio_chip members typed boolean · 9fb1f39e
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      9fb1f39e
  18. 24 9月, 2013 1 次提交
  19. 18 9月, 2013 1 次提交
  20. 17 9月, 2013 3 次提交
  21. 24 8月, 2013 2 次提交
  22. 16 8月, 2013 1 次提交
  23. 27 3月, 2013 2 次提交
  24. 07 12月, 2012 1 次提交
  25. 12 9月, 2012 1 次提交
  26. 24 8月, 2012 1 次提交
  27. 12 7月, 2012 1 次提交
  28. 13 12月, 2011 1 次提交
  29. 01 11月, 2011 1 次提交
  30. 07 6月, 2011 1 次提交
  31. 11 8月, 2010 1 次提交
  32. 23 9月, 2009 1 次提交
  33. 19 9月, 2009 1 次提交
  34. 16 1月, 2009 1 次提交
    • B
      gpio: fix probe() error return in gpio driver probes · a342d215
      Ben Dooks 提交于
      A number of drivers in drivers/gpio return -ENODEV when confronted with
      missing setup parameters such as the platform data.  However, returning
      -ENODEV causes the driver layer to silently ignore the driver as it
      assumes the probe did not find anything and was only speculative.
      
      To make life easier to discern why a driver is not being attached, change
      to returning -EINVAL, which is a better description of the fact that the
      driver data was not valid.
      
      Also add a set of dev_dbg() statements to the error paths to provide an
      better explanation of the error as there may be more that one point in the
      driver.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a342d215