> Sorry for the delay. I'm busy in company work.
> These 2 patches looks fine with me.
> But I think we can fold this 2 patches into one.
> Do you mind I doing this and merge to my for-next?
Hi Bryan,
It looks you've already done in 'devel' branch in linux-leds.
Thanks!
Best Regards,
Milo
--
To
Sorry for the delay. I'm busy in company work.
These 2 patches looks fine with me.
But I think we can fold this 2 patches into one.
Do you mind I doing this and merge to my for-next?
Hi Bryan,
It looks you've already done in 'devel' branch in linux-leds.
Thanks!
Best Regards,
Milo
--
To
+#if defined(CONFIG_LEDS_TRIGGER_CAMERA) ||
defined(CONFIG_LEDS_TRIGGER_CAMERA_MODULE)
+extern void ledtrig_flash_ctrl(bool on);
+extern void ledtrig_torch_ctrl(bool on);
+#else
+#define ledtrig_flash_ctrl(x) do {} while(0)
+#define ledtrig_torch_ctrl(x) do {} while(0)
It's better
-Original Message-
From: Bryan Wu [mailto:coolo...@gmail.com]
Sent: Thursday, March 14, 2013 8:19 AM
To: Kim, Milo
Cc: linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; Jeong,
Daniel
Subject: Re: [PATCH 2/3] leds: add LED Trigger for camera function
On Wed, Mar 13, 2013
TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight driver
and current sinks.
This patch enables LP8788 backlight module.
(Brightness mode)
The brightness is controlled by PWM input or I2C register.
All modes are supported in the driver.
(Platform data)
Configurable data can
.
Replace module_init() and module_exit() with module_platform_driver().
Patch v1.
Initial patch
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/video/backlight/Kconfig |6 +
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lp8788_bl.c | 333
> For this kind of patches you should really use the "-M" flag of "git
> format-patch" to activate rename detection. The patch becomes much
> more
> readable. For example, the diffstat for this one using -M is:
Thanks for useful tip!
Regards,
Milo
--
To unsubscribe from this list: send the
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().
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
This patch-set consists of major changes below.
(a) Move trigger drivers into new subdirectory, 'drivers/leds/trigger/'
(b) Add LED trigger for camera functions: 'flash' and 'torch'
(c) Support camera LED trigger feature in existing drivers: LM355x and LM3642
Milo(Woogyom) Kim (3):
leds:
This patch-set consists of major changes below.
(a) Move trigger drivers into new subdirectory, 'drivers/leds/trigger/'
(b) Add LED trigger for camera functions: 'flash' and 'torch'
(c) Support camera LED trigger feature in existing drivers: LM355x and LM3642
Milo(Woogyom) Kim (3):
leds:
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
-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/trigger/Kconfig |8 +
drivers/leds/trigger/Makefile |1 +
drivers/leds/trigger/ledtrig-camera.c | 57 +
include/linux/leds.h |8 +
4 files changed, 74
For this kind of patches you should really use the -M flag of git
format-patch to activate rename detection. The patch becomes much
more
readable. For example, the diffstat for this one using -M is:
Thanks for useful tip!
Regards,
Milo
--
To unsubscribe from this list: send the line
LP8557 is one of LP855x family device, but it has different register map
and initialization process.
To support this device, device specific configuration is done through the
lp855x_device_config structure.
Few register definitions are fixed for better readability.
BRIGHTNESS_CTRL ->
Getting the brightness value is not critical, no need to read the actual
register value. To simplify it, just return the 'bl->props.brightness' value.
Then, lp855x_read_byte() can be removed, not used any more.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/video/backlight/lp855x_bl.c | 24
At this moment, LP855x device driver has fixed register configuration.
For example, fixed register addresses and values are set on the device
initialization.
But new device of LP855x family, LP8557 has different register map and
initialization sequence.
To support new device architecture,
To support new device LP8557, LP855x device initialization process should be
changed.
This patch-set enables re-designing LP855x driver architecture and
supporting LP8557 device.
Milo(Woogyom) Kim (3):
backlight: lp855x_bl: introduce device configuration flow
backlight: lp855x_bl: support new
To support new device LP8557, LP855x device initialization process should be
changed.
This patch-set enables re-designing LP855x driver architecture and
supporting LP8557 device.
Milo(Woogyom) Kim (3):
backlight: lp855x_bl: introduce device configuration flow
backlight: lp855x_bl: support new
()
Name change
===
Use generic name 'lp855x_configure()' instead of 'lp855x_init_registers()'.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/video/backlight/lp855x_bl.c | 78 ++-
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git
.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
Documentation/backlight/lp855x-driver.txt |4 +-
drivers/video/backlight/Kconfig |2 +-
drivers/video/backlight/lp855x_bl.c | 87 -
include/linux/platform_data/lp855x.h | 19
Getting the brightness value is not critical, no need to read the actual
register value. To simplify it, just return the 'bl-props.brightness' value.
Then, lp855x_read_byte() can be removed, not used any more.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/video/backlight
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
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/leds-lp55xx-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lp55xx-common.c
b/drivers/leds/leds-lp55xx-common.c
index d9eb841..8a388a4 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp55xx-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lp55xx-common.c
b/drivers/leds/leds-lp55xx-common.c
index d9eb841..8a388a4 100644
--- a/drivers/leds/leds-lp55xx
are added.
Pattern RGB data is fixed as constant value.
(No side effect on other devices, LP5521 or LP5523.)
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
Documentation/leds/00-INDEX |2 +
Documentation/leds/leds-lp5562.txt| 135 +++
Documentation/leds/leds
The regulator_dev has regulator_enable_gpio structure.
'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.
regulator_dev ---> regulator_enable_gpio
.ena_gpio .gpio
.ena_gpio_invert .ena_gpio_invert
Pointer, 'ena_pin' is used for checking
To support shared enable GPIO pin, replace GPIO code with new static functions
Reference count: 'enable_count'
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator. Now, enable GPIO is shared among regulators.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Signed-off-by:
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared
A Regulator can be enabled by external GPIO pin which is configurable in the
regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices like LP8788 LDOs, multiple regulators are enabled by shared
one GPIO pin.
This patch-set enables shared enable GPIO
were moved to
new function, regulator_ena_gpio_request().
Use regulator_enable_pin structure rather than regulator_dev.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c | 86 +-
include/linux/regulator/driver.h
A Regulator can be enabled by external GPIO pin which is configurable in the
regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices like LP8788 LDOs, multiple regulators are enabled by shared
one GPIO pin.
This patch-set enables shared enable GPIO
(Woogyom) Kim milo@ti.com
---
drivers/regulator/lp8788-ldo.c | 98 +++-
1 file changed, 17 insertions(+), 81 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index cd5a14a..fcba90a 100644
--- a/drivers/regulator
GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count =1)
Regardless of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c | 50
enable GPIO pin.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c |6 +++---
include/linux/regulator/driver.h |2 --
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 57d434d
> Thanks applying 1 and 2 into omap-for-v3.9/board. Did not
> see patch 3 of this anywhere?
Thank you.
The third patch is for the TPS65910 PMU on the Craneboard.
It was already applied.
https://lkml.org/lkml/2012/11/30/192
Regards,
Milo
--
To unsubscribe from this list: send the line
Thanks applying 1 and 2 into omap-for-v3.9/board. Did not
see patch 3 of this anywhere?
Thank you.
The third patch is for the TPS65910 PMU on the Craneboard.
It was already applied.
https://lkml.org/lkml/2012/11/30/192
Regards,
Milo
--
To unsubscribe from this list: send the line unsubscribe
The printk format of type 'size_t' is not '%d' but '%zu' or '%zx'.
This patch fixes build warnings below.
drivers/leds/leds-lp5521.c: In function lp5521_firmware_loaded:
drivers/leds/leds-lp5521.c:257:4: warning: format %d expects argument of
type int, but argument 3 has type size_t
To solve undefined symbols for LED class and I2C, lp55xx-common driver should
support a module build as well.
In case of CONFIG_I2C=m, CONFIG_LEDS_LP5521/5523=m, it still has undefined
symbol problems because CONFIG_LEDS_LP55XX_COMMON can be selected as 'y'.
Moreover, I2C functions are used in
This patch clears a build warning below.(ARCH=x86_64)
drivers/leds/leds-lp5523.c: In function lp5523_firmware_loaded:
drivers/leds/leds-lp5523.c:283:4: warning: format %d expects argument of type in
t, but argument 3 has type size_t [-Wformat]
Signed-off-by: Milo(Woogyom) Kim
---
This patch removes a build warning below.(ARCH=x86_64)
drivers/leds/leds-lp5521.c: In function lp5521_firmware_loaded:
drivers/leds/leds-lp5521.c:257:4: warning: format %d expects argument of type in
t, but argument 3 has type size_t [-Wformat]
Signed-off-by: Milo(Woogyom) Kim
---
This patch removes a build warning below.(ARCH=x86_64)
drivers/leds/leds-lp5521.c: In function lp5521_firmware_loaded:
drivers/leds/leds-lp5521.c:257:4: warning: format %d expects argument of type in
t, but argument 3 has type size_t [-Wformat]
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
This patch clears a build warning below.(ARCH=x86_64)
drivers/leds/leds-lp5523.c: In function lp5523_firmware_loaded:
drivers/leds/leds-lp5523.c:283:4: warning: format %d expects argument of type in
t, but argument 3 has type size_t [-Wformat]
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
`lp55xx_update_bits':
(.text+0x162492): undefined reference to `i2c_smbus_write_byte_data'
drivers/built-in.o: In function `lp55xx_write':
(.text+0x1624c5): undefined reference to `i2c_smbus_write_byte_data'
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/Kconfig |5 +++--
1 file changed, 3
]
drivers/leds/leds-lp5523.c: In function lp5523_firmware_loaded:
drivers/leds/leds-lp5523.c:283:4: warning: format %d expects argument of
type int, but argument 3 has type size_t [-Wformat]
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/leds-lp5521.c |2 +-
drivers
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Wednesday, January 23, 2013 1:12 PM
> To: Bryan Wu
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Kim, Milo
> Subject: linux-next: build failure after merge of the leds
To solve undefined symbol errors for LED class and I2C, lp55xx-common driver
should support a module build as well.
make x86_64 allmodconfig failed like this:
drivers/built-in.o: In function `lp55xx_unregister_leds':
(.text+0x161dab): undefined reference to `led_classdev_unregister'
: In function `lp55xx_update_bits':
(.text+0x162492): undefined reference to `i2c_smbus_write_byte_data'
drivers/built-in.o: In function `lp55xx_write':
(.text+0x1624c5): undefined reference to `i2c_smbus_write_byte_data'
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/Kconfig |2
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Wednesday, January 23, 2013 1:12 PM
To: Bryan Wu
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Kim, Milo
Subject: linux-next: build failure after merge of the leds tree
Hi Bryan
> > OK, the consumer just cares about the regulator(s) which is(are)
> obtained.
> > However it doesn't show exact state of regulator in case that enable
> GPIOs are
> > shared.
>
> It would do if my suggestion that we use a shared state for the GPIO
> were implemented!
>
> > (6) CB tries to get
OK, the consumer just cares about the regulator(s) which is(are)
obtained.
However it doesn't show exact state of regulator in case that enable
GPIOs are
shared.
It would do if my suggestion that we use a shared state for the GPIO
were implemented!
(6) CB tries to get the state of
> There is only one caller calling _rdev_to_offset(), and the code
> looks simper if we remove _rdev_to_offset(). Thus remove it.
Acked-by: Milo Kim
> -Original Message-
> From: Nathan Lynch [mailto:n...@pobox.com]
>
> On Thu, 2013-01-17 at 01:06 +0000, Kim, Milo wrote:
> > @@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
> > void led_trigger_event(struct led_trigger *trig,
> >
-Original Message-
From: Nathan Lynch [mailto:n...@pobox.com]
On Thu, 2013-01-17 at 01:06 +, Kim, Milo wrote:
@@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
void led_trigger_event(struct led_trigger *trig,
enum led_brightness brightness
There is only one caller calling _rdev_to_offset(), and the code
looks simper if we remove _rdev_to_offset(). Thus remove it.
Acked-by: Milo Kim milo@ti.com
> The vout address for buck[1|2] can be easily calculated,
> thus remote these arrays.
>
> Signed-off-by: Axel Lin
Acked-by: Milo Kim
Use general name, 'list' rather than 'next_trig'.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/led-triggers.c | 12 ++--
include/linux/leds.h|3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/led-triggers.c
There are two list_heads for handling LED trigger function.
'trig_list' of led_classdev and 'led_cdevs' of led_trigger.
Those are added/removed with led_trigger_set().
To find exact LED device, those are scanned in led_trigger_event() and
led_trigger_blink_setup().
But without additional
LED device.
We can get LED device from registered LED device list.
Removed list heads: 'trig_list' and 'led_cdevs'.
Not used any more
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/led-triggers.c | 27 ---
include/linux/leds.h|2
Use general name, 'list' rather than 'next_trig'.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/leds/led-triggers.c | 12 ++--
include/linux/leds.h|3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/leds/led-triggers.c b/drivers
The vout address for buck[1|2] can be easily calculated,
thus remote these arrays.
Signed-off-by: Axel Lin axel@ingics.com
Acked-by: Milo Kim milo@ti.com
The regulator_ena_gpio_request() allocates the enable GPIO and add the list.
Related resources should be released if they are not used any more.
To free requested GPIO and remove it from the enable GPIO list,
new function, 'regulator_ena_gpio_free()' is added.
Signed-off-by: Milo(Woogyom) Kim
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, this enable GPIO is owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared
To support shared enable GPIO pin, replace GPIO code with new static functions
regulator_ena_gpio_ctrl()
Find a GPIO information in the enable GPIO list and control the pin.
_do_ena_gpio_ctrl()
Balance the reference count of each GPIO and actual pin control.
The count is incremented
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator. Now, enable GPIO is shared among regulators.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Signed-off-by:
.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c | 49 +++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index de47880..1273090 100644
--- a/drivers
of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c | 54 --
1 file changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator
(Woogyom) Kim milo@ti.com
---
drivers/regulator/lp8788-ldo.c | 98 +++-
1 file changed, 17 insertions(+), 81 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index cd5a14a..fcba90a 100644
--- a/drivers/regulator
The regulator_ena_gpio_request() allocates the enable GPIO and add the list.
Related resources should be released if they are not used any more.
To free requested GPIO and remove it from the enable GPIO list,
new function, 'regulator_ena_gpio_free()' is added.
Signed-off-by: Milo(Woogyom) Kim
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
>
> So, clearly that's going to be the behaviour at the system level but
> the
> consumers aren't going to know that. If the consumer supports some of
> the supplies being enabled and disabled separately then it will rely on
> the
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
>
> This isn't quite going to work properly - we need to actually move the
> state (and also a reference count) into some sort of shared state.
> Otherwise consider what happens in this scenario:
>
> 1. regulator 1 enables
>
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
This isn't quite going to work properly - we need to actually move the
state (and also a reference count) into some sort of shared state.
Otherwise consider what happens in this scenario:
1. regulator 1 enables
2.
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
So, clearly that's going to be the behaviour at the system level but
the
consumers aren't going to know that. If the consumer supports some of
the supplies being enabled and disabled separately then it will rely on
the
This patch fixes a limitation in case of multiple enable pin usages.
Several regulators can be enabled/disabled at the same time by one
shared GPIO pin.
If specific GPIO pin is already used, then skip requesting the GPIO.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 21
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Cc: Axel Lin
Signed-off-by: Milo(Woogyom) Kim
---
When a regulator is enabled or disabled, enable GPIO state is changed if it is
used.
If multiple regulators are controlled by one shared GPIO, pin states of other
GPIOs should be updated also.
Look up the list of regulators and change the enable pin state if same GPIO
is used. It guarantees
exact value of regulator_is_enabled().
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator/core.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 21b4247..44b2d61 100644
This patch fixes a limitation in case of multiple enable pin usages.
Several regulators can be enabled/disabled at the same time by one
shared GPIO pin.
If specific GPIO pin is already used, then skip requesting the GPIO.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
drivers/regulator
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Cc: Axel Lin axel@ingics.com
Signed-off-by: Milo(Woogyom) Kim
> -Original Message-
> From: Bryan Wu [mailto:coolo...@gmail.com]
> Sent: Thursday, January 10, 2013 10:16 AM
> To: Kim, Milo
> Cc: Jeong, Daniel; gshark.je...@gmail.com; linux-l...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] leds-lm355x
-Original Message-
From: Bryan Wu [mailto:coolo...@gmail.com]
Sent: Thursday, January 10, 2013 10:16 AM
To: Kim, Milo
Cc: Jeong, Daniel; gshark.je...@gmail.com; linux-l...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] leds-lm355x: support LED trigger
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Tuesday, January 08, 2013 7:44 PM
> To: Axel Lin
> Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFT] regulator: lp8788-ldo: Use ldo-
> -Original Message-
> From: linux-leds-ow...@vger.kernel.org [mailto:linux-leds-
> ow...@vger.kernel.org] On Behalf Of Jason Cooper
> Sent: Wednesday, January 09, 2013 5:04 AM
> To: Josh Coombs
> Cc: coolo...@gmail.com; linux-kernel@vger.kernel.org; linux-
> i...@vger.kernel.org;
-Original Message-
From: linux-leds-ow...@vger.kernel.org [mailto:linux-leds-
ow...@vger.kernel.org] On Behalf Of Jason Cooper
Sent: Wednesday, January 09, 2013 5:04 AM
To: Josh Coombs
Cc: coolo...@gmail.com; linux-kernel@vger.kernel.org; linux-
i...@vger.kernel.org;
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Tuesday, January 08, 2013 7:44 PM
To: Axel Lin
Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFT] regulator: lp8788-ldo: Use ldo-en_pin to
check if regulator
LM355x family devices provide flash, torch and indicator functions.
This patch support LED trigger feature.
Using LED trigger APIs(), other driver simply turn on/off the flash, torch
and indicator.
Platform data
the name of LED trigger is configurable.
Documentation
example and
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Monday, January 07, 2013 8:08 PM
> To: Axel Lin
> Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFT] regulator: lp8788-ldo: Use ldo-
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Monday, January 07, 2013 8:08 PM
To: Axel Lin
Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFT] regulator: lp8788-ldo: Use ldo-en_pin to
check if regulator
and detailed description added.
Signed-off-by: Milo(Woogyom) Kim milo@ti.com
---
Documentation/leds/leds-lm3556.txt| 62 +
drivers/leds/leds-lm355x.c|3 ++
include/linux/platform_data/leds-lm355x.h |8
3 files changed, 73 insertions
Hi Axel,
> -Original Message-
> From: Axel Lin [mailto:axel@ingics.com]
> Sent: Saturday, January 05, 2013 4:34 PM
> To: Mark Brown
> Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
> Subject: [PATCH RFT] regulator: lp8788-ldo: Use ldo->en_pin to
> -Original Message-
> From: Bryan Wu [mailto:coolo...@gmail.com]
> Sent: Saturday, January 05, 2013 3:46 AM
> To: Kim, Milo
> Cc: linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 00/33] leds: cleanup LP5521/5523 LED driver
>
> On Thu,
-Original Message-
From: Bryan Wu [mailto:coolo...@gmail.com]
Sent: Saturday, January 05, 2013 3:46 AM
To: Kim, Milo
Cc: linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/33] leds: cleanup LP5521/5523 LED driver
On Thu, Dec 20, 2012 at 4:17 PM, Kim
Hi Axel,
-Original Message-
From: Axel Lin [mailto:axel@ingics.com]
Sent: Saturday, January 05, 2013 4:34 PM
To: Mark Brown
Cc: Kim, Milo; Girdwood, Liam; linux-kernel@vger.kernel.org
Subject: [PATCH RFT] regulator: lp8788-ldo: Use ldo-en_pin to check if
regulator is enabled
Hi Thierry,
> > (Platform data)
> > Configurable data can be defined in the platform side.
> > name : backlight driver name. (default: "lcd-
> backlight")
> > initial_brightness: initial value of backlight brightness
> > bl_mode : brightness control by PWM or
Hi Thierry,
(Platform data)
Configurable data can be defined in the platform side.
name : backlight driver name. (default: lcd-
backlight)
initial_brightness: initial value of backlight brightness
bl_mode : brightness control by PWM or lp8788
Use 'platform_device' rather than i2c client device node.
Argument is added in lp8788_config_ldo_enable_mode().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-ldo.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
The lp8788-ldo is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc,
Remove space before semicolon in for-loop.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-buck.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp8788-buck.c
index 98770e8..1161949 100644
---
Use 'platform_device' rather than i2c client device node.
Arguments are added in lp8788_init_dvs() and lp8788_dvs_gpio_request().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-buck.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
201 - 300 of 758 matches
Mail list logo
