1. 25 Jun, 2009 3 commits
  2. 24 Aug, 2009 1 commit
  3. 25 Jun, 2009 7 commits
  4. 02 Sep, 2009 1 commit
    • Daniel Glckner's avatar
      Many gpio chips allow to generate interrupts when the value of a pin · 00742665
      Daniel Glckner authored
      changes.  This patch gives usermode application the opportunity to make
      use of this feature by calling poll(2) on the /sys/class/gpio/gpioN/value
      sysfs file.  The edge to trigger can be set in the edge file in the same
      directory.  Possible values are "none", "rising", "falling", and "both".
      
      Using level triggers is not possible with current sysfs since nothing
      changes the GPIO value (and the IRQ keeps triggering).  Edge triggering
      will "just work".  Note that if there was an event between read() and
      poll(), the poll() returns immediately.
      
      Also note that this version only supports true GPIO interrupts.  Some
      later patch might be able to synthesize this behavior by timer-driven
      polling; some systems seem to need that.
      
      [dbrownell@users.sourceforge.net: align ids to 16 bit ids; whitespace]
      Signed-off-by: default avatarDaniel Glöckner <dg@emlix.com>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      00742665
  5. 04 Aug, 2009 3 commits
  6. 03 Aug, 2009 1 commit
  7. 18 Jul, 2009 1 commit
  8. 24 Aug, 2009 2 commits
  9. 20 Aug, 2009 1 commit
  10. 24 Aug, 2009 1 commit
  11. 18 Jul, 2009 1 commit
  12. 01 Jul, 2009 1 commit
  13. 23 Jun, 2009 1 commit
  14. 09 Sep, 2009 1 commit
  15. 05 Sep, 2009 1 commit
  16. 27 Aug, 2009 1 commit
    • Anton Vorontsov's avatar
      RTC core won't allow wakeup alarms to be set if RTC devices' parent (i.e. · bf104f71
      Anton Vorontsov authored
      i2c_client or spi_device) isn't wakeup capable.
      
      For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass via
      board info, and if set, I2C core will initialize wakeup capability.  For
      SPI devices there is no such flag at all.
      
      I believe that it's not platform code responsibility to allow or disallow
      wakeups, instead, drivers themselves should set the capability if a device
      can trigger wakeups.
      
      That's what drivers/base/power/sysfs.c says:
      
       * It is the responsibility of device drivers to enable (or disable)
       * wakeup signaling as part of changing device power states, respecting
       * the policy choices provided through the driver model.
      
      I2C and SPI RTC devices send wakeup events via interrupt lines, so we
      should set the wakeup capability if IRQ is routed.
      
      Ideally we should also check irq for wakeup capability before setting
      device's capability, i.e.
      
      	if (can_irq_wake(irq))
      		device_set_wakeup_capable(&client->dev, 1);
      
      But there is no can_irq_wake() call exist, and it is not that trivial to
      implement it for all interrupts controllers and complex/cascaded setups.
      
      drivers/base/power/sysfs.c also covers these cases:
      
       * Devices may not be able to generate wakeup events from all power
       * states.  Also, the events may be ignored in some configurations;
       * for example, they might need help from other devices that aren't
       * active
      
      So there is no guarantee that wakeup will actually work, and so I think
      there is no point in being pedantic wrt checking IRQ wakeup capability.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      bf104f71
  17. 02 Sep, 2009 1 commit
  18. 04 Aug, 2009 1 commit
  19. 03 Aug, 2009 1 commit
  20. 18 Aug, 2009 1 commit
  21. 29 Jun, 2009 1 commit
  22. 24 Aug, 2009 2 commits
  23. 05 Sep, 2009 1 commit
  24. 01 Jul, 2009 1 commit
  25. 29 Jun, 2009 2 commits
  26. 26 Jun, 2009 1 commit
  27. 24 Aug, 2009 1 commit