It can be a problem when a pattern is loaded via the firmware interface.
LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'.
So it should be deleted.
On the other hand, locks are required in store_engine_load()
on updating program memory.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Cc: <stable@vger.kernel.org>
We need to make sure that the error code from devm_of_pwm_get() is the one
the module returns in case of failure.
Restructure the code to make this possible for DT booted case.
With this patch the driver can ask for deferred probing when the board is
booted with DT.
Fixes for example omap4-sdp board's keyboard backlight led.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch moves the handling of the chip's enable pin from the board
code into the driver. It also updates all board-code files using the
driver to incorporate this change.
This is needed for device tree support of the enable pin.
Signed-off-by: Sebastian Reichel <sre@debian.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
now the leds-gpio driver will create every child led node without
checking the status is disabled or not.
for example, if we have a led node like d3, and its status is disabled:
leds {
d3 {
label = "d3";
gpios = <&pioE 24 0>;
status = "disabled";
};
};
we except the d3 should not be created. And the gpios should not be
request as well.
But current driver will create d3 and request its gpio.
This patch fix this by using for_each_available_child_of_node() and
of_get_available_child_count() to enumerate all child nodes. So the
disabled node will be inavailable.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
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>
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
'of_match_ptr' is defined in linux/of.h. Include it explicitly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This enables setting a default trigger on an LP55xx channel,
either from platform data or device tree. This mechanism is
identical to the mechanism for GPIO LEDs and references the
common LEDs device tree bindings.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Milo Kim <milo.kim@ti.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
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
...
Board updates for 3.12. Again, a bit of domain overlap with SoC and DT branches,
but most of this is around legacy code and board support. We've found that
platform maintainers have a hard time separating all of these out and might
move towards fewer branches for next release.
- Removal of a number of Marvell Kirkwood board files, since contents
is now common and mostly configured via DT.
- Device-tree updates for Marvell Dove, including irqchip and clocksource
setup.
- Defconfig updates. Gotta go somewhere. One new one for Renesas Lager.
- New backlight drivers for backlights used on Renesas shmobile platforms.
- Removal of Renesas leds driver.
- Shuffling of some of the new Broadcom platforms to give room for others in
the same mach directory. More in 2.13.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSKhrfAAoJEIwa5zzehBx3OOAQAJCWhoYaHvWmyAf+xCOQNpX2
YgAngENW04VpHFOyn6BtoGv6+5JypdB2TmK3GHHlVJd1Im5mD1wgm8hAfgyV8lQ4
UeJULdA2HZAstKeTirO65BIyUb5QIrWakF24ccfIfg2xeScM8FV0m8cmzeo3fYAf
DmmeoSCmvTdu/cDWBNlsQZ/as8qCQwyF+5kZg+SMl1btA1Publu2I5lDE02TH46d
sc5mN+ihw0JG62EJV7pov6uVyeFLExoTbrNfQZ4rixmKkMDS/jq5ZbBS5c0i8ULF
s1UMSZtYTcUO9rAPv3+MOIc7fq7nKo9lLuwMrA1HHUEDJ2BEi8DIp99F+ZYm/MSL
WpVxYNwOobPcMJBYGR2fy4GgpIyWB285GgrBUxcq7t0Xi4uBbptwjLhDE4d7LREV
8guW251R+OEVPYcwFctsubnox0MViyC3CQ1FaAAdtTjpSKomlhk/yaxaQ9nGrxls
QCZgXHWm4Ir3QYv8XfOn0X9vdP81EnX11SiwtrRSJ71QMs814nB8NdPDqU4VHsw8
exKmqjq/Lt+F9Kpxn/FevNNuYOdefZNQi00yl3ERchdIGdvRwE/0yA0D69mpwIVr
E41UwvH3g43vazCo2PMdWPWuFlpGMR3iZ4pXnDLH/w33ppfJWfokYwKSRQ/mu/MN
LMjkwoZn1X+fZzNSh9/G
=EGua
-----END PGP SIGNATURE-----
Merge tag 'boards-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC board updates from Olof Johansson:
"Board updates for 3.12. Again, a bit of domain overlap with SoC and
DT branches, but most of this is around legacy code and board support.
We've found that platform maintainers have a hard time separating all
of these out and might move towards fewer branches for next release.
- Removal of a number of Marvell Kirkwood board files, since contents
is now common and mostly configured via DT.
- Device-tree updates for Marvell Dove, including irqchip and
clocksource setup.
- Defconfig updates. Gotta go somewhere. One new one for Renesas
Lager.
- New backlight drivers for backlights used on Renesas shmobile
platforms.
- Removal of Renesas leds driver.
- Shuffling of some of the new Broadcom platforms to give room for
others in the same mach directory. More in 3.13"
* tag 'boards-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (67 commits)
mmc: sdhci-bcm-kona: Staticize sdhci_bcm_kona_card_event
mmc: sdhci-bcm-kona: Remove unneeded version.h inclusion
ARM: bcm: Make secure API call optional
ARM: DT: binding fixup to align with vendor-prefixes.txt (drivers)
ARM: mmc: fix NONREMOVABLE test in sdhci-bcm-kona
ARM: bcm: Rename board_bcm
mmc: sdhci-bcm-kona: make linker-section warning go away
ARM: tegra: defconfig updates
ARM: dove: add initial DT file for Globalscale D2Plug
ARM: dove: add GPIO IR receiver node to SolidRun CuBox
ARM: dove: add common pinmux functions to DT
ARM: dove: add cpu device tree node
ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI
arch/arm/mach-kirkwood: Avoid using ARRAY_AND_SIZE(e) as a function argument
ARM: kirkwood: fix DT building and update defconfig
ARM: kirkwood: Remove all remaining trace of DNS-320/325 platform code
ARM: configs: disable DEBUG_LL in bcm_defconfig
ARM: bcm281xx: Board specific reboot code
ARM bcm281xx: Turn on socket & network support.
ARM: bcm281xx: Turn on L2 cache.
...
The wm831x-status driver was not converted to use a REG resource when they
were introduced and the rest of the wm831x drivers converted, causing it
to fail to probe due to requesting the wrong resource type.
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: Bryan Wu <cooloney@gmail.com>
fb_notifier_callback is called on any event fired by
fb_notifier_call_chain. Events may, or may not contain some data
(fb_event.data). In case of FB_EVENT_BLANK fb_event.data contains a
pointer to an integer holdingthe blank state. The Problem is, that in
ledtrig-backlight.c - fb_notifier_callback the pointer to blank state
is dereferenced BEFORE the event-type is checked.
Obviously this leads to problems with other events than FB_EVENT_BLANK,
where fb_event.data is undefined or NULL. It seems, that this problem
existed ever since the driver was added.
Like in drivers/video/backlight/backlight.c line 43 I would suggest to
return immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
A malformed device tree could lead into a segmentation fault if the reg
value of a led is bigger than the number of leds.
A valid device tree could have only information about the last led of the
chip. Fix the device tree parsing to handle those cases.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
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>
To update an LED a register has to be read, updated and writen. If
another LED whas been updated at the same time, this could lead into
wrong updates.
This patch adds a common mutex to all the leds of the same chip to
protect the ledout register.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Add support for PCA9634 chip, which belongs to the same family as the
9633 but with support for 8 outputs instead of 4.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
git commit db6eaf8388
(leds-lp5523: use generic firmware interface) causes an application conflict.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode', 'engineN_load' and
'engineN_leds'. (N = 1, 2 or 3)
A 'selftest' attribute macro is replaced with LP55xx common macro.
Those are accessed when a LED pattern is run by an application.
Use a mutex in lp5523_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5523_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED MUX start and stop address should be updated in the program memory
on LP5523 initialization.
LED pattern doesn't work without additional MUX address configuration.
This handling is done by new function, lp5523_init_program_engine().
Eventually, it's called during device initialization, lp5523_post_init_device().
This is a conflict after git commit 632418bf65
(leds-lp5523: clean up lp5523_configure()).
So it should be fixed.
Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5523_load_engine()
It is called whenever the operation mode is changed to 'load'.
It is used for simple operation mode change.
It will be used when engine mode and LED selection is updated in later patch.
lp5523_load_engine_and_select_page()
Change the operation mode to 'load' and select program page number.
This is used for programming a LED pattern at a time.
So load_engine() is replaced with new API, load_engine_and_select_page()
in lp5523_firmware_loaded().
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch reduces the number of programming commands.
(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32
Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
git commit 9ce7cb170f
may cause an application confict, engineN_mode and engineN_load.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode' and 'engineN_load'.
A 'selftest' attribute macro is replaced with LP55xx common macro.
Use a mutex in lp5521_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5521_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.
'led_pattern' attribute is not included
: engineN_mode and _load were created for custom user-application.
'led_pattern' is an exception. I added this attribute not for custom application
but for simple test. Now it is used only in LP5562 driver, not LP5521.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch provides common macros for LP5521 and LP5523 device attributes and
functions.
(Device attributes)
LP5521: 'mode', 'load' and 'selftest'
LP5523: 'mode', 'load', 'leds' and 'selftest'
(Permissions)
mode: R/W
load: Write-only
leds: R/W
selftest: Read-only
Couple of lines are duplicate, so use these macros for adding device attributes
in LP5521 and LP5523 drivers.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx family devices have internal three program engines which are used for
loading LED patterns. To maintain legacy device attributes, specific data
structure is used, 'mode' and 'led_mux'. The mode is used for showing/storing
current engine mode such like disabled, load and run. Then led_mux is used for
showing/storing current output LED selection.
This is only for LP5523/55231.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Dave Hansen <dave@sr71.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Márton Németh <nm127@freemail.hu>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
With the DT conversion, the board Kconfig symbols MACH_ are going to be
removed. In order to prepare this removal, this patch replaces alls the
machines dependencies for leds-netxbig by ARCH_KIRKWOOD.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
With the DT conversion, the board Kconfig symbols MACH_ are going to be
removed. In order to prepare this removal, this patch replaces alls the
machines dependencies for leds-ns2 by ARCH_KIRKWOOD.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Fix a warning from "sparse":
drivers/leds/leds-lp3944.c:292:23: warning: mixing different enum types
drivers/leds/leds-lp3944.c:292:23: int enum led_brightness versus
drivers/leds/leds-lp3944.c:292:23: int enum lp3944_status
Keeping track of LP3944_LED_STATUS_OFF and LP3944_LED_STATUS_ON only in
lp3944_led_set_brightness() is OK, as the handling of DIM (blinking)
mode[s] is in lp3944_led_set_blink().
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
nasgpio_led_get_attr() is used only in this file.
Fix the following sparse warning:
drivers/leds/leds-ss4200.c:200:5: warning: symbol 'nasgpio_led_get_attr' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Add hardware blinking support to the pca9633 driver.
NOTE: Hardware blinking violates the leds infrastructure
driver interface since the hardware only supports
blinking all LEDs with the same delay_on/delay_off
rates. That is, only the LEDs that are set to blink
will actually blink but all LEDs that are set to blink
will blink in identical fashion. The delay_on/delay_off
values of the last LED that is set to blink will be used
for all of the blinking LEDs. If the hardware doesn't
support the requested blinking pattern, a default of
500ms on and off will be used.
Hardware blinking is disabled by default but can be enabled
by setting the 'blink_type' member in the platform_data
struct to 'PCA9633_HW_BLINK' or by adding the 'nxp,hw-blink'
property to the DTS.
(fengguang.wu@intel.com: Removes unneeded semicolon.)
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.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>
Similar to tca6507, we can just parse the standard LED
properties for pca9633.
Tested on a pca9632, which is compatible with pca9633.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the led class code to use the
correct field.
Acked-by: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
drivers/leds/leds-mc13783.c: In function 'mc13xxx_led_probe':
drivers/leds/leds-mc13783.c:195:2: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Convert drivers/leds/led-class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, led class registers
suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
class->suspend/resume. When __device_suspend() runs call-backs, it will
find class->pm ops for the led class.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch rewrite driver code to be ready to add support for
MC13892 LEDs and probe from devicetree.
(cooloney@gmail.com: fix one coding style issue when apply this patch)
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Static checkers complain that, although this is declared as an
unsigned long, we can only use the lower 32 bits. For anything
higher, we hit bugs widening then bitwise negate or wrapping bugs
doing the left shift.
From looking at the context, this is not a problem because we only
use 16 bits. I've changed some types to make it more clear.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
we can rely on device core for handling pinctrl, so remove
devm_pinctrl_get_select_default() from the driver.
Reported-by: Stephen Warren <warren@wwwdotorg.org>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
