1. 02 4月, 2013 1 次提交
    • K
      leds: add new LP5562 LED driver · ff45262a
      Kim, Milo 提交于
      LP5562 can drive up to 4 channels, RGB and White.
      LEDs can be controlled directly via the led class control interface.
      
       LP55xx common driver
        LP5562 is one of LP55xx family device, so LP55xx common code are used.
        On the other hand, chip specific configuration is defined in the structure
        'lp55xx_device_config'
      
       LED pattern data
        LP5562 has also internal program memory which is used for running various LED
        patterns. LP5562 driver supports the firmware interface and the predefined
        pattern data as well.
      
       LP5562 device attributes: 'led_pattern' and 'engine_mux'
        A 'led_pattern' is an index code which runs the predefined pattern data.
        And 'engine_mux' is updated with the firmware interface is activated.
        Detailed description has been updated in the documentation files,
        'leds-lp55xx.txt' and 'leds-lp5562.txt'.
      
       Changes on the header file
        LP5562 configurable definitions are added.
        Pattern RGB data is fixed as constant value.
        (No side effect on other devices, LP5521 or LP5523.)
      
      (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan
      Carpenter <dan.carpenter@oracle.com>)
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: NBryan Wu <cooloney@gmail.com>
      ff45262a
  2. 07 2月, 2013 1 次提交
    • M
      leds-lp55xx: add new common driver for lp5521/5523 · c93d08fa
      Milo(Woogyom) Kim 提交于
       This patch supports basic common driver code for LP5521, LP5523/55231 devices.
      
       ( Driver Structure Data )
      
       lp55xx_led and lp55xx_chip
       In lp55xx common driver, two different data structure is used.
       o lp55xx_led
         control multi output LED channels such as led current, channel index.
       o lp55xx_chip
         general chip control such like the I2C and platform data.
      
       For example, LP5521 has maximum 3 LED channels.
       LP5523/55231 has 9 output channels.
      
       lp55xx_chip for LP5521 ... lp55xx_led #1
                                  lp55xx_led #2
                                  lp55xx_led #3
      
       lp55xx_chip for LP5523 ... lp55xx_led #1
                                  lp55xx_led #2
                                  .
                                  .
                                  lp55xx_led #9
      
       ( Platform Data )
      
       LP5521 and LP5523/55231 have own specific platform data.
       However, this data can be handled with just one platform data structure.
       The lp55xx platform data is declared in the header.
       This structure is derived from leds-lp5521.h and leds-lp5523.h
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: NBryan Wu <cooloney@gmail.com>
      c93d08fa
  3. 13 9月, 2012 1 次提交
  4. 11 9月, 2012 1 次提交
    • G
      leds: Add new LED driver for lm355x chips · b98d13c7
      G.Shark Jeong 提交于
      This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI.
      
      LM3554 :
      The LM3554 is a 2 MHz fixed-frequency synchronous boost
      converter with 1.2A dual high side led drivers.
      Datasheet: www.ti.com/lit/ds/symlink/lm3554.pdf
      
      LM3556 :
      The LM3556 is a 4 MHz fixed-frequency synchronous boost
      converter plus 1.5A constant current driver for a high-current white LED.
      Datasheet: www.national.com/ds/LM/LM3556.pdf
      
      (bryan.wu@canonical.com: use flush_work() to replace flush_work_sync() which is
      deprecated)
      Signed-off-by: NG.Shark Jeong <gshark.jeong@gmail.com>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      b98d13c7
  5. 31 7月, 2012 1 次提交
  6. 26 7月, 2012 1 次提交
    • K
      leds: add new lp8788 led driver · eb80411b
      Kim, Milo 提交于
      TI LP8788 PMU has the current sink as the keyboard led driver.
      The brightness is controlled by the i2c commands.
      Configurable parameters can be defined in the platform side.
      
      Patch v2.
      (a) use workqueue on changing the brightness
      
      (b) use mutex_lock/unlock when the brightness is set
          and the led block of lp8788 device is enabled
      
      (c) remove err_dev on _probe()
          : just return as returned value if any errors
      
      (d) replace module_init/exit() with module_platform_driver()
      
      (e) add led configuration structure and loading them by default
          if platform data is null
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      eb80411b
  7. 24 7月, 2012 3 次提交
  8. 30 5月, 2012 3 次提交
    • J
      leds: add LM3533 LED driver · 401dea7f
      Johan Hovold 提交于
      Add sub-driver for the LEDs on National Semiconductor / TI LM3533 lighting
      power chips.
      
      The chip provides 256 brightness levels, hardware accelerated blinking as
      well as ambient-light-sensor and pwm input control.
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Rob Landley <rob@landley.net>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      401dea7f
    • S
      leds: add new transient trigger for one shot timer activation · 44e1e9f8
      Shuah Khan 提交于
      The leds timer trigger does not currently have an interface to activate a
      one shot timer.  The current support allows for setting two timers, one
      for specifying how long a state to be on, and the second for how long the
      state to be off.  The delay_on value specifies the time period an LED
      should stay in on state, followed by a delay_off value that specifies how
      long the LED should stay in off state.  The on and off cycle repeats until
      the trigger gets deactivated.  There is no provision for one time
      activation to implement features that require an on or off state to be
      held just once and then stay in the original state forever.
      
      Without one shot timer interface, user space can still use timer trigger
      to set a timer to hold a state, however when user space application
      crashes or goes away without deactivating the timer, the hardware will be
      left in that state permanently.
      
      As a specific example of this use-case, let's look at vibrate feature on
      phones.  Vibrate function on phones is implemented using PWM pins on SoC
      or PMIC.  There is a need to activate one shot timer to control the
      vibrate feature, to prevent user space crashes leaving the phone in
      vibrate mode permanently causing the battery to drain.
      
      This trigger exports three properties, activate, state, and duration When
      transient trigger is activated these properties are set to default values.
      
      - duration allows setting timer value in msecs. The initial value is 0.
      - activate allows activating and deactivating the timer specified by
        duration as needed. The initial and default value is 0.  This will allow
        duration to be set after trigger activation.
      - state allows user to specify a transient state to be held for the specified
        duration.
      Signed-off-by: NShuah Khan <shuahkhan@gmail.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: NeilBrown <neilb@suse.de>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      44e1e9f8
    • D
      leds: driver for DA9052/53 PMIC v2 · 5ba73631
      David Dajun Chen 提交于
      LED Driver for Dialog Semiconductor DA9052/53 PMICs.
      
      [akpm@linux-foundation.org: make led_reg static]
      Signed-off-by: NDavid Dajun Chen <dchen@diasemi.com>
      Signed-off-by: NAshish Jangam <ashish.jangam@kpitcummins.com>
      Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ba73631
  9. 24 3月, 2012 1 次提交
  10. 06 3月, 2012 1 次提交
  11. 24 1月, 2012 1 次提交
  12. 11 1月, 2012 1 次提交
  13. 09 1月, 2012 1 次提交
  14. 23 12月, 2011 1 次提交
  15. 01 11月, 2011 1 次提交
    • M
      leds: Renesas TPU LED driver · f59b6f9f
      Magnus Damm 提交于
      Add V2 of the LED driver for a single timer channel for the TPU hardware
      block commonly found in Renesas SoCs.
      
      The driver has been written with optimal Power Management in mind, so to
      save power the LED is driven as a regular GPIO pin in case of maximum
      brightness and power off which allows the TPU hardware to be idle and
      which in turn allows the clocks to be stopped and the power domain to be
      turned off transparently.
      
      Any other brightness level requires use of the TPU hardware in PWM mode.
      TPU hardware device clocks and power are managed through Runtime PM.
      System suspend and resume is known to be working - during suspend the LED
      is set to off by the generic LED code.
      
      The TPU hardware timer is equipeed with a 16-bit counter together with an
      up-to-divide-by-64 prescaler which makes the hardware suitable for
      brightness control.  Hardware blink is unsupported.
      
      The LED PWM waveform has been verified with a Fluke 123 Scope meter on a
      sh7372 Mackerel board.  Tested with experimental sh7372 A3SP power domain
      patches.  Platform device bind/unbind tested ok.
      
      V2 has been tested on the DS2 LED of the sh73a0-based AG5EVM.
      
      [axel.lin@gmail.com: include linux/module.h]
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f59b6f9f
  16. 21 9月, 2011 1 次提交
    • E
      x86: geode: New PCEngines Alix system driver · d4f3e350
      Ed Wildgoose 提交于
      This new driver replaces the old PCEngines Alix 2/3 LED driver with a
      new driver that controls the LEDs through the leds-gpio driver. The
      old driver accessed GPIOs directly, which created a conflict and
      prevented also loading the cs5535-gpio driver to read other GPIOs on
      the Alix board. With this new driver, we hook into leds-gpio which in
      turn uses GPIO to control the LEDs and therefore it's possible to
      control both the LEDs and access onboard GPIOs
      
      Driver is moved to platform/geode as requested by Grant and any other
      geode initialisation modules should move here also
      
      This driver is inspired by leds-net5501.c by Alessandro Zummo.
      
      Ideally, leds-net5501.c should also be moved to platform/geode. 
      Additionally the driver relies on parts of the patch: 7f131cf3 ("leds:
      leds-alix2c - take port address from MSR) by Daniel Mack to perform
      detection of the Alix board.
      
      [akpm@linux-foundation.org: include module.h]
      Signed-off-by: NEd Wildgoose <kernel@wildgooses.com>
      Cc: git@wildgooses.com
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Daniel Mack <daniel@caiaq.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Reviewed-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d4f3e350
  17. 27 5月, 2011 1 次提交
  18. 25 5月, 2011 2 次提交
  19. 23 3月, 2011 1 次提交
  20. 12 11月, 2010 1 次提交
  21. 08 10月, 2010 1 次提交
  22. 17 7月, 2010 1 次提交
  23. 26 5月, 2010 2 次提交
  24. 17 3月, 2010 1 次提交
  25. 08 3月, 2010 1 次提交
  26. 17 12月, 2009 1 次提交
  27. 16 12月, 2009 3 次提交
  28. 07 9月, 2009 1 次提交
    • M
      leds: Add WM831x status LED driver · c746b551
      Mark Brown 提交于
      The WM831x devices feature two software controlled status LEDs with
      hardware assisted blinking.
      
      The device can also autonomously control the LEDs based on a selection
      of sources.  This can be configured at boot time using either platform
      data or the chip OTP.  A sysfs file in the style of that for triggers
      allowing the control source to be configured at run time.  Triggers
      can't be used here since they can't depend on the implementation details
      of a specific LED type.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      c746b551
  29. 24 6月, 2009 1 次提交
  30. 06 4月, 2009 3 次提交
    • K
      leds: add BD2802GU LED driver · 0b56129b
      Kim Kyuwon 提交于
      ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically
      engineered for decoration purposes.  This RGB controller incorporates
      lighting patterns and illuminates.
      
      This driver is designed to minimize power consumption, so when there is no
      emitting LED, it enters to reset state.  And because the BD2802GU has lots
      of features that can't be covered by the current LED framework, it
      provides Advanced Configuration Function(ADF) mode, so that user
      applications can set registers of BD2802GU directly.
      
      Here are basic usage examples :
      ; to turn on LED (not blink)
      $ echo 1 > /sys/class/leds/led1_R/brightness
      ; to blink LED
      $ echo timer > /sys/class/leds/led1_R/trigger
      $ echo 1 > /sys/class/leds/led1_R/delay_on
      $ echo 1 > /sys/class/leds/led1_R/delay_off
      ; to turn off LED
      $ echo 0 > /sys/class/leds/led1_R/brightness
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NKim Kyuwon <chammoru@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      0b56129b
    • F
      leds: Add gpio-led trigger · 17354bfe
      Felipe Balbi 提交于
      The gpio led trigger will allow leds to be triggered by
      gpio events.
      
      When we give the led a gpio number, the trigger will
      request_irq() on that so we don't have to keep polling
      for gpio state.
      
      It's useful for usecases as n810's keypad leds that could
      be triggered by the gpio event generated when user slides
      up to show the keypad.
      
      We also provide means for userland to tell us what is the
      desired brightness for that special led when it goes on
      so userland could use information from ambient light sensors
      and not set led brightness too high if it's not necessary.
      Signed-off-by: NFelipe Balbi <me@felipebalbi.com>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      17354bfe
    • P
      leds: Add rb532 LED driver for the User LED · ac67e23b
      Phil Sutter 提交于
      Mikrotik built six LEDs into the Routerboard 532, from which one is
      destined for custom use, the so called "User LED". This patch adds a
      driver for it, based on the LEDs class.
      Signed-off-by: NPhil Sutter <n0-1@freewrt.org>
      Acked-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
      ac67e23b