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>
The LP55xx DT structure is applicable to the LP5562 device.
The driver and documentation are updated.
Compatible property of the DT
: LP5521 and LP5223 were manufactured by National Semiconductor.
LP5562 is a new device from Texas Instruments.
Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Currently, the LP55xx DT structure supports max 3 channels.
However, LP5523 has max 9 channels and LP5562 has 4 channels.
To enhance this constraint, the DT structure has been changed.
(a) Use the child node for various channel settings instead of fixed array
(b) Remove 'num_channel' property.
This value can be retrieved by counting the children node.
(c) 'chan-name' property supported
(d) Documentation updates for LP5521 and LP5523
(cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt)
Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d06310
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d06310
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d06310
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d06310
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch allows the lp5521 driver to be successfully probed and
initialised when Device Tree support is enabled.
Based on a patch by Gabriel Fernandez, rewritten in accordance
with review feedback.
Cc: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
During the development of this driver an in-house register documentation
was used. The last week some integration tests were done and this
problem was found. It turned out that the released register
documentation is wrong.
The fix is very simple: shift all masks by one.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid
cases for enableing GENERIC_GPIO without GPIOLIB, even though it is
possible to do so which has been causing confusion and breakage. This
branch does the work to completely eliminate GENERIC_GPIO.
However, it is not trivial to just create a branch to remove it. Over
the course of the v3.9 cycle more code referencing GENERIC_GPIO has been
added to linux-next that conflicts with this branch. The following must
be done to resolve the conflicts when merging this branch into mainline:
* "git grep CONFIG_GENERIC_GPIO" should return 0 hits. Matches should be
replaced with CONFIG_GPIOLIB
* "git grep '\bGENERIC_GPIO\b'" should return 1 hit in the Chinese
documentation.
* Selectors of GENERIC_GPIO should be turned into selectors of GPIOLIB
* definitions of the option in architecture Kconfig code should be deleted.
Stephen has 3 merge fixup patches[1] that do the above. They are currently
applicable on mainline as of May 2nd.
[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg428056.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRifUnAAoJEEFnBt12D9kBs2YP/0U6+ia+xYvkVaJc28PDVIzn
OReZNcJOYU8D5voxz0voaRD0EdcPwjbMu9Kp9aXMHlk4VxevF+8jCc/us0bIjtO1
VcB5VmSCIhMhxdnBlum11Mk7Vr5MCweyl9NBsypnPt8cl4obMBZHf2yzoodFktNb
wtyYlOb6FALtc6iDbOO6dG3w9F7FAOLvskUFzdv89m8mupTsBu9jw9NqFDbJHOex
rxq0Sdd+kWF/nkJVcV5Y6jIdletRlhpipefMJ9diexreHvwqh+c4kJEYZaXgB5+m
ha95cPbReK1d+RqzM3A8d4irzSVSmq4k7ijI6QkFOr48+AH7XsgKv5so885LKzMN
IIXg2Phm9i0H8+ecEvhcc4oIYBHJiEKK54Y0qUD9dqbFoDGPTCSqMHdSSMbpAY+J
bIIXlVzj1En3PPNUJLPt8q8Qz6WxCT9mDST3QSGYnD4o90HT+1R9j92RxGL6McOq
rUOyJDwmzFvpBvKK4raGdOU435M+ps2NPKKNIRaIGQPPY9rM1kN4YqvhXukEsC9L
3a3+3cQLh7iKxBHncxeQsJfethP1CPkJnzvF9r+ZZLf2rcPH4pbQIE2uO0XnX/nd
5/DKi0nGgAJ//GMMzdo3RiOA5zGFjIZ/KMvfhQldpP6qFJRhqdGi6FPlAcwr1z1n
YnCByPwwlvfC4LTXFOGL
=xodc
-----END PGP SIGNATURE-----
Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux
Pull removal of GENERIC_GPIO from Grant Likely:
"GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any
valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it
is possible to do so which has been causing confusion and breakage.
This branch does the work to completely eliminate GENERIC_GPIO."
* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux:
gpio: update gpio Chinese documentation
Remove GENERIC_GPIO config option
Convert selectors of GENERIC_GPIO to GPIOLIB
blackfin: force use of gpiolib
m68k: coldfire: use gpiolib
mips: pnx833x: remove requirement for GENERIC_GPIO
openrisc: default GENERIC_GPIO to false
avr32: default GENERIC_GPIO to false
xtensa: remove explicit selection of GENERIC_GPIO
sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
powerpc: remove redundant GENERIC_GPIO selection
unicore32: default GENERIC_GPIO to false
unicore32: remove unneeded select GENERIC_GPIO
arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB
arm: remove redundant GENERIC_GPIO selection
mips: alchemy: require gpiolib
mips: txx9: change GENERIC_GPIO to GPIOLIB
mips: loongson: use GPIO driver on CONFIG_GPIOLIB
mips: remove redundant GENERIC_GPIO select
GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on
GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Switch to using SIMPLE_DEV_PM_OPS macro to declare the driver's
pm_ops. It reduces code size. Also, CONFIG_PM_SLEEP is added to
suspend/ resume functions to prevent build warnings when
CONFIG_PM_SLEEP is not selected.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.
drivers/leds/leds-bd2802.c:766:12: warning: 'bd2802_suspend' defined but not used [-Wunused-function]
drivers/leds/leds-bd2802.c:776:12: warning: 'bd2802_resume' defined but not used [-Wunused-function]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
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: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Program execution is timed with 32768Hz clock in the LP55xx family devices.
To run LED functionalities, LP55xx devices provide two options.
One is using internal clock. The other is using external clock.
This patch enables external clock detection automatically.
If external clock is not detected, then the internal clock will be used in the
LP55xx driver.
Valid clock rate is 32768Hz in LP55xx devices.
This new API is used in each LP55xx driver like LP5521 and LP5562.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch fixes a regression introduced by commit 72052fcc10
("leds: leds-ns2: add device tree binding").
When the driver is initialized with device tree data, platform_data
pointer is NULL. This causes a kernel oops at removal.
To fix this bug, num_leds is moved into driver_data and platform_data
is not longer used from ns2_led_remove().
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Call to led_pwm_set() can happen inside atomic context, like triggers.
If the PWM call can sleep, defer using a worker.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
According to a sysfs documentation(Documentation/filesystem/sysfs.txt),
scnprintf() should be used in a read operation method.
It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LM355x and LM3642 support flash and torch functionality.
(Camera driver) (LED trigger for camera) (LED driver)
Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642
brightness ctrl
<actual driving here>
Flash/torch LEDs are controlled by other driver using LED camera trigger
APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl().
Then, actual device control is activated by each LED driver such like
LM355x or LM3642.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This eliminates having an #ifdef returning NULL for the case
when OF is disabled.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Provide some trace, though the hardware is most likely non-functional if
this happens.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | !!brightness
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)
So, when '!!brightness' is 1, the gpio pin can be set as input,
instead of output.
To prevent this problem, GPIOF_OUT_INIT flags should be used when
using gpio_request_one().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The devm_gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | gpio_get_value(template->cmd)
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)
So, when 'gpio_get_value(template->cmd)' is 1, the gpio pin can
be set as input, instead of output.
To prevent this problem, GPIOF_OUT_INIT flags should be used when
using devm_gpio_request_one().
Same goes for 'gpio_get_value(template->slow)' case.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The devm_gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | state
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)
So, when 'state' is 1, the gpio pin can be set as input, instead
of output.
To prevent this problem, GPIOF_OUT_INIT flags should be used when
using devm_gpio_request_one().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
CONFIG_HOTPLUG was removed, so __devexit or __exit of remove()
should not be used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
CONFIG_HOTPLUG was removed, so __devexit or __exit of remove()
should not be used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
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>
Pull LED subsystem update from Bryan Wu.
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (61 commits)
leds: leds-sunfire: use dev_err()/pr_err() instead of printk()
leds: 88pm860x: Add missing of_node_put()
leds: tca6507: Use of_get_child_count()
leds: leds-pwm: make it depend on PWM and not HAVE_PWM
Documentation: leds: update LP55xx family devices
leds-lp55xx: fix problem on removing LED attributes
leds-lp5521/5523: add author and copyright description
leds-lp5521/5523: use new lp55xx common header
leds-lp55xx: clean up headers
leds-lp55xx: clean up definitions
leds-lp55xx: clean up unused data and functions
leds-lp55xx: clean up _remove()
leds-lp55xx: add new function for removing device attribtues
leds-lp55xx: code refactoring on selftest function
leds-lp55xx: use common device attribute driver function
leds-lp55xx: support device specific attributes
leds-lp5523: use generic firmware interface
leds-lp5521: use generic firmware interface
leds-lp55xx: support firmware interface
leds-lp55xx: add new lp55xx_register_sysfs() for the firmware interface
...
Fixed the checkpatch errors and warnings as below:
ERROR: spaces required around that '=' (ctx:VxW)
WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
of_find_node_by_name() returns a node pointer with refcount incremented, use
of_node_put() on it when done.
of_find_node_by_name() will call of_node_put() against from parameter,
thus we also need to call of_node_get(from) before calling
of_find_node_by_name().
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
The correct dependency for the leds-pwm is PWM and not HAVE_PWM
since PWM drivers now have their own subsystem.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55XX common device attributes, 'led_current' and 'max_current' are created
while loading the driver.
Those are LED device attributes which are removed automatically on releasing
led class devices - led_classdev_unregister().
Therefore, this duplicate code should be removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Now LP5521 and LP5523 drivers are based on new lp55xx structure.
So the author and copyrights are updated.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Remove unused definitions and change hex values to capital letters
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Old data structures and I2C function are not used any more.
Each driver uses the lp55xx common data and functions.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Replace lp5521/5523_unregister_sysfs() with lp55xx_unregister_sysfs().
On unloading the driver, running engines should be stopped.
Use explicit driver function, lp5521/5523_stop_engine().
Unused functions are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp55xx_unregister_sysfs() is used for removing lp55xx device attributes.
Chip specific and engine attributes are removed on unloading the driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521 and LP5523 have a selftest function which is run via the sysfs.
Use lp55xx driver data and R/W functions rather than lp5521/5523 private data
and functions.
Additionally, if-statements are changed for code simplicity.
Unused functions, lp5521/5523_read() are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_register_sysfs() are replaced with lp55xx common driver function,
lp55xx_register_sysfs().
Chip specific device attributes are configurable using 'dev_attr_group'.
Error condition name is changed:
use specific error condition, 'err_register_sysfs' rather than unclear name,
'fail2'.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To support device specific attributes, new common driver function is added.
Eventually those are created on registering the sysfs with common dev attrs.
Furthermore, this patch makes adding device attributes simple in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
engine1_leds
engine2_leds
engine3_leds
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5523_load/stop/run_engine(), lp5523_update_program_memory() and
lp5523_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx common driver provides generic firmware interface
for running a LED pattern.
LP5521 and LP5523 have many device attributes for running patterns.
This patch cleans up those complex code.
Removed device attributes:
engine1_mode
engine2_mode
engine3_mode
engine1_load
engine2_load
engine3_load
led_pattern
All device attributes and functions are replaced with two callback functions,
'firmware_cb' and 'run_engine'.
New engine functions:
lp5521_load/stop/run_engine(), lp5521_update_program_memory() and
lp5521_wait_opmode_done()
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch provides additional device attributes which enable
loading the firmware. ('select_engine' and 'run_engine')
To run a LED pattern, two parts of driver should be enabled.
Common features : lp55xx-common
===============================
Firmware interface for loading LED patterns
Chip specific features : leds-lp5521, leds-lp5523
=================================================
Register addresses for loading firmware data
Register addresses for running selected engine
Pattern programming sequence
============================
LP55xx chips have three program engines.
To load and run a LED pattern, the programming sequence is as follows.
(1) Select an engine number (1/2/3)
(2) Set engine mode to load
(3) Write pattern data into selected area
(4) Set engine mode to run
This sequence is almost same as the firmware interface.
(1) Select an engine number : 'select_engine' dev attribute
(2) Mode change to load : 'loading' of firmware class
(3) Write pattern data into selected area : 'data' of firmware class
(4) Mode change to run : 'run_engine' dev attribute
(1) and (4) are device specific features which provide callback functions
(2) and (3) are common features.
For example,
echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo 1 > /sys/class/firmware/lp5521/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
echo 0 > /sys/class/firmware/lp5521/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
As soon as 'loading' is set to 0, registered callback is called.
Inside the callback, the selected engine is loaded and memory is updated.
To run programmed pattern, 'run_engine' attribute should be enabled.
Device specific data structure
==============================
o Firmware callback
load selected engine and update program memory
o Run engine
change the engine mode
o 'engine_idx' and firmware data, 'fw'
Those are used in the driver internally with callback functions
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP55xx family chips have internal program memory which run various patterns.
Using this memory, LEDs continue on blinking/dimming without continuous I2C
commands. That means the I2C HOST can be entered into sleep once the memory
is updated.
An application can get hex data from a file and write them into
the program memory through the I2C. This is general firwmare interface.
This patch is the initial step for adding the firmware interface.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Use lp55xx_unregister_leds() rather than duplicate code.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
To unregister led class devices and sysfs attributes,
LP5521 and LP5523 have each driver function.
This patch makes both drivers simple using common driver function,
lp55xx_unregister_leds().
And some unused variables are removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED current is configurable via the sysfs.
Max current is a read-only attribute.
These attributes code can be shared in lp55xx common driver.
Device attributes: 'led_current' and 'max_current'
move to lp55xx common driver
Replaced functions:
show_max_current() => lp55xx_show_max_current()
show_current() => lp55xx_show_current()
store_current() => lp55xx_store_current()
LED setting function: set_led_current()
Current registers are device specific, so configurable function is added
in each driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_set_brightness() and lp5523_set_brightness() are replaced with
common function, lp55xx_set_brightness().
This function is invoked when the brightness of each LED channel is updated.
LP5521 and LP5523 have different register address for the brightness control,
so this work is done by chip specific brightness_work_fn().
lp5521/5523_led_brightness_work():
use lp55xx_led and lp55xx_chip data structure.
use lp55xx write function.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521_init_led() and lp5523_init_led() are replaced with one common function,
lp55xx_init_led().
Max channels is configurable, so it's used in lp55xx_init_led().
'LP5523_LEDS' are changed to 'LP5523_MAX_LEDS'.
lp55xx_set_brightness, lp55xx_led_attributes: skeleton
Will be filled in next patches.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED class devices are registered in lp5521_register_leds() and
lp5523_register_leds().
Two separate functions are merged into consolidated lp55xx function,
lp55xx_register_leds().
Error handling fix:
Unregistering LEDS are handled in lp55xx_register_leds() when LED registration
failure occurs. So each driver error handler is changed to 'err_register_leds'
Chip dependency: 'brightness_work_fn' and 'set_led_current'
To make the structure abstract, both functions are configured in each driver.
Those functions should be done by each driver because register control is
chip-dependant work.
lp55xx_init_led: skeleton
Will be filled in next patch
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Two separate de-init functions are merged into one common function.
And it is used in err_post_init of lp55xx_init_device().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
lp5521/5523_init_device() are replaced with lp55xx common function,
lp55xx_init_device().
Error handler in init_device:
deinit function are matched with 'err_post_init' section in
lp55xx_init_device().
Remove LP5523 engine intialization code:
Engine functionality is not mandatory but optional.
Moreover engine initialization is done internally with device reset command.
Therefore, this code is unnecessary.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 chip configuration is replaced with lp55xx common function,
lp55xx_post_init_device().
Name change:
lp5521/5523_configure() to lp5521/5523_post_init_device()
These are called in init function.
Register access function
Argument type is changed from 'i2c_client' to 'lp55xx_chip'.
Use exported R/W functions of lp55xx common driver.
Temporary variables in lp5521/5523_init_device()
These functions will be removed but temporary variables are needed for
blocking build warnings - incompatible pointer.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 chip detection functions are replaced with lp55xx common function,
lp55xx_detect_device().
Chip dependent address and values are configurable in each driver.
In init function, chip detection is executed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 reset device functions are moved to lp55xx common driver.
Value of register address and value are chip dependent.
Those are configured in each driver.
In init function, reset command is executed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LP5521/5523 platform data functions are moved to lp55xx common driver.
New init function, lp55xx_init_device() is created.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch is a preceding step for making common lp55xx init function.
Return code:
Do not use 'OR' arithmetic for the result.
If some error occurs, just return it.
Remove engine verification code:
To check whether internal engine works or not, many lines of code are executed.
However, this job is unnecessary during the chip initialization because
the engine usage is not mandatory but optional function.
LED engines are enabled when specific LED pattern is loaded.
Therefore, this verification code is removed.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch is a preceding step for making common lp55xx init function.
LP5521_REG_R_CURRENT register code moved:
Chip specific code moved from lp5521_init_device() to lp5521_configure().
Remove engine init function:
LP5521 has internal program engines which are used for running LED patterns.
(blinking, ramp up/down and other emotional visual effects)
Engine initialization is done by reset command in lp5521_init_device().
Remove this duplicate code.
Return code:
Do not use 'OR' arithmetic for the result.
If some error occus, just return it.
Enable latency:
Use explicit named function, lp5521_wait_enable_done().
According to the datasheet, 500us is guaranteed time.
Thus wait time is changed from 1000us to 500us.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Mark Brown