On Tue, Jan 7, 2014 at 12:42 PM, Pavel Machek wrote:
> Hi!
>
> There's some locking weirdness, and few missing comments in lp5523
> driver.
>
> Now, this is untested patch from my reverse-engineering. I hope I
> understood things right...
>
> In particular, there's unbalanced unlock in
>
On Tue, Jan 7, 2014 at 12:42 PM, Pavel Machek wrote:
> Hi!
>
> There's some locking weirdness, and few missing comments in lp5523
> driver.
>
> Now, this is untested patch from my reverse-engineering. I hope I
> understood things right...
>
> In particular, there's unbalanced unlock in
>
On Tue, Jan 7, 2014 at 9:41 AM, Linus Walleij wrote:
> On Fri, Jan 3, 2014 at 7:19 AM, Bryan Wu wrote:
>> On Thu, Jan 2, 2014 at 9:25 PM, Tushar Behera
>> wrote:
>>> Commit c67d0f29262b ("ARM: s3c24xx: get rid of custom ")
>>> removed the usage
On Tue, Jan 7, 2014 at 9:41 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Fri, Jan 3, 2014 at 7:19 AM, Bryan Wu coolo...@gmail.com wrote:
On Thu, Jan 2, 2014 at 9:25 PM, Tushar Behera tushar.beh...@linaro.org
wrote:
Commit c67d0f29262b (ARM: s3c24xx: get rid of custom mach/gpio.h
On Tue, Jan 7, 2014 at 12:42 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
There's some locking weirdness, and few missing comments in lp5523
driver.
Now, this is untested patch from my reverse-engineering. I hope I
understood things right...
In particular, there's unbalanced unlock in
On Tue, Jan 7, 2014 at 12:42 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
There's some locking weirdness, and few missing comments in lp5523
driver.
Now, this is untested patch from my reverse-engineering. I hope I
understood things right...
In particular, there's unbalanced unlock in
On Thu, Jan 2, 2014 at 9:25 PM, Tushar Behera wrote:
> Commit c67d0f29262b ("ARM: s3c24xx: get rid of custom ")
> removed the usage of mach/gpio.h file, but we need to include
> plat/gpio-cfg.h to avoid following build error.
>
> Fixes following build error.
> drivers/leds/leds-s3c24xx.c: In
On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek wrote:
> Hi!
>
>> > Idea would be "sequence of brigtnesses" (one file) and "delay between
>> > changes" (second file).
>>
>> Ick.
>>
>> > Reason to do it in kernel is that some machines actually have
>> > "coprocessor" on i2c that can do it while main
On Wed, Jan 1, 2014 at 3:51 PM, David Lang wrote:
> On Wed, 1 Jan 2014, One Thousand Gnomes wrote:
>
>>> whatever mechanism is created for toggling LEDs should be able to toggle
>>> arbitrary GPIO pins, and there is a problem with the speed of the
>>> standard
>>> access mechanisms in /sysfs. see
On Mon, Dec 30, 2013 at 1:09 AM, Tushar Behera wrote:
> Fixes following build error.
> drivers/leds/leds-s3c24xx.c: In function ‘s3c24xx_led_probe’:
> drivers/leds/leds-s3c24xx.c:100:2: error: implicit declaration of
> function ‘s3c_gpio_setpull’ [-Werror=implicit-function-declaration]
>
I don't
On Mon, Dec 30, 2013 at 1:09 AM, Tushar Behera tushar.beh...@linaro.org wrote:
Fixes following build error.
drivers/leds/leds-s3c24xx.c: In function ‘s3c24xx_led_probe’:
drivers/leds/leds-s3c24xx.c:100:2: error: implicit declaration of
function ‘s3c_gpio_setpull’
On Wed, Jan 1, 2014 at 3:51 PM, David Lang da...@lang.hm wrote:
On Wed, 1 Jan 2014, One Thousand Gnomes wrote:
whatever mechanism is created for toggling LEDs should be able to toggle
arbitrary GPIO pins, and there is a problem with the speed of the
standard
access mechanisms in /sysfs. see
On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek pa...@ucw.cz wrote:
Hi!
Idea would be sequence of brigtnesses (one file) and delay between
changes (second file).
Ick.
Reason to do it in kernel is that some machines actually have
coprocessor on i2c that can do it while main CPU is
On Thu, Jan 2, 2014 at 9:25 PM, Tushar Behera tushar.beh...@linaro.org wrote:
Commit c67d0f29262b (ARM: s3c24xx: get rid of custom mach/gpio.h)
removed the usage of mach/gpio.h file, but we need to include
plat/gpio-cfg.h to avoid following build error.
Fixes following build error.
On Wed, Dec 11, 2013 at 4:11 PM, Olof Johansson wrote:
> 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
On Wed, Dec 11, 2013 at 4:11 PM, Olof Johansson o...@lixom.net wrote:
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
On Wed, Dec 11, 2013 at 1:19 AM, Xiubo Li wrote:
> Overflow maybe occurs when calculates the duty time. For instance,
> the period time is 99000ns, and the max_brightness is 127, when
> setting the brightness to 12, the duty value will be 25906026ns, but
> it should be 93543307ns.
This looks
On Wed, Dec 11, 2013 at 1:19 AM, Xiubo Li li.xi...@freescale.com wrote:
Overflow maybe occurs when calculates the duty time. For instance,
the period time is 99000ns, and the max_brightness is 127, when
setting the brightness to 12, the duty value will be 25906026ns, but
it should be
Hi Linus,
Please consider the following bug fix since commit
dc1ccc48159d63eca5089e507c82c7d22ef60839:
Linux 3.13-rc2 (2013-11-29 12:57:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git
leds-fixes-for-3.13
for you to
On Thu, Nov 28, 2013 at 1:06 AM, Peter Ujfalusi wrote:
> 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
On Wed, Nov 20, 2013 at 10:14 PM, Milo Kim wrote:
> 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.
>
On Wed, Nov 20, 2013 at 10:14 PM, Milo Kim wrote:
> 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.
>
Looks like lp5521_update_program_memory() will be called
On Wed, Nov 20, 2013 at 10:13 PM, Milo Kim wrote:
> 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
On Wed, Nov 20, 2013 at 10:13 PM, Milo Kim milo@ti.com wrote:
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
On Wed, Nov 20, 2013 at 10:14 PM, Milo Kim milo@ti.com wrote:
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.
Looks like lp5521_update_program_memory() will
On Wed, Nov 20, 2013 at 10:14 PM, Milo Kim milo@ti.com wrote:
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
On Thu, Nov 28, 2013 at 1:06 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
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
Hi Linus,
Please consider the following bug fix since commit
dc1ccc48159d63eca5089e507c82c7d22ef60839:
Linux 3.13-rc2 (2013-11-29 12:57:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git
leds-fixes-for-3.13
for you to
e it
into my tree and for stable tree.
Thanks,
-Bryan
> But new interface via request_firmware still not working.
> Directory /sys/class/firmware/lp5523/data not exists.
>
> I think that there can be race condition with udev which is
> responsible for firmware loading... Anyway main proble
problem solved,
old interface is working again and old applications too.
On Tuesday 19 November 2013 02:13:49 Bryan Wu wrote:
Pali,
Could you please test Milo's patch?
Thanks,
-Bryan
On Thu, Nov 7, 2013 at 9:15 PM, Milo Kim milo@ti.com wrote:
Hi Pali,
Sorry for the late reply
On Thu, Nov 7, 2013 at 7:24 PM, Joe Perches wrote:
> On Fri, 2013-11-08 at 14:20 +1100, NeilBrown wrote:
>> 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.
>
> trivia:
>
://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next
for you to fetch changes up to 30dae2f98612d7c8cd855861b9de205ebd9ef4fa:
leds: lp55xx: handle enable pin in driver (2013-10-25 10:13:25 -0700)
Bryan Wu (1
://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next
for you to fetch changes up to 30dae2f98612d7c8cd855861b9de205ebd9ef4fa:
leds: lp55xx: handle enable pin in driver (2013-10-25 10:13:25 -0700)
Bryan Wu (1
On Thu, Nov 7, 2013 at 7:24 PM, Joe Perches j...@perches.com wrote:
On Fri, 2013-11-08 at 14:20 +1100, NeilBrown wrote:
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.
On Thu, Nov 7, 2013 at 3:39 PM, Bryan Wu wrote:
> On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown wrote:
>>
>
> [PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
>
> I think it should be tca6507, right? Typo?
>
I fixed this typo and queue up this
On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown wrote:
>
[PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
I think it should be tca6507, right? Typo?
For other parts of this patch, I'm OK for them.
And just a quick scan of the leds-tca6507, I found bunch of typos in
the
On Thu, Oct 31, 2013 at 7:33 PM, NeilBrown wrote:
>
>
> 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
On Thu, Oct 31, 2013 at 7:33 PM, NeilBrown ne...@suse.de wrote:
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
On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown ne...@suse.de wrote:
[PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
I think it should be tca6507, right? Typo?
For other parts of this patch, I'm OK for them.
And just a quick scan of the leds-tca6507, I found bunch of
On Thu, Nov 7, 2013 at 3:39 PM, Bryan Wu coolo...@gmail.com wrote:
On Thu, Oct 31, 2013 at 7:41 PM, NeilBrown ne...@suse.de wrote:
[PATCH 2/2] LEDS: tca6502: add device-tree support for GPIO configuration.
I think it should be tca6507, right? Typo?
I fixed this typo and queue up this patch
On Fri, Oct 25, 2013 at 11:21 AM, Pali Rohár wrote:
> On Friday 25 October 2013 19:10:07 Bryan Wu wrote:
>> On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár
> wrote:
>> > On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote:
>> >> On Thu, Aug 8, 2013 at 12:59 AM, Milo
On Fri, Oct 25, 2013 at 11:21 AM, Pali Rohár pali.ro...@gmail.com wrote:
On Friday 25 October 2013 19:10:07 Bryan Wu wrote:
On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár
pali.ro...@gmail.com wrote:
On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote:
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim
On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár wrote:
> On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote:
>> On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
>> > This patch-set resolves the application conflict by
>> > restoring sysfs files.
>> >
>>
On Fri, Oct 25, 2013 at 9:38 AM, Pali Rohár pali.ro...@gmail.com wrote:
On Tuesday 13 August 2013 23:04:14 Bryan Wu wrote:
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
This patch-set resolves the application conflict by
restoring sysfs files.
For LP5521
On Tue, Oct 22, 2013 at 10:38 AM, Tony Lindgren wrote:
> * Sebastian Reichel [131022 06:02]:
>> Add support for LP5523 device.
>
> This patch should be queued separately by Benoit.
>
OK, got it. I will merge Patch 1.
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren wrote:
> * Bryan Wu [131022 10:23]:
>> On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren wrote:
>> > * Sebastian Reichel [131022 06:02]:
>> >> This patch moves the handling of the chip's enable pin from the board
>&
ny Lindgren
I'm OK for LED parts, will this patch go through omap tree? If so,
please add my ack.
Acked-by: Bryan Wu
Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
parts, will this patch go through omap tree? If so,
please add my ack.
Acked-by: Bryan Wu coolo...@gmail.com
Thanks,
-Bryan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren t...@atomide.com wrote:
* Bryan Wu coolo...@gmail.com [131022 10:23]:
On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote:
* Sebastian Reichel s...@debian.org [131022 06:02]:
This patch moves the handling of the chip's enable
On Tue, Oct 22, 2013 at 10:38 AM, Tony Lindgren t...@atomide.com wrote:
* Sebastian Reichel s...@debian.org [131022 06:02]:
Add support for LP5523 device.
This patch should be queued separately by Benoit.
OK, got it. I will merge Patch 1.
-Bryan
--
To unsubscribe from this list: send the
On Wed, Oct 16, 2013 at 6:09 PM, Maximilian Güntner
wrote:
> 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
> ---
> v3:
>fixed warnings when running
On Wed, Oct 16, 2013 at 6:09 PM, Maximilian Güntner
maximilian.guent...@gmail.com wrote:
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
On Mon, Oct 14, 2013 at 6:19 PM, Maximilian Güntner
wrote:
> 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
> ---
>
> v2:
>addresses Bryan Wu's
On Mon, Oct 14, 2013 at 6:19 PM, Maximilian Güntner
maximilian.guent...@gmail.com wrote:
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
On Mon, Oct 14, 2013 at 10:31 AM, Maximilian Güntner
wrote:
> The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
> levels of brightness)
> This driver supports configuration using platform_data.
>
I'm OK for this patch basically, just a little picky coding style
issue as below.
On Mon, Oct 14, 2013 at 10:31 AM, Maximilian Güntner
maximilian.guent...@gmail.com wrote:
The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
levels of brightness)
This driver supports configuration using platform_data.
I'm OK for this patch basically, just a little picky
On Thu, Sep 26, 2013 at 4:27 AM, Josh Wu wrote:
> 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 {
>
On Thu, Sep 26, 2013 at 4:27 AM, Josh Wu josh...@atmel.com wrote:
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 {
On Tue, Sep 24, 2013 at 1:04 AM, Josh Wu wrote:
> 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 {
>
On Tue, Sep 24, 2013 at 1:04 AM, Josh Wu josh...@atmel.com wrote:
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 {
linux/drivers/leds/trigger/ledtrig-cpu.c
> ===
> --- linux.orig/drivers/leds/trigger/ledtrig-cpu.c 2013-08-27
> 14:46:42.043176071 -0500
> +++ linux/drivers/leds/trigger/ledtrig-cpu.c2013-08-27 14:46:42.035176153
> -0
= __get_cpu_var(cpu_trig);
+ struct led_trigger_cpu *trig = this_cpu_ptr(cpu_trig);
Sure, please go ahead with my ack.
Acked-by: Bryan Wu coolo...@gmail.com
/* Locate the correct CPU LED */
switch (ledevt) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
wrote:
> 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
> holding the blank
On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
manfred.schla...@gmx.at wrote:
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
ledout register with a mutex to support updates of more than leds at
> the same time
> Fix device tree parsing
>
> v5: Contains feedback from Bryan Wu
> Bryan: Fix device tree bindings documentation
>
Thanks, I've already merged this new patchset into my tree.
-Bryan
> v4: Rebase to l
register with a mutex to support updates of more than leds at
the same time
Fix device tree parsing
v5: Contains feedback from Bryan Wu
Bryan: Fix device tree bindings documentation
Thanks, I've already merged this new patchset into my tree.
-Bryan
v4: Rebase to latest leds-next and new
On Wed, Aug 14, 2013 at 12:14 AM, Ricardo Ribalda Delgado
wrote:
> 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
> ---
> drivers/leds/Kconfig|7 +--
>
On Wed, Aug 14, 2013 at 12:14 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
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.riba...@gmail.com
---
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> This patch-set resolves the application conflict by restoring sysfs files.
>
> For LP5521
> engine1/2/3_mode
> engine1/2/3_load
>
> For LP5523
> engine1/2/3_mode
> engine1/2/3_load
> engine1/2/3_leds
>
> Those attributes are accessed
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
>
Good for merge.
-Bryan
> Signed-off-by: Milo Kim
> ---
> drivers/leds/leds-lp5562.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
> index
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> Now, all legacy application interfaces are restored.
> Each driver documentation is updated.
>
Good to merge, thanks,
-Bryan
> Cc: Pali Rohár
> Signed-off-by: Milo Kim
> ---
> Documentation/leds/leds-lp5521.txt | 20 +++-
>
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0
> (leds-lp5523: use generic firmware interface) causes an application conflict.
> This interface should be maintained for compatibility.
>
> Restored device attributes are 'engineN_mode',
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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().
>
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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.
>
>
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328
> 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'.
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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:
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim wrote:
> 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
On Tue, Aug 13, 2013 at 7:49 AM, Ricardo Ribalda Delgado
wrote:
> Hello Bryan
>
> Did you have a chance to look at the new series?
>
Sorry for the delay. I have no problem for this series. Could you
please rebase to my tree's for-next branch [1]? And post again?
Because recently there were
On Tue, Aug 13, 2013 at 7:49 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hello Bryan
Did you have a chance to look at the new series?
Sorry for the delay. I have no problem for this series. Could you
please rebase to my tree's for-next branch [1]? And post again?
Because
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328
may cause an application confict, engineN_mode and engineN_load.
This interface should be maintained for compatibility.
Restored device attributes are 'engineN_mode' and
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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.
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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.
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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,
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0
(leds-lp5523: use generic firmware interface) causes an application conflict.
This interface should be maintained for compatibility.
Restored device attributes are
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
Now, all legacy application interfaces are restored.
Each driver documentation is updated.
Good to merge, thanks,
-Bryan
Cc: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Milo Kim milo@ti.com
---
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
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.
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
Good for merge.
-Bryan
Signed-off-by: Milo Kim milo@ti.com
---
drivers/leds/leds-lp5562.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp5562.c
On Thu, Aug 8, 2013 at 12:59 AM, Milo Kim woogyom@gmail.com wrote:
This patch-set resolves the application conflict by restoring sysfs files.
For LP5521
engine1/2/3_mode
engine1/2/3_load
For LP5523
engine1/2/3_mode
engine1/2/3_load
engine1/2/3_leds
Those attributes are
On Thu, Aug 8, 2013 at 3:36 PM, Peter Meerwald
wrote:
> Hello,
>
>> > Add support for PCA9634 chip, which belongs to the same family as the
>> > 9633 but with support for 8 outputs instead of 4.
>
>> Basically I like this method to add a new chip supporting. Please find
>> my comments below.
>
>
On Thu, Aug 8, 2013 at 9:45 AM, Ricardo Ribalda Delgado
wrote:
> 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,
On Thu, Aug 8, 2013 at 9:45 AM, Ricardo Ribalda Delgado
wrote:
> Add support for PCA9634 chip, which belongs to the same family as the
> 9633 but with support for 8 outputs instead of 4.
>
Basically I like this method to add a new chip supporting. Please find
my comments below.
> Signed-off-by:
On Thu, Aug 8, 2013 at 9:45 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Add support for PCA9634 chip, which belongs to the same family as the
9633 but with support for 8 outputs instead of 4.
Basically I like this method to add a new chip supporting. Please find
my comments
On Thu, Aug 8, 2013 at 9:45 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
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
On Thu, Aug 8, 2013 at 3:36 PM, Peter Meerwald
p.meerw...@bct-electronic.com wrote:
Hello,
Add support for PCA9634 chip, which belongs to the same family as the
9633 but with support for 8 outputs instead of 4.
Basically I like this method to add a new chip supporting. Please find
my
On Mon, Aug 5, 2013 at 12:31 AM, Pali Rohár wrote:
> On Monday 05 August 2013 09:26:46 Kim, Milo wrote:
>> > Hello,
>> >
>> > git commit "leds-lp5523: use generic firmware interface"
>> > db6eaf8388a413a5ee1b4547ce78506b9c6456b0 introduced in
>> > kernel 3.10 changed user space API for modifing
On Mon, Aug 5, 2013 at 12:31 AM, Pali Rohár pali.ro...@gmail.com wrote:
On Monday 05 August 2013 09:26:46 Kim, Milo wrote:
Hello,
git commit leds-lp5523: use generic firmware interface
db6eaf8388a413a5ee1b4547ce78506b9c6456b0 introduced in
kernel 3.10 changed user space API for modifing
301 - 400 of 1526 matches
Mail list logo
