| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add the driver to support User LEDs on PXI Embedded Controller.
Signed-off-by: Hui Chun Ong <hui.chun.ong@ni.com>
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
This driver creates a userspace leds driver similar to uinput.
New LEDs are created by opening /dev/uleds and writing a uleds_user_dev
struct. A new LED class device is registered with the name given in the
struct. Reading will return a single byte that is the current brightness.
The poll() syscall is also supported. It will be triggered whenever the
brightness changes. Closing the file handle to /dev/uleds will remove
the leds class device.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
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: Vadim Pasternak <vadimp@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
This adds a driver for the six PM8058 LEDs, three ordinary LEDs,
two "flash" LEDs and one "keypad" LED.
The "keypad" and "flash" LEDs are not really hard-wired to these
usecases: for example on the APQ8060 Dragonboard, the "keypad"
LED is instead used to drive an IR LED used for the proximity
sensor. The "flash" LEDs are just ordinary high-current LED
drivers.
Cc: linux-arm-msm@vger.kernel.org
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
This is a driver for the Integrated Silicon Solution Inc. LED driver
chips series IS31FL319x. They can drive 1, 3, 6 or up to 9
LEDs.
Each LED is individually controllable in brightness (through pwm)
in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors.
The maximum current of the LEDs can be programmed and limited to
5 .. 40mA through a device tree property.
The chip is connected through I2C and can have one of 4 addresses
in the range 0x64 .. 0x67 depending on how the AD pin is connected. The
address is defined by the reg property as usual.
The chip also has a shutdown input which could be connected to a GPIO,
but this driver uses software shutdown if all LEDs are inactivated.
The chip also has breathing and audio features which are not fully
supported by this driver.
Tested-on: OMAP5 based Pyra handheld prototype.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
The chip can drive 2 sets of RGB leds. Controller can
be controlled via PWM, I2C and audio synchronisation.
This driver uses I2C to communicate with the chip.
Datasheet: http://www.ti.com/lit/gpn/lp3952
Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.
The programming paradigm of these devices is similar in the following
ways:
- All registers are 8 bit
- All LED control registers are write-only
- Each LED channel has a PWM register (0-255)
- PWM register writes are shadowed until an Update register is poked
- All have a concept of Software Shutdown, which disables output
However, there are some differences in devices:
- 3236/3235 have a separate Control register for each LED,
(3218/3216 pack the enable bits into fewer registers)
- 3236/3235 have a per-channel current divisor setting
- 3236/3235 have a Global Control register that can turn off all LEDs
- 3216 is unique in a number of ways
- OUT9-OUT16 can be configured as GPIOs instead of LED controls
- LEDs can be programmed with an 8-frame animation, with
programmable delay between frames
- LEDs can be modulated by an input audio signal
- Max output current can be adjusted from 1/4 to 2x globally
- Has a Configuration register instead of a Shutdown register
This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
- All devices are capable of going into a lower-power "software
shutdown" mode.
- The is31fl3236 and is31fl3235 can reduce the max output current
per-channel with a divisor of 1, 2, 3, or 4.
- The is31fl3216 can use some LED channels as GPIOs instead.
- The is31fl3216 can animate LEDs in hardware.
- The is31fl3216 can modulate LEDs according to an audio input.
- The is31fl3216 can reduce/increase max output current globally.
Signed-off-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Fixes the following randconfig problem
leds-sead3.c:(.text+0x7dc): undefined reference to `led_classdev_unregister'
leds-sead3.c:(.text+0x7e8): undefined reference to `led_classdev_unregister'
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-leds@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
Pull backlight updates from Lee Jones:
- Stop using LP855X Platform Data to control regulators
- Move PWM8941 WLED driver into Backlight
- Remove invalid use of IS_ERR_VALUE() macro
- Remove duplicate check for NULL data before unregistering
- Export I2C Device ID structure
* tag 'backlight-for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
backlight: tosa: Export I2C module alias information
backlight: lp8788_bl: Delete a check before backlight_device_unregister()
backlight: sky81452: Remove unneeded use of IS_ERR_VALUE() macro
backlight: pm8941-wled: Move PM8941 WLED driver to backlight
backlight: lp855x: Use private data for regulator control
|
|
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.
All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.
<location_code>:<attention|identify|fault>
Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.
The platform level implementation of LED get and set state has been
achieved through OPAL calls. These calls are made available for the
driver by exporting from architecture specific codes.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Tested-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This adds support for the LED controller on Broadcom's BCM6358.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Varka Bhadram <varkabhadram@gmail.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This adds support for the LED controller on Broadcom's BCM6328.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch adds a driver for the 1.5A Step-Up Current Regulator
for Flash LEDs. The device is programmed through a Skyworks proprietary
AS2Cwire serial digital interface.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
The TLC59116 is an I2C bus controlled 16-channel LED driver. The
TLC59108 is an I2C bus controlled 8-channel LED driver, which is very
similar to the TLC59116. Each LED output has its own 8-bit
fixed-frequency PWM controller to control the brightness of the LED.
The LEDs can also be fixed off and on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Imre Kaloz <kaloz@openwrt.org>
Cc: Matthew.Fatheree@belkin.com
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
(cooloney@gmail.com: remove unneeded semicolon)
Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault,
flash_sync_strobe and available_sync_leds. All the flash related
features are placed in a separate module.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Introduce the Texas Instruments lp8860
4 channel LED driver.
This driver configures the device in display cluster mode
as this seems to be the most used configuration at the
time of the driver configuration.
For more product information please see the link below:
http://www.ti.com/product/lp8860-q1
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon updates from Guenter Roeck:
- new driver for menf21bmc.
- convert k10temp, smsc47b397, da9052, da9055 to new hwmon API.
- register ntc_thermistor driver with thermal subsystem.
- add support for F15h M60h to k10temp driver.
- add driver for MEN14F021P00 BMC HWMON driver; this required a merge
with tag mfd-hwmon-leds-watchdog-v3.18
* tag 'hwmon-for-linus-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (ab8500) Call kernel_power_off instead of pm_power_off
hwmon: (menf21bmc) Introduce MEN14F021P00 BMC HWMON driver
leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver
watchdog: menf21bmc_wdt: Introduce MEN 14F021P00 BMC Watchdog driver
mfd: menf21bmc: Introduce MEN 14F021P00 BMC MFD Core driver
hwmon: (ntc_thermistor) Add ntc thermistor to thermal subsystem as a sensor.
hwmon: (smsc47b397) Convert to devm_hwmon_device_register_with_groups
MAINTAINERS: add entry for the PWM fan driver
hwmon: (k10temp) Convert to devm_hwmon_device_register_with_groups
hwmon: (k10temp) Add support for F15h M60h
hwmon: (da9052) Convert to devm_hwmon_device_register_with_groups
hwmon: (da9055) Convert to devm_hwmon_device_register_with_groups
hwmon: (ads1015) Use of_property_read_u32 at appropriate places
|
|
This makes it possible to create a set of LEDs from a syscon
MFD instance, which is lean mean and clean on the ARM
reference designs and can replace the Versatile LEDs driver
in the long run, as well as other custom syscon LEDs drivers.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
[Fixed cocinelle warnings]
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner <andreas.werner@men.de>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver changes from Olof Johansson:
"A handful of driver-related changes. We've had a bunch of them going
in through other branches as well, so it's only a part of what we
really have this release.
Larger pieces are:
- Removal of a now unused PWM driver for atmel
[ This includes AVR32 changes that have been appropriately acked ]
- Performance counter support for the arm CCN interconnect
- OMAP mailbox driver cleanups and consolidation
- PCI and SATA PHY drivers for SPEAr 13xx platforms
- Redefinition (with backwards compatibility!) of PCI DT bindings for
Tegra to better model regulators/power"
Note: this merge also fixes up the semantic conflict with the new
calling convention for devm_phy_create(), see commit f0ed817638b5 ("phy:
core: Let node ptr of PHY point to PHY and not of PHY provider") that
came in through Greg's USB tree.
Semantic merge patch by Stephen Rothwell <sfr@canb.auug.org.au> through
the next tree.
* tag 'drivers-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (38 commits)
bus: arm-ccn: Fix error handling at event allocation
mailbox/omap: add a parent structure for every IP instance
mailbox/omap: remove the private mailbox structure
mailbox/omap: consolidate OMAP mailbox driver
mailbox/omap: simplify the fifo assignment by using macros
mailbox/omap: remove omap_mbox_type_t from mailbox ops
mailbox/omap: remove OMAP1 mailbox driver
mailbox/omap: use devm_* interfaces
bus: ARM CCN: add PERF_EVENTS dependency
bus: ARM CCN PMU driver
PCI: spear: Remove spear13xx_pcie_remove()
PCI: spear: Fix Section mismatch compilation warning for probe()
ARM: tegra: Remove legacy PCIe power supply properties
PCI: tegra: Remove deprecated power supply properties
PCI: tegra: Implement accurate power supply scheme
ARM: SPEAr13xx: Update defconfigs
ARM: SPEAr13xx: Add pcie and miphy DT nodes
ARM: SPEAr13xx: Add bindings and dt node for misc block
ARM: SPEAr13xx: Fix static mapping table
phy: Add drivers for PCIe and SATA phy on SPEAr13xx
...
|
|
This adds a driver for the iPAQ microcontroller LED.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
The leds-atmel-pwm driver is now obsolete. It is not used by any mainlined
boards and is replaced by the generic leds_pwm with the pwm-atmel driver using
the generic PWM framework.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull LED updates from Bryan Wu:
"I just found merge window is open and I'm quite busy and almost forget
to send out this pull request. Thanks Russell and Alexandre ping me
about this.
So basically we got some clean up and leds-pwm fixing patches from
Russell"
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: Remove duplicated OOM message for individual driver
drivers/leds: Replace __get_cpu_var use through this_cpu_ptr
leds: lp55xx: add DT bindings for LP55231
leds: 88pm860x: Fix missing refcount decrement for parent of_node
leds: 88pm860x: Use of_get_child_by_name
leds: leds-pwm: add DT support for LEDs wired to supply
leds: leds-pwm: implement PWM inversion
leds: leds-pwm: convert OF parsing code to use led_pwm_add()
leds: leds-pwm: provide a common function to setup a single led-pwm device
leds: pca9685: Remove leds-pca9685 driver
dell-led: add mic mute led interface
|
|
This driver is replaced by pwm-pca9685 driver and there is no user uses this
driver in current tree. So remove it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Maximilian Güntner <maximilian.guentner@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
Now that we have converted this driver to a real platform device
module-based thing, we move the driver down into the LEDs
subsystem and rename the config option to LEDS_VERSATILE.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Pawel Moll <pawel.moll@arm.com>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
levels of brightness)
This driver supports configuration using platform_data.
Signed-off-by: Maximilian Güntner <maximilian.guentner@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull led updates from Bryan Wu:
"Sorry for the late pull request, since I'm just back from vacation.
LED subsystem updates for 3.12:
- pca9633 driver DT supporting and pca9634 chip supporting
- restore legacy device attributes for lp5521
- other fixing and updates"
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (28 commits)
leds: wm831x-status: Request a REG resource
leds: trigger: ledtrig-backlight: Fix invalid memory access in fb_event notification callback
leds-pca963x: Fix device tree parsing
leds-pca9633: Rename to leds-pca963x
leds-pca9633: Add mutex to the ledout register
leds-pca9633: Unique naming of the LEDs
leds-pca9633: Add support for PCA9634
leds: lp5562: use LP55xx common macros for device attributes
Documentation: leds-lp5521,lp5523: update device attribute information
leds: lp5523: remove unnecessary writing commands
leds: lp5523: restore legacy device attributes
leds: lp5523: LED MUX configuration on initializing
leds: lp5523: make separate API for loading engine
leds: lp5521: remove unnecessary writing commands
leds: lp5521: restore legacy device attributes
leds: lp55xx: add common macros for device attributes
leds: lp55xx: add common data structure for program
Documentation: leds: Fix a typo
leds: ss4200: Fix incorrect placement of __initdata
leds: clevo-mail: Fix incorrect placement of __initdata
...
|
|
The driver now supports the chips pca9633 and pca9634, therefore we
rename the files to more generic and meaningul names
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
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: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
The driver is superseded by the generic pwm-renesas-tpu driver used with
leds-pwm.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
For better driver management, new subdirectory, 'trigger' is created.
All LED trigger drivers are moved into this directory.
Internal header, 'leds.h' is included in each LED trigger drivers.
Fix the location of header file, "leds.h" -> "../leds.h" in driver files.
One exception is here, 'ledtrig-timer.c'.
There is no need to include 'leds.h'. so '#include "leds.h"' line was removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
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: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
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: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull LED subsystem update from Bryan Wu.
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (24 commits)
leds: add output driver configuration for pca9633 led driver
leds: lm3642: Use regmap_update_bits() in lm3642_chip_init()
leds: Add new LED driver for lm3642 chips
leds-lp5523: Fix riskiness of the page fault
leds-lp5523: turn off the LED engines on unloading the driver
leds-lm3530: Fix smatch warnings
leds-lm3530: Use devm_regulator_get function
leds: leds-gpio: adopt pinctrl support
leds: Add new LED driver for lm355x chips
leds-lp5523: use the i2c device id rather than fixed name
leds-lp5523: add new device id for LP55231
leds-lp5523: support new LP55231 device
leds: triggers: send uevent when changing triggers
leds-lp5523: minor code style fixes
leds-lp5523: change the return type of lp5523_set_mode()
leds-lp5523: set the brightness to 0 forcely on removing the driver
leds-lp5523: add channel name in the platform data
leds: leds-gpio: Use of_get_child_count() helper
leds: leds-gpio: Use platform_{get,set}_drvdata
leds: leds-gpio: use of_match_ptr()
...
|
|
This driver is a general version for LM642 led chip of TI.
LM3642 :
The LM3642 is a 4MHz fixed-frequency synchronous boost
converter plus 1.5A constant current driver for a high-current
white LED.
The LM3642 is controlled via an I2C-compatible interface.
Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
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: G.Shark Jeong <gshark.jeong@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds into next/drivers
From Bryan Wu <bryan.wu@canonical.com>:
Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a
new generic led trigger for CPU not only for ARM but also for others.
For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to
trigger idle start or idle end event.
These patches convert old style LED driver in arch/arm to gpio_led or new led
driver interface. Against 3.5 release and build successfully for all the machines.
Test ledtrig-cpu driver on OMAP4 Panda board.
v9 --> v10
* fix compiling issue on versatile_defconfig reported by Russell King
* rebase to 3.5 kernel and move patches to new git tree
v8 --> v9:
* use mutex to replace rw_sema pointed out by Tim Gardner
* add a new struct led_trigger_cpu
* add lock_is_inited to record mutex lock initialization
v6 --> v7:
* add a patch to unify the led-trigger name
* fix some typo pointed
* use BUG_ON to detect CPU numbers during building stage
v5 --> v6:
* replace __get_cpu_var() to per_cpu()
* remove smp_processor_id() which is wrong with for_each_possible_cpu()
* test on real OMAP4 Panda board
* add comments about CPU hotplug in the CPU LED trigger driver
v4 --> v5:
* rebase all the patches on top of latest linux-next
* replace on_each_cpu() with for_each_possible_cpu()
* add some description of ledtrig_cpu() API
* remove old leds code from driver nwflash.c, which should use a new led trigger then
* this trigger driver can be built as module now
v3 --> v4:
* fix a typo pointed by Jochen Friedrich
* fix some building errors
* add Reviewed-by and Tested-by into patch log
v2 --> v3:
* almost rewrote the whole ledtrig-cpu driver, which is more simple
* every CPU will have a per-CPU trigger
* cpu trigger can be assigned to any leds
* fix a lockdep issue in led-trigger common code
* other fix according to review
v1 --> v2:
* remove select operations in Kconfig of every machines
* add back supporting of led in core module of mach-integrator
* solidate name scheme in ledtrig-cpu.c
* add comments of CPU_LED_* cpu led events
* fold patches of RealView and Versatile together
* add machine_is_ check during assabet led driver init
* add some Acked-by in patch logs
* remove code for simpad machine in machine-sa11000, since Jochen Friedrich
introduced gpiolib and gpio-led driver for simpad
* on Assabet and Netwinder machine, LED operations is reversed like:
setting bit means turn off leds
clearing bit means turn on leds
* add a new function to read CM_CTRL register for led driver
* 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
ARM: use new LEDS CPU trigger stub to replace old one
ARM: mach-sa1100: retire custom LED code
ARM: mach-omap1: retire custom LED code
ARM: mach-pnx4008: remove including old leds event API header file
ARM: plat-samsung: remove including old leds event API header file
ARM: mach-pxa: retire custom LED code
char: nwflash: remove old led event code
ARM: mach-footbridge: retire custom LED code
ARM: mach-ebsa110: retire custom LED code
ARM: mach-clps711x: retire custom LED code of P720T machine
ARM: mach-integrator: retire custom LED code
ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions
ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger
ARM: mach-shark: retire custom LED code
ARM: mach-ks8695: remove leds driver, since nobody use it
ARM: mach-realview and mach-versatile: retire custom LED code
ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers
led-triggers: create a trigger for CPU activity
Conflicts:
arch/arm/mach-clps711x/p720t.c
arch/arm/mach-sa1100/leds-cerf.c
arch/arm/mach-sa1100/leds-lart.c
Let's hope this is the last time we pull this and it doesn't cause
more trouble. I have verified that version 10 causes no build
warnings or errors any more, and the patches still look good.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Attempting to consolidate the ARM LED code, this removes the
custom RealView LED trigger code to turn LEDs on and off in
response to CPU activity and replace it with a standard trigger.
(bryan.wu@canonical.com:
It introduces several syscore stubs into this trigger.
It also provides ledtrig_cpu trigger event stub in <linux/leds.h>.
Although it was inspired by ARM work, it can be used in other arch.)
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Tested-by: Jochen Friedrich <jochen@scram.de>
|
|
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: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
Add driver for BlinkM device to drivers/leds/.
Add entry to MAINTAINERS file.
Add documentation in Documentation/leds/.
A BlinkM is a RGB LED controlled through I2C.
This driver implements an interface to the LED framework
and another sysfs group to access the internal options
of the BlinkM.
rev6: Use module_i2c_driver().
rev5: Removed own workqueue in favor of events wq.
rev4: Fixed comments by Bryan Wu.
rev3: Fixed issues found by Jonathan Neuschäfer.
(bryan.wu@canonical.com: remove 2 trailing whitespace)
Signed-off-by: Jan-Simon Möller <jansimon.moeller@gmx.de>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
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
Tested on OMAP4430
(bryan.wu@canonical.com: use module_i2c_driver() rather than
lm3556_init/lm3556_exit for code simplicity; fixed some typo
pointed out by Rob Landley)
Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com>
Reviewed-by: Axel Lin <axel.lin@gmail.com>
Reviewed-by: Kim, Milo <Milo.Kim@ti.com>
Acked-by: Rob Landley <rob@landley.net>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
Add oneshot trigger to blink a led with configurale parameters via
sysfs.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Cc: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
|
|
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: Johan 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: Shuah 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
LED Driver for Dialog Semiconductor DA9052/53 PMICs.
[akpm@linux-foundation.org: make led_reg static]
Signed-off-by: David Dajun Chen <dchen@diasemi.com>
Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Bryan Wu <bryan.wu@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Pull "ARM: board specific updates" from Arnd Bergmann/Olof Johansson:
"These changes are all specific to one board only. We're trying to
keep the number of board files low, but generally board level updates
are ok on platforms that are working on moving towards DT based
probing, which will eventually lead to removing them.
The board-ams-delta.c board file gets a conflict between the removal
of ams_delta_config and the addition of a lot of other data. The
Kconfig file has two changes in the same line, and in exynos, the
power domain cleanup conflicts with the addition of the image sensor
device.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[olof: Amended a fix for a mismerge to board-omap4panda.c]
Signed-off-by: Olof Johansson <olof@lixom.net>"
Fixed up some fairly trivial conflicts manually.
* tag 'boards' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (82 commits)
i.MX35-PDK: Add Camera support
ARM : mx35: 3ds-board: add framebuffer device
pxa/hx4700: Remove pcmcia platform_device structure
ARM: pxa/hx4700: Reduce sleep mode battery discharge by 35%
ARM: pxa/hx4700: Remove unwanted request for GPIO105
ARM: EXYNOS: support Exynos4210-bus Devfreq driver on Nuri board
ARM: EXYNOS: Register JPEG on nuri
ARM: EXYNOS: Register JPEG on universal_c210
ARM: S5PV210: Enable JPEG on SMDKV210
ARM: S5PV210: Add JPEG board definition
ARM: EXYNOS: Enable JPEG on Origen
ARM: EXYNOS: Enable JPEG on SMDKV310
ARM: EXYNOS: Add __init attribute to universal_camera_init()
ARM: EXYNOS: Add __init attribute to nuri_camera_init()
ARM: S5PV210: Enable FIMC on SMDKC110
ARM: S5PV210: Enable FIMC on SMDKV210
ARM: S5PV210: Enable MFC on SMDKC110
ARM: S5PV210: Enable MFC on SMDKV210
ARM: EXYNOS: Enable G2D on SMDKV310
ARM: tegra: update defconfig
...
|
