Use the more convenient macro.
Signed-off-by: NZHAO Gang <gamerh2o@gmail.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

This removes a warning on non-DT-enabled platforms:

drivers/leds/leds-pwm.c: In function 'led_pwm_create_of':
drivers/leds/leds-pwm.c:88:22: warning: unused variable 'node'

Really caused by the local variable that is assigned to and then never
used. Just do away with the local var, it's not needed.

Technically this code path can never be entered without DT enabled,
since there's an earlier check about number of children in the calling
function, but the compiler can't see that.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Overflow maybe occurs when calculates the duty time. For instance,
the period time is 990000000ns, and the max_brightness is 127, when
setting the brightness to 12, the duty value will be 25906026ns, but
it should be 93543307ns.
Signed-off-by: NBryan Wu <cooloney@gmail.com>

LED registers are used only in this driver, so no additional
locking is needed. Read-Modify-Write cycle in workqueue is already
protected by regmap.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

LED platform data are overwhelmed by excessive field "max_cur"
which just replicates few bits of "led_control" field.
This patch removes this field and adds a definition for the
current settings in the header.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Need check CONFIG_GPIOLIB whether defined, just like another area has
done within this file. Or can not pass compiling when CONFIG_GPIOLIB
disabled.

The related error (with allmodconfig for metag):

    CC [M]  drivers/leds/leds-tca6507.o
  drivers/leds/leds-tca6507.c: In function 'tca6507_led_dt_init':
  drivers/leds/leds-tca6507.c:731: error: 'struct tca6507_platform_data' has no member named 'gpio_base'
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

There are two ways to run a pattern in LP5523.
One is using legacy sysfs files such as 'enginex_mode','enginex_load' and
'enginex_leds'. ('x' is from 1 to 3).
Among them, 'enginex_leds' are used for selecting specific LED channel MUX.
(MUX means which LEDs are used for running a pattern from LED 1 to 9.)

The other way is using the firmware interface.
In this mode, the default LED MUX strings are used.
In other words, LED MUX is not configurable on the fly.

This patch enables dynamic LED MUX configuration when the firmware is loaded.
By accessing the sysfs file 'enginex_leds', the LED channels can be configured.
To synchronize the operation mode, each engine mode should be set to 'LOAD'.

The documentation is updated as well.

Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Whenever the engine is loaded by the user-application, the operation mode is
reset first. But it has a problem in case of multiple engine used because
previous engine settings are cleared.
The driver should update not whole 8bits but each engine bit by masking.

On the other hands, whole engines should be reset when the driver is unloaded
and on initializing the LP5523 driver.
So, new functions are used for this handling - lp5521/5523_stop_all_engines().

Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

In particular fix the capitalisation of GPIO and LED and
correct TCA6507_MAKE_CPIO, but also rewrite the comment about
platform-data to include reference to devicetree.

Also re-wrap comments to fit 80 columns.
Reported-by: NBryan Wu <cooloney@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

The 7 lines driven by the TCA6507 can either drive LEDs or act as output-only
GPIOs.

To make this distinction in devicetree we use the "compatible" property.

If the device attached to a line is "compatible" with "gpio", we treat it
like a GPIO.  If it is "compatible" with "led" (or if no "compatible" value
is set) we treat it like an LED.

(cooloney@gmail.com: fix typo in the subject)
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

1/ The led_info array must be allocated to allow the full number
  of LEDs even if not all are present.  The array maybe be sparsely
  filled but it is indexed by device address so we must at least
  allocate as many slots as the highest address used.  It is easiest
  just to allocate all 7.

2/ range check the 'reg' value properly.

3/ led.flags must be initialised to zero, else all leds could
   be treated as GPIOs (depending on what happens to be on the stack).
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

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: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NBryan 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: NSebastian Reichel <sre@debian.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBryan 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: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBryan 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: NMaximilian Güntner <maximilian.guentner@gmail.com>
Signed-off-by: NBryan 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: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

'of_match_ptr' is defined in linux/of.h. Include it explicitly.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Cc: Guennadi Liakhovetski <lg@denx.de>
Signed-off-by: NBryan 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: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NMilo Kim <milo.kim@ti.com>
Acked-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

'break' after return is redundant. Remove it.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NJan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

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: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: NBryan 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: NManfred Schlaegl <manfred.schlaegl@gmx.at>
Signed-off-by: NBryan 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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBryan 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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBryan 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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

If there is more than one pca963x chips on the system and there are
some LEDs without platform_data names, the driver wont be able to
provide unique naming to them.

This will cause led_class_dev_register to fail, unregistering all the
LEDs of the chip.

This patch adds the i2c address to the name of the unnamed LEDs, making
them unique.

[  555.346827] ------------[ cut here ]------------
[  555.346844] WARNING: at /build/linux-voe0Su/linux-3.9.8/fs/sysfs/dir.c:536 sysfs_add_one+0x8b/0x9d()
[  555.346847] Hardware name: QT5022
[  555.346850] sysfs: cannot create duplicate filename '/class/leds/pca9633:6'
[  555.346853] Modules linked in: qt5038_platform(O+) leds_pca9633(O) hid_generic ledtrig_default_on rfcomm bnep bluetooth binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd dns_resolver fscache sunrpc nls_utf8 nls_cp437 vfat fat loop fuse joydev hid_multitouch usbhid hid acpi_cpufreq mperf kvm_amd kvm evdev pn533 nfc arc4 microcode pcspkr efivars k10temp ath9k ath9k_common ath9k_hw ath fglrx(PO) mac80211 cfg80211 video rfkill processor thermal_sys sp5100_tco button i2c_piix4 ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci libahci igb i2c_algo_bit i2c_core dca ptp pps_core ehci_pci ohci_hcd ehci_hcd libata usbcore usb_common scsi_mod [last unloaded: leds_pca963x]
[  555.346940] Pid: 4766, comm: insmod Tainted: P        W  O 3.9-1-amd64 #1 Debian 3.9.8-1
[  555.346943] Call Trace:
[  555.346956]  [<ffffffff8103d153>] ? warn_slowpath_common+0x76/0x8c
[  555.346962]  [<ffffffff8103d202>] ? warn_slowpath_fmt+0x47/0x49
[  555.346968]  [<ffffffff8116005d>] ? sysfs_pathname+0x3b/0x41
[  555.346973]  [<ffffffff81160767>] ? sysfs_add_one+0x8b/0x9d
[  555.346978]  [<ffffffff811610a4>] ? sysfs_do_create_link_sd+0xe8/0x174
[  555.346985]  [<ffffffff81279250>] ? device_add+0x243/0x5ab
[  555.346991]  [<ffffffff81060a16>] ? complete_all+0x31/0x40
[  555.346998]  [<ffffffff8104991a>] ? init_timer_key+0xc/0x56
[  555.347004]  [<ffffffff8127964c>] ? device_create_vargs+0x82/0xb6
[  555.347009]  [<ffffffff812796af>] ? device_create+0x2f/0x31
[  555.347014]  [<ffffffff81060add>] ? should_resched+0x5/0x23
[  555.347021]  [<ffffffff812a3a92>] ? led_classdev_register+0x24/0x103
[  555.347028]  [<ffffffffa09d01c0>] ? pca9633_probe+0x173/0x239 [leds_pca9633]
[  555.347035]  [<ffffffff8127b504>] ? __driver_attach+0x73/0x73
[  555.347049]  [<ffffffffa009dfc9>] ? i2c_device_probe+0x63/0x88 [i2c_core]
[  555.347057]  [<ffffffff8127b373>] ? driver_probe_device+0x92/0x1b0
[  555.347064]  [<ffffffff81279c5c>] ? bus_for_each_drv+0x43/0x7d
[  555.347070]  [<ffffffff8127b2af>] ? device_attach+0x68/0x83
[  555.347078]  [<ffffffff8127a990>] ? bus_probe_device+0x25/0x8d
[  555.347083]  [<ffffffff812793f7>] ? device_add+0x3ea/0x5ab
[  555.347088]  [<ffffffff81060a16>] ? complete_all+0x31/0x40
[  555.347094]  [<ffffffff8104991a>] ? init_timer_key+0xc/0x56
[  555.347104]  [<ffffffffa009d3a1>] ? i2c_new_device+0x10d/0x179 [i2c_core]
[  555.347112]  [<ffffffffa008f036>] ? qt5038_init+0x36/0x1000 [qt5038_platform]
[  555.347119]  [<ffffffffa008f000>] ? 0xffffffffa008efff
[  555.347125]  [<ffffffff8100209e>] ? do_one_initcall+0x74/0x128
[  555.347131]  [<ffffffffa008f000>] ? 0xffffffffa008efff
[  555.347137]  [<ffffffff810836f5>] ? load_module+0x1af7/0x1dfc
[  555.347144]  [<ffffffff810801c5>] ? free_notes_attrs+0x3c/0x3c
[  555.347150]  [<ffffffff81083a98>] ? sys_init_module+0x9e/0xab
[  555.347157]  [<ffffffff8138be29>] ? system_call_fastpath+0x16/0x1b
[  555.347161] ---[ end trace ad00b85794e0de4d ]---
[  555.347448] leds-pca9633: probe of 0-006b failed with error -17
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBryan 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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

git commit db6eaf83
(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: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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 632418bf
(leds-lp5523: clean up lp5523_configure()).
So it should be fixed.

Cc: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

git commit 9ce7cb17
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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NBryan 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: NSachin Kamat <sachin.kamat@linaro.org>
Cc: Dave Hansen <dave@sr71.net>
Signed-off-by: NBryan 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: NSachin Kamat <sachin.kamat@linaro.org>
Cc: Márton Németh <nm127@freemail.hu>
Signed-off-by: NBryan 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: NSimon Guinot <simon.guinot@sequanux.org>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NBryan 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: NSimon Guinot <simon.guinot@sequanux.org>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NBryan Wu <cooloney@gmail.com>