1. 17 Mar, 2017 1 commit
  2. 25 Feb, 2017 1 commit
    • Hans de Goede's avatar
      leds: class: Add new optional brightness_hw_changed attribute · b8c5099b
      Hans de Goede authored
      Some LEDs may have their brightness level changed autonomously
      (outside of kernel control) by hardware / firmware. This commit
      adds support for an optional brightness_hw_changed attribute to
      signal such changes to userspace (if a driver can detect them):
      
      What:		/sys/class/leds/<led>/brightness_hw_changed
      Date:		January 2017
      KernelVersion:	4.11
      Description:
      		Last hardware set brightness level for this LED. Some LEDs
      		may be changed autonomously by hardware/firmware. Only LEDs
      		where this happens and the driver can detect this, will
      		have this file.
      
      		This file supports poll() to detect when the hardware
      		changes the brightness.
      
      		Reading this file will return the last brightness level set
      		by the hardware, this may be different from the current
      		brightness.
      
      Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
      their flags field and call led_classdev_notify_brightness_hw_changed()
      with the hardware set brightness when they detect a hardware / firmware
      triggered brightness change.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      b8c5099b
  3. 29 Jan, 2017 1 commit
    • Hans de Goede's avatar
      leds: class: Add new optional brightness_hw_changed attribute · 0cb8eb30
      Hans de Goede authored
      Some LEDs may have their brightness level changed autonomously
      (outside of kernel control) by hardware / firmware. This commit
      adds support for an optional brightness_hw_changed attribute to
      signal such changes to userspace (if a driver can detect them):
      
      What:		/sys/class/leds/<led>/brightness_hw_changed
      Date:		January 2017
      KernelVersion:	4.11
      Description:
      		Last hardware set brightness level for this LED. Some LEDs
      		may be changed autonomously by hardware/firmware. Only LEDs
      		where this happens and the driver can detect this, will
      		have this file.
      
      		This file supports poll() to detect when the hardware
      		changes the brightness.
      
      		Reading this file will return the last brightness level set
      		by the hardware, this may be different from the current
      		brightness.
      
      Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
      their flags field and call led_classdev_notify_brightness_hw_changed()
      with the hardware set brightness when they detect a hardware / firmware
      triggered brightness change.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      0cb8eb30
  4. 22 Nov, 2016 2 commits
  5. 27 Sep, 2016 1 commit
    • Rafał Miłecki's avatar
      usb: core: Introduce a USB port LED trigger · 0f247626
      Rafał Miłecki authored
      This commit adds a new trigger responsible for turning on LED when USB
      device gets connected to the selected USB port. This can can useful for
      various home routers that have USB port(s) and a proper LED telling user
      a device is connected.
      
      The trigger gets its documentation file but basically it just requires
      enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
      
      There was a long discussion on design of this driver. Its current state
      is a result of picking them most adjustable solution as others couldn't
      handle all cases.
      
      1) It wasn't possible for the driver to register separated trigger for
         each USB port. Some physical USB ports are handled by more than one
         controller and so by more than one USB port. E.g. USB 2.0 physical
         port may be handled by OHCI's port and EHCI's port.
         It's also not possible to assign more than 1 trigger to a single LED
         and implementing such feature would be tricky due to syncing triggers
         and sysfs conflicts with old triggers.
      
      2) Another idea was to register trigger per USB hub. This wouldn't allow
         handling devices with multiple USB LEDs and controllers (hubs)
         controlling more than 1 physical port. It's common for hubs to have
         few ports and each may have its own LED.
      
      This final trigger is highly flexible. It allows selecting any USB ports
      for any LED. It was also modified (comparing to the initial version) to
      allow choosing ports rather than having user /guess/ proper names. It
      was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
      2 physical ports and 3 controllers.
      
      It was noted USB subsystem already has usb-gadget and usb-host triggers
      but they are pretty trivial ones. They indicate activity only and can't
      have ports specified.
      
      In future it may be good idea to consider adding activity support to
      usbport as well. This should allow switching to this more generic driver
      and maybe marking old ones as obsolete.
      This can be implemented with another sysfs file for setting mode. The
      default mode wouldn't change so there won't be ABI breakage and so such
      feature can be safely implemented later.
      
      There was also an idea of supporting other devices (PCI, SDIO, etc.) but
      as this driver already contains some USB specific code (and will get
      more) these should be probably separated drivers (triggers).
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f247626
  6. 15 Sep, 2016 1 commit
    • Vadim Pasternak's avatar
      leds: add driver for Mellanox systems LEDs · be4fdf99
      Vadim Pasternak authored
      This makes it possible to create a set of LEDs for Mellanox systems:
      "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
      "msb7800", "msn2740", "msn2100".
      
      Driver obtains LED devices according to system configuration, provided
      through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and
      creates devices in form: "devicename:colour:function".
      
      LED setting is controlled through on board CPLD Lattice device.
      For setting particular LED off, solid, blink:
      echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness
      echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness
      echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger
      
      On module probing all LEDs are set green, on removing - off.
      
      Last setting overwrites previous, f.e. sequence for
      changing LED from green - red - green:
      echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
      echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness
      echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
      Note: LEDs cannot be turned on/off simultaneously.
      
      The Kconfig currently controlling compilation of this code is:
      drivers/leds/Kconfig:config LEDS_MLXCPLD
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      be4fdf99
  7. 29 Aug, 2016 1 commit
  8. 27 Jun, 2016 1 commit
  9. 08 Jun, 2016 1 commit
    • Tony Makkiel's avatar
      leds: core: Fix brightness setting upon hardware blinking enabled · 7cfe749f
      Tony Makkiel authored
      Commit 76931edd ("leds: fix brightness changing when software blinking
      is active") changed the semantics of led_set_brightness() which according
      to the documentation should disable blinking upon any brightness setting.
      Moreover it made it different for soft blink case, where it was possible
      to change blink brightness, and for hardware blink case, where setting
      any brightness greater than 0 was ignored.
      
      While the change itself is against the documentation claims, it was driven
      also by the fact that timer trigger remained active after turning blinking
      off. Fixing that would have required major refactoring in the led-core,
      led-class, and led-triggers because of cyclic dependencies.
      
      Finally, it has been decided that allowing for brightness change during
      blinking is beneficial as it can be accomplished without disturbing
      blink rhythm.
      
      The change in brightness setting semantics will not affect existing
      LED class drivers that implement blink_set op thanks to the LED_BLINK_SW
      flag introduced by this patch. The flag state will be from now on checked
      in led_set_brightness() which will allow to distinguish between software
      and hardware blink mode. In the latter case the control will be passed
      directly to the drivers which apply their semantics on brightness set,
      which is disable the blinking in case of most such drivers. New drivers
      will apply new semantics and just change the brightness while hardware
      blinking is on, if possible.
      
      The issue was smuggled by subsequent LED core improvements, which modified
      the code that originally introduced the problem.
      
      Fixes: f1e80c07 ("leds: core: Add two new LED_BLINK_ flags")
      Signed-off-by: default avatarTony Makkiel <tony.makkiel@daqri.com>
      Signed-off-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      7cfe749f
  10. 04 Jan, 2016 1 commit
  11. 12 Jun, 2015 1 commit
    • Samuel Thibault's avatar
      Input: export LEDs as class devices in sysfs · f60c8ba7
      Samuel Thibault authored
      This change creates a new input handler called "leds" that exports LEDs on input
      devices as standard LED class devices in sysfs and allows controlling their
      state via sysfs or via any of the standard LED triggers. This allows to
      re-purpose and reassign LDEs on the keyboards to represent states other
      than the standard keyboard states (CapsLock, NumLock, etc).
      
      The old API of controlling input LEDs by writing into /dev/input/eventX
      devices is still present and will take precedence over accessing via LEDs
      subsystem (i.e. it may override state set by a trigger). If input device is
      "grabbed" then requests coming through LED subsystem will be ignored.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Tested-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Acked-by: Pavel Machek's avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      f60c8ba7
  12. 10 Jun, 2015 1 commit
  13. 25 May, 2015 1 commit
  14. 10 Mar, 2015 1 commit
  15. 11 Feb, 2014 1 commit
    • Henrik Austad's avatar
      Documentation/: update 00-INDEX files · 3cf8ca1c
      Henrik Austad authored
      Some of the 00-INDEX files are somewhat outdated and some folders does
      not contain 00-INDEX at all.  Only outdated (with the notably exception
      of spi) indexes are touched here, the 169 folders without 00-INDEX has
      not been touched.
      
      New 00-INDEX
       - spi/* was added in a series of commits dating back to 2006
      
      Added files (missing in (*/)00-INDEX)
       - dmatest.txt was added by commit 851b7e16 ("dmatest: run test via
         debugfs")
       - this_cpu_ops.txt was added by commit a1b2a555 ("percpu: add
         documentation on this_cpu operations")
       - ww-mutex-design.txt was added by commit 040a0a37 ("mutex: Add
         support for wound/wait style locks")
       - bcache.txt was added by commit cafe5635 ("bcache: A block layer
         cache")
       - kernel-per-CPU-kthreads.txt was added by commit 49717cb4
         ("kthread: Document ways of reducing OS jitter due to per-CPU
         kthreads")
       - phy.txt was added by commit ff764963 ("drivers: phy: add generic
         PHY framework")
       - block/null_blk was added by commit 12f8f4fc ("null_blk:
         documentation")
       - module-signing.txt was added by commit 3cafea30 ("Add
         Documentation/module-signing.txt file")
       - assoc_array.txt was added by commit 3cb98950 ("Add a generic
         associative array implementation.")
       - arm/IXP4xx was part of the initial repo
       - arm/cluster-pm-race-avoidance.txt was added by commit 7fe31d28
         ("ARM: mcpm: introduce helpers for platform coherency exit/setup")
       - arm/firmware.txt was added by commit 7366b92a ("ARM: Add
         interface for registering and calling firmware-specific operations")
       - arm/kernel_mode_neon.txt was added by commit 2afd0a05 ("ARM:
         7825/1: document the use of NEON in kernel mode")
       - arm/tcm.txt was added by commit bc581770 ("ARM: 5580/2: ARM TCM
         (Tightly-Coupled Memory) support v3")
       - arm/vlocks.txt was added by commit 9762f12d ("ARM: mcpm: Add
         baremetal voting mutexes")
       - blackfin/gptimers-example.c, Makefile was added by commit
         4b60779d ("Blackfin: add an example showing how to use the
         gptimers API")
       - devicetree/usage-model.txt was added by commit 31134efc ("dt:
         Linux DT usage model documentation")
       - fb/api.txt was added by commit fb21c2f4 ("fbdev: Add FOURCC-based
         format configuration API")
       - fb/sm501.txt was added by commit e6a04980 ("video, sm501: add
         edid and commandline support")
       - fb/udlfb.txt was added by commit 96f8d864 ("fbdev: move udlfb out
         of staging.")
       - filesystems/Makefile was added by commit 1e0051ae
         ("Documentation/fs/: split txt and source files")
       - filesystems/nfs/nfsd-admin-interfaces.txt was added by commit
         8a4c6e19 ("nfsd: document kernel interfaces for nfsd
         configuration")
       - ide/warm-plug-howto.txt was added by commit f74c9141 ("ide: add
         warm-plug support for IDE devices (take 2)")
       - laptops/Makefile was added by commit d49129ac
         ("Documentation/laptop/: split txt and source files")
       - leds/leds-blinkm.txt was added by commit b54cf35a ("LEDS: add
         BlinkM RGB LED driver, documentation and update MAINTAINERS")
       - leds/ledtrig-oneshot.txt was added by commit 5e417281 ("leds: add
         oneshot trigger")
       - leds/ledtrig-transient.txt was added by commit 44e1e9f8 ("leds:
         add new transient trigger for one shot timer activation")
       - m68k/README.buddha was part of the initial repo
       - networking/LICENSE.(qla3xxx|qlcnic|qlge) was added by commits
         40839129, c4e84bde, 5a4faa87
       - networking/Makefile was added by commit 3794f3e8 ("docsrc: build
         Documentation/ sources")
       - networking/i40evf.txt was added by commit 105bf2fe ("i40evf: add
         driver to kernel build system")
       - networking/ipsec.txt was added by commit b3c6efbc ("xfrm: Add
         file to document IPsec corner case")
       - networking/mac80211-auth-assoc-deauth.txt was added by commit
         3cd7920a ("mac80211: add auth/assoc/deauth flow diagram")
       - networking/netlink_mmap.txt was added by commit 5683264c
         ("netlink: add documentation for memory mapped I/O")
       - networking/nf_conntrack-sysctl.txt was added by commit c9f9e0e1
         ("netfilter: doc: add nf_conntrack sysctl api documentation") lan)
       - networking/team.txt was added by commit 3d249d4c ("net: introduce
         ethernet teaming device")
       - networking/vxlan.txt was added by commit d342894c ("vxlan:
         virtual extensible lan")
       - power/runtime_pm.txt was added by commit 5e928f77 ("PM: Introduce
         core framework for run-time PM of I/O devices (rev.  17)")
       - power/charger-manager.txt was added by commit 3bb3dbbd
         ("power_supply: Add initial Charger-Manager driver")
       - RCU/lockdep-splat.txt was added by commit d7bd2d68 ("rcu:
         Document interpretation of RCU-lockdep splats")
       - s390/kvm.txt was added by 5ecee4ba (KVM: s390: API documentation)
       - s390/qeth.txt was added by commit b4d72c08 ("qeth: bridgeport
         support - basic control")
       - scheduler/sched-bwc.txt was added by commit 88ebc08e ("sched: Add
         documentation for bandwidth control")
       - scsi/advansys.txt was added by commit 4bd6d7f3 ("[SCSI] advansys:
         Move documentation to Documentation/scsi")
       - scsi/bfa.txt was added by commit 1ec90174 ("[SCSI] bfa: add
         readme file")
       - scsi/bnx2fc.txt was added by commit 12b8fc10 ("[SCSI] bnx2fc: Add
         driver documentation")
       - scsi/cxgb3i.txt was added by commit c3673464 ("[SCSI] cxgb3i: Add
         cxgb3i iSCSI driver.")
       - scsi/hpsa.txt was added by commit 992ebcf1 ("[SCSI] hpsa: Add
         hpsa.txt to Documentation/scsi")
       - scsi/link_power_management_policy.txt was added by commit
         ca77329f ("[libata] Link power management infrastructure")
       - scsi/osd.txt was added by commit 78e0c621 ("[SCSI] osd:
         Documentation for OSD library")
       - scsi/scsi-parameter.txt was created/moved by commit 163475fb
         ("Documentation: move SCSI parameters to their own text file")
       - serial/driver was part of the initial repo
       - serial/n_gsm.txt was added by commit 323e8412 ("n_gsm: add a
         documentation")
       - timers/Makefile was added by commit 3794f3e8 ("docsrc: build
         Documentation/ sources")
       - virt/kvm/s390.txt was added by commit d9101fca ("KVM: s390:
         diagnose call documentation")
       - vm/split_page_table_lock was added by commit 49076ec2 ("mm:
         dynamically allocate page->ptl if it cannot be embedded to struct
         page")
       - w1/slaves/w1_ds28e04 was added by commit fbf7f7b4 ("w1: Add
         1-wire slave device driver for DS28E04-100")
       - w1/masters/omap-hdq was added by commit e0a29382 ("hdq:
         documentation for OMAP HDQ")
       - x86/early-microcode.txt was added by commit 0d91ea86 ("x86, doc:
         Documentation for early microcode loading")
       - x86/earlyprintk.txt was added by commit a1aade47 ("x86/doc:
         mini-howto for using earlyprintk=dbgp")
       - x86/entry_64.txt was added by commit 8b4777a4 ("x86-64: Document
         some of entry_64.S")
       - x86/pat.txt was added by commit d27554d8 ("x86: PAT
         documentation")
      
      Moved files
       - arm/kernel_user_helpers.txt was moved out of arch/arm/kernel by
         commit 37b83046 ("ARM: kuser: move interface documentation out of
         the source code")
       - efi-stub.txt was moved out of x86/ and down into Documentation/ in
         commit 4172fe2f ("EFI stub documentation updates")
       - laptops/hpfall.c was moved out of hwmon/ and into laptops/ in commit
         efcfed9b ("Move hp_accel to drivers/platform/x86")
       - commit 5616c23a ("x86: doc: move x86-generic documentation from
         Doc/x86/i386"):
         * x86/usb-legacy-support.txt
         * x86/boot.txt
         * x86/zero_page.txt
       - power/video_extension.txt was moved to acpi in commit 70e66e4d
         ("ACPI / video: move video_extension.txt to Documentation/acpi")
      
      Removed files (left in 00-INDEX)
       - memory.txt was removed by commit 00ea8990 ("memory.txt: remove
         stray information")
       - gpio.txt was moved to gpio/ in commit fd8e198c ("Documentation:
         gpiolib: document new interface")
       - networking/DLINK.txt was removed by commit 168e06ae
         ("drivers/net: delete old parallel port de600/de620 drivers")
       - serial/hayes-esp.txt was removed by commit f53a2ade ("tty: esp:
         remove broken driver")
       - s390/TAPE was removed by commit 9e280f66 ("[S390] remove tape
         block docu")
       - vm/locking was removed by commit 57ea8171 ("mm: documentation:
         remove hopelessly out-of-date locking doc")
       - laptops/acer-wmi.txt was remvoed by commit 02003667 ("acer-wmi:
         Delete out-of-date documentation")
      
      Typos/misc issues
       - rpc-server-gss.txt was added as knfsd-rpcgss.txt in commit
         030d794b ("SUNRPC: Use gssproxy upcall for server RPCGSS
         authentication.")
       - commit b88cf73d ("net: add missing entries to
         Documentation/networking/00-INDEX")
         * generic-hdlc.txt was added as generic_hdlc.txt
         * spider_net.txt was added as spider-net.txt
       - w1/master/mxc-w1 was added as mxc_w1 by commit a5fd9139 ("w1: add
         1-wire master driver for i.MX27 / i.MX31")
       - s390/zfcpdump.txt was added as zfcpdump by commit 6920c12a
         ("[S390] Add Documentation/s390/00-INDEX.")
      Signed-off-by: default avatarHenrik Austad <henrik@austad.us>
      Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>	[rcu bits]
      Acked-by: default avatarRob Landley <rob@landley.net>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: James Bottomley <JBottomley@parallels.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3cf8ca1c
  16. 28 Jan, 2014 1 commit
    • Milo Kim's avatar
      leds: lp5523: Support LED MUX configuration on running a pattern · 93ad8a1d
      Milo Kim authored
      There are two ways to run a pattern in LP5523.
      One is using legacy sysfs files such as 'enginex_mode','enginex_load' and
      'enginex_leds'. ('x' is from 1 to 3).
      Among them, 'enginex_leds' are used for selecting specific LED channel MUX.
      (MUX means which LEDs are used for running a pattern from LED 1 to 9.)
      
      The other way is using the firmware interface.
      In this mode, the default LED MUX strings are used.
      In other words, LED MUX is not configurable on the fly.
      
      This patch enables dynamic LED MUX configuration when the firmware is loaded.
      By accessing the sysfs file 'enginex_leds', the LED channels can be configured.
      To synchronize the operation mode, each engine mode should be set to 'LOAD'.
      
      The documentation is updated as well.
      
      Cc: Pali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarMilo Kim <milo.kim@ti.com>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      93ad8a1d
  17. 27 Aug, 2013 3 commits
    • Milo Kim's avatar
      Documentation: leds-lp5521,lp5523: update device attribute information · 863724a6
      Milo Kim authored
      Now, all legacy application interfaces are restored.
      Each driver documentation is updated.
      
      Cc: Pali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarMilo Kim <milo.kim@ti.com>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      863724a6
    • Sachin Kamat's avatar
      Documentation: leds: Fix a typo · e5862b9a
      Sachin Kamat authored
      __initdata should be placed between the variable name and equal
      sign for the variable to be placed in the intended section.
      Fix the example.
      Signed-off-by: default avatarSachin Kamat <sachin.kamat@linaro.org>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      e5862b9a
    • Kim, Milo's avatar
      leds: support new LP8501 device - another LP55xx common · 33b3a561
      Kim, Milo authored
      LP8501 can drive up to 9 channels like LP5523.
      LEDs can be controlled directly via the I2C and programmable engines are
      supported.
      
      LP55xx common driver
       LP8501 is one of LP55xx family device, so LP55xx common code are used.
       Chip specific data is defined in the structure, 'lp55xx_device_config'.
      
      Differences between LP8501 and LP5523
       Different register layout for LED output control and others.
       LP8501 specific feature for separate output power selection.
       LP8501 doesn't support external clock detection.
       Different programming engine data.
      
      LP8501 specific feature - output power selection
       Output channels are selected by power selection - Vout or Vdd.
       Separate power for VDD1-6 and VDD7-9 are available.
       It is configurable in the platform data.
       To support this feature, LP55xx DT structure and header are changed.
       Device tree binding is updated as well.
      
      LED pattern data
       Example pattern data is updated in the driver documentation.
      Signed-off-by: default avatarMilo Kim <milo.kim@ti.com>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      33b3a561
  18. 20 Aug, 2013 1 commit
  19. 01 Apr, 2013 2 commits
    • Kim, Milo's avatar
      leds: lp55xx: configure the clock detection · 81f2a5b4
      Kim, Milo authored
      Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used().
      The clock configuration can be done by the driver itself.
      
      (a) Concept
      The default value is set by each driver with clock selection.
      The internal clock selection bit is updated in case that the external clock
      is not detected or clock rate is not 32KHz.
      
      (b) Change on LP55xx platform data
      The clock configuration is done automatically, so no need to define
      'update_config' in the platform side.
      Correlated information are removed in the documentations and header.
      
      (c) Definitions moved from header to driver files
      CONFIG register values are moved each driver, LP5521 and LP5562.
      Not necessary definitions are removed also.
      Signed-off-by: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      81f2a5b4
    • Kim, Milo's avatar
      leds: add new LP5562 LED driver · ff45262a
      Kim, Milo authored
      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: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      ff45262a
  20. 06 Feb, 2013 1 commit
  21. 11 Sep, 2012 1 commit
  22. 24 Jul, 2012 1 commit
  23. 23 Jul, 2012 2 commits
  24. 29 May, 2012 1 commit
    • Shuah Khan's avatar
      leds: add new transient trigger for one shot timer activation · 44e1e9f8
      Shuah Khan authored
      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: default avatarShuah 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      44e1e9f8
  25. 23 Mar, 2012 3 commits
  26. 04 Nov, 2011 1 commit
  27. 05 Apr, 2011 1 commit
  28. 12 Nov, 2010 1 commit