.
Signed-off-by: Giedrius Statkevičius <giedrius.statkevic...@gmail.com>
Acked-by: Milo Kim <milo@ti.com>
---
drivers/power/supply/lp8788-charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/lp8788-charger.c
b/drivers/power/s
On 3/26/2017 1:00 AM, Giedrius Statkevičius wrote:
val might become 7 in which case stime[7] (array of length 7) would be
accessed during the scnprintf call later and that will cause issues.
Obviously, string concatenation is not intended here so just a comma needs
to be added to fix the issue.
On 3/3/2017 3:21 PM, Rob Herring wrote:
On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:
With index usages, device specific properties can be replaced with generic
one. Vpos is index 0 and Vneg is index 1.
DT examples are added as well.
Signed-off-by: Milo Kim <milo@ti.
On 3/3/2017 3:21 PM, Rob Herring wrote:
On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:
With index usages, device specific properties can be replaced with generic
one. Vpos is index 0 and Vneg is index 1.
DT examples are added as well.
Signed-off-by: Milo Kim
---
On 10/14/2016 4:33 PM, Dan Carpenter wrote:
We checked that "pdata->chg_params" is non-NULL earlier in this function
so when we add "i" to it, it's still non-NULL.
Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
Acked-by: Milo Kim <milo@ti.com&g
On 10/14/2016 4:33 PM, Dan Carpenter wrote:
We checked that "pdata->chg_params" is non-NULL earlier in this function
so when we add "i" to it, it's still non-NULL.
Signed-off-by: Dan Carpenter
Acked-by: Milo Kim
Thanks for catching this.
Best regards,
Milo
<briannor...@chromium.org>
Acked-by: Milo Kim <milo@ti.com>
Thanks!
---
v2: s/TS8555/LP8555/ in comment (typo)
.../devicetree/bindings/leds/backlight/lp855x.txt | 2 ++
drivers/video/backlight/lp855x_bl.c| 29 ++
2 files changed,
On 6/11/2016 4:39 AM, Brian Norris wrote:
The LP8556 datasheet describes an EN/VDDIO input, which serves "both as
a chip enable and as a power supply reference for PWM, SDA, and SCL
inputs." The LP8556 that I'm testing doesn't respond properly if I try
to talk I2C to it too quickly after
previous patches?
This reduces the error code path and .remove callback for removing
MFD child devices and deleting IRQ chip data.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
CC: Milo Kim <milo@ti.com>
---
drivers/mfd/lp8788-irq.c | 12 +++-
drivers/mfd/lp878
Hi Laxman,
On 4/21/2016 9:25 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for adding MFD child devices and
devm_regmap_add_irq_chip() for IRQ chip registration.
This patch doesn't include the code regarding devm_mfd_add_devices().
Could you check it again? Or am I missing any
On 4/5/2016 8:48 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
CC: Milo Kim <milo@ti.com
On 4/5/2016 8:48 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Milo Kim
Acked-by: Milo Kim
---
drivers/mfd/lp3943.c |
Carpenter <dan.carpen...@oracle.com>
Acked-by: Milo Kim <milo@ti.com>
Thanks for catching this!
diff --git a/drivers/mfd/lp8788-irq.c b/drivers/mfd/lp8788-irq.c
index c7a9825..792d51b 100644
--- a/drivers/mfd/lp8788-irq.c
+++ b/drivers/mfd/lp8788-irq.c
@@ -112,7 +112,7
On 3/11/2016 5:11 PM, Dan Carpenter wrote:
Instead to being true/false, the "handled" is true/uninitialized.
Presumably this doesn't cause that many problems in real life because
normally we handle the IRQ.
Fixes: eea6b7cc53aa ('mfd: Add lp8788 mfd driver')
Signed-off-by: Dan Carpenter
>
Acked-by: Milo Kim <milo@ti.com>
Thanks for catching this.
---
drivers/power/lp8788-charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
index f5a48fd..7321b72 100644
--- a/drivers/powe
On 2/27/2016 9:54 PM, Colin King wrote:
From: Colin Ian King
The boolean 'found' is not initialized and hence garbage. It should
be initialized as false.
Found with static analysis using CoverityScan
Signed-off-by: Colin Ian King
Acked-by: Milo Kim
Thanks for catching this.
---
ulator/lp872x.txt | 1 +
drivers/regulator/lp872x.c | 34 ++
include/linux/regulator/lp872x.h | 5
3 files changed, 40 insertions(+)
Acked-by: Milo Kim <milo@ti.com>
Best regards,
Milo
On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: Paul Kocialkowski
---
.../devicetree/bindings/regulator/lp872x.txt | 1
On 2/13/2016 3:25 AM, Paul Kocialkowski wrote:
> >+
> >+ /* Always set enable GPIO high. */
> >+ ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X
EN");
> >+ if (ret) {
> >+ dev_err(lp->dev, "gpio request err: %d\n", ret);
> >+
On 2/13/2016 3:25 AM, Paul Kocialkowski wrote:
> >+
> >+ /* Always set enable GPIO high. */
> >+ ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X
EN");
> >+ if (ret) {
> >+ dev_err(lp->dev, "gpio request err: %d\n", ret);
> >+
Hi Paul,
Thanks for the patch. Please see my comments below.
On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: Paul Kocialkowski
On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
In those cases, it is not a problem to have no DVS GPIO provided, as the current
code will already switch to software-only DVS selection:
When the DVS GPIO is invalid,
Hi Paul,
Thanks for the patch. Please see my comments below.
On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: Paul Kocialkowski
ont...@paulk.fr>
Acked-by: Milo Kim <milo@ti.com>
---
drivers/regulator/lp872x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 19d7584..21c49d8 100644
--- a/drivers/regulator/lp872x.c
+++ b/drive
Hi Jacek,
On 11/30/2015 9:26 PM, Jacek Anaszewski wrote:
In case of LM3633 the real current outputs are banks and multiplexing
that occurs between banks and LVLEDn pins can be conveniently expressed
with the bindings I proposed above.
>If three output channels are controlled by one control
Hi Jacek,
On 11/30/2015 9:26 PM, Jacek Anaszewski wrote:
In case of LM3633 the real current outputs are banks and multiplexing
that occurs between banks and LVLEDn pins can be conveniently expressed
with the bindings I proposed above.
>If three output channels are controlled by one control
Hi Jacek,
Thanks for your detailed feedback. Please refer to my comments below.
On 11/27/2015 8:19 PM, Jacek Anaszewski wrote:
Hi Milo,
Thanks for the update. I have few comments below.
diff --git a/drivers/leds/leds-lm3633.c b/drivers/leds/leds-lm3633.c
new file mode 100644
index
Hi Jacek,
On 11/27/2015 8:19 PM, Jacek Anaszewski wrote:
Hi Milo,
On 11/26/2015 07:56 AM, Milo Kim wrote:
LM3633 LED device is one of TI LMU device list.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Jacek Anaszewski
Cc: Mark Brown
Cc: linux-l...@vger.kernel.org
Cc:
i <j.anaszew...@samsung.com>
Cc: Mark Brown <broo...@kernel.org>
Cc: linux-l...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim <milo@ti.com>
---
.../devicetree/bindings/leds/leds-lm3633.txt | 24
++
1 file changed, 2
..9c391ca
--- /dev/null
+++ b/drivers/leds/leds-lm3633.c
@@ -0,0 +1,840 @@
+/*
+ * TI LM3633 LED driver
+ *
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Milo Kim <milo@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of t
On 11/3/2015 5:33 PM, Lee Jones wrote:
On Tue, 03 Nov 2015, Kim, Milo wrote:
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
drivers/video/backlight/Makefile | 7 +
drivers/video/backlight/lm3532_bl.c
On 11/24/2015 5:18 PM, Lee Jones wrote:
On Tue, 24 Nov 2015, Kim, Milo wrote:
On 11/24/2015 11:35 AM, Kim, Milo wrote:
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read
On 11/3/2015 5:33 PM, Lee Jones wrote:
On Tue, 03 Nov 2015, Kim, Milo wrote:
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
drivers/video/backlight/Makefile | 7 +
drivers/video/backlight/lm3532_bl.c
On 11/24/2015 5:18 PM, Lee Jones wrote:
On Tue, 24 Nov 2015, Kim, Milo wrote:
On 11/24/2015 11:35 AM, Kim, Milo wrote:
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read
On 11/24/2015 11:35 AM, Kim, Milo wrote:
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(lmu
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
>+{
>+ int ret;
>+ unsigned int val;
>+
>+ ret = regmap_read(lmu->regmap, reg, );
>+ if (ret < 0)
>+ return
On 11/24/2015 11:35 AM, Kim, Milo wrote:
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(lmu
Hi Lee,
Thanks for all your comments. Please see my comments below.
On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
>+{
>+ int ret;
>+ unsigned int val;
>+
>+ ret = regmap_read(lmu->regmap, reg, );
>+ if (ret < 0)
>+ return
Hi Jacek,
On 11/20/2015 6:22 PM, Jacek Anaszewski wrote:
On 11/10/2015 08:38 AM, Kim, Milo wrote:
[...]
+cat /sys/class/leds//pattern_levels
+low brightness: 0, high brightness: 255
+
+What:/sys/class/leds//run_pattern
+Date:Oct 2015
Hi Jacek,
On 11/20/2015 6:22 PM, Jacek Anaszewski wrote:
On 11/10/2015 08:38 AM, Kim, Milo wrote:
[...]
+cat /sys/class/leds//pattern_levels
+low brightness: 0, high brightness: 255
+
+What:/sys/class/leds//run_pattern
+Date:Oct 2015
Thanks for all your comments. I'll create the 2nd patch-set in few weeks.
Best regards,
Milo
On 11/11/2015 6:49 PM, Lee Jones wrote:
On Mon, 02 Nov 2015, Milo Kim wrote:
This patch describes overall binding for TI LMU MFD devices.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc:
.jo...@linaro.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim <milo@ti.com>
---
Documentation/devicetree/bindings/mfd/ti-lmu.txt | 282 +++
1 file changed, 282 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
Hi Jacek,
On 11/10/2015 10:44 PM, Jacek Anaszewski wrote:
+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
>>>+ struct device_attribute *attr,
>>>+ const char *buf, size_t len)
>>>+{
>>>+struct ti_lmu_led *lmu_led =
Hi Jacek,
On 11/10/2015 10:44 PM, Jacek Anaszewski wrote:
+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
>>>+ struct device_attribute *attr,
>>>+ const char *buf, size_t len)
>>>+{
>>>+struct ti_lmu_led *lmu_led =
On 11/4/2015 10:59 PM, Mark Brown wrote:
On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:
This looks mostly good, just a few fairly small things:
+lm363x_regulator_of_get_init_data(struct device *dev,
+ struct lm363x_regulator *lm363x_regulator, int id)
+{
+
Hi Jacek,
On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:
Hi Milo,
Thanks for the patch. Please find my comments in the code.
diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..c1d8759
---
Hi Jacek,
On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:
+ - led-max-microamp: Max current setting. Type is .
>+ Unit is microampere. Range is from 5000 to 3.
Could you specify also a step?
Yep, step is 1000. Thanks for catching this.
I'll update the binding in the
Hi Jacek,
On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:
+ - led-max-microamp: Max current setting. Type is .
>+ Unit is microampere. Range is from 5000 to 3.
Could you specify also a step?
Yep, step is 1000. Thanks for catching this.
I'll update the binding in the
ate: Oct 2015
+KernelVersion: 4.3
These properties certainly will not appear in 4.3.
Oops! 4.4 gonna be OK?
+Contact: Milo Kim <milo@ti.com>
+Description: read/write
+Set pattern time dimension. There are five arguments.
+ (1) startup delay
+
On 11/4/2015 10:59 PM, Mark Brown wrote:
On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:
This looks mostly good, just a few fairly small things:
+lm363x_regulator_of_get_init_data(struct device *dev,
+ struct lm363x_regulator *lm363x_regulator, int id)
+{
+
On 11/6/2015 10:57 AM, Rob Herring wrote:
On Mon, Nov 02, 2015 at 02:24:22PM +0900, Milo Kim wrote:
Hardware fault monitoring driver is used in LM3633 and LM3697 device.
Just 'compatible' property is required to describe the driver.
Cc: devicet...@vger.kernel.org
Cc: Guenter Roeck
Cc: Jean
;li...@roeck-us.net>
Cc: Jean Delvare <jdelv...@suse.com>
Cc: Lee Jones <lee.jo...@linaro.org>
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim <milo@ti.com>
Acked-by: Rob Herring <r...@kernel.org>
Thanks for your review, Rob.
HWMON
On 11/3/2015 5:33 PM, Lee Jones wrote:
On Tue, 03 Nov 2015, Kim, Milo wrote:
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
drivers/video/backlight/Makefile | 7 +
drivers/video/backlight/lm3532_bl.c
On 11/3/2015 5:33 PM, Lee Jones wrote:
On Tue, 03 Nov 2015, Kim, Milo wrote:
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
drivers/video/backlight/Makefile | 7 +
drivers/video/backlight/lm3532_bl.c
On 11/3/2015 12:02 AM, Rob Herring wrote:
On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim wrote:
LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
for describing device.
Cc: devicet...@vger.kernel.org
Cc: Jingoo Han
Cc: Lee Jones
Cc: linux-kernel@vger.kernel.org
Hi Lee,
On 11/2/2015 6:00 PM, Lee Jones wrote:
Is it just me, or have you missed lots of people off Cc?
Ah, that's what I was hesitating...
What is the best way to submit MFD code patches? Cc for all people from
get_maintainer.pl?
Best regards,
Milo
--
To unsubscribe from this list: send
Hi Rob,
On 11/2/2015 11:53 PM, Rob Herring wrote:
On Sun, Nov 1, 2015 at 11:01 PM, Milo Kim wrote:
LM3633 LED device is one of TI LMU device list.
Cc: devicet...@vger.kernel.org
Cc: Jacek Anaszewski
Cc: Lee Jones
Cc: linux-kernel@vger.kernel.org
Cc: linux-l...@vger.kernel.org
Hi Guenter,
On 11/2/2015 11:27 PM, Guenter Roeck wrote:
On 11/01/2015 09:24 PM, Milo Kim wrote:
LM3633 and LM3697 are TI LMU MFD device.
Those device have hardware monitoring feature which detects opened or
shorted circuit case.
Sure, but it only makes sense if you provide standard hwmon
On 11/2/2015 9:26 PM, Mark Brown wrote:
On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:
LM363X regulator driver supports LM3631 and LM3632.
LM3631 has 5 regulators. LM3632 provides 3 regulators.
One boost output and LDOs are used for the display module.
Boost voltage is configurable
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
> drivers/video/backlight/Makefile | 7 +
> drivers/video/backlight/lm3532_bl.c| 183 +
> drivers/video/backlight/lm3631_bl.c|
Hi Lee,
On 11/2/2015 5:59 PM, Lee Jones wrote:
drivers/video/backlight/Kconfig| 62 ++
> drivers/video/backlight/Makefile | 7 +
> drivers/video/backlight/lm3532_bl.c| 183 +
> drivers/video/backlight/lm3631_bl.c|
On 11/3/2015 12:02 AM, Rob Herring wrote:
On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim <milo@ti.com> wrote:
LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
for describing device.
Cc: devicet...@vger.kernel.org
Cc: Jingoo Han <jingooh...@gmail.com>
C
Hi Guenter,
On 11/2/2015 11:27 PM, Guenter Roeck wrote:
On 11/01/2015 09:24 PM, Milo Kim wrote:
LM3633 and LM3697 are TI LMU MFD device.
Those device have hardware monitoring feature which detects opened or
shorted circuit case.
Sure, but it only makes sense if you provide standard hwmon
Hi Lee,
On 11/2/2015 6:00 PM, Lee Jones wrote:
Is it just me, or have you missed lots of people off Cc?
Ah, that's what I was hesitating...
What is the best way to submit MFD code patches? Cc for all people from
get_maintainer.pl?
Best regards,
Milo
--
To unsubscribe from this list: send
Hi Rob,
On 11/2/2015 11:53 PM, Rob Herring wrote:
On Sun, Nov 1, 2015 at 11:01 PM, Milo Kim <milo@ti.com> wrote:
LM3633 LED device is one of TI LMU device list.
Cc: devicet...@vger.kernel.org
Cc: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Lee Jones <lee.jo...@linaro
On 11/2/2015 9:26 PM, Mark Brown wrote:
On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:
LM363X regulator driver supports LM3631 and LM3632.
LM3631 has 5 regulators. LM3632 provides 3 regulators.
One boost output and LDOs are used for the display module.
Boost voltage is configurable
Ouch! The notifier.h must be included. I didn't notice this error in ARM
architecture. Let me fix this error in next patch-set.
Thanks a lot for catching this!
Best regards,
Milo
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index eeb6b9e..44268c7 100644
---
My apologies for sending without no-chain-reply-to option.
So, I've resent the patch-set named 'PATCH RESEND 00/16 .. 16/16'.
Best regards,
Milo
On 11/2/2015 2:01 PM, Milo Kim wrote:
TI LMU(Lighting Management Unit) driver supports lighting devices below.
Enable pin Backlights
My apologies for sending without no-chain-reply-to option.
So, I've resent the patch-set named 'PATCH RESEND 00/16 .. 16/16'.
Best regards,
Milo
On 11/2/2015 2:01 PM, Milo Kim wrote:
TI LMU(Lighting Management Unit) driver supports lighting devices below.
Enable pin Backlights
driver
:: TO: Milo Kim <milo@ti.com>
:: CC: 0day robot <fengguang...@intel.com>
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this l
Hi Takashi,
On 9/8/2015 2:06 PM, Takashi Iwai wrote:
On Tue, 08 Sep 2015 02:30:07 +0200,
Kim, Milo wrote:
Hi Takashi,
On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote
Hi Takashi,
On 9/8/2015 2:06 PM, Takashi Iwai wrote:
On Tue, 08 Sep 2015 02:30:07 +0200,
Kim, Milo wrote:
Hi Takashi,
On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote
Hi Takashi,
On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote:
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with
Hi Takashi,
On 9/7/2015 11:19 PM, Jacek Anaszewski wrote:
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote:
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with
Hi Rob,
On 8/28/2015 9:59 PM, Rob Herring wrote:
On Fri, Aug 28, 2015 at 4:12 AM, Milo Kim wrote:
>New function, 'of_dev_get_platdata()'
> - provides unified handling of getting device platform data
> - supports DT and non-DT(legacy) cases
> - removes duplicated code from each driver
> -
Hi Rob,
On 8/28/2015 9:59 PM, Rob Herring wrote:
On Fri, Aug 28, 2015 at 4:12 AM, Milo Kim<milo@ti.com> wrote:
>New function, 'of_dev_get_platdata()'
> - provides unified handling of getting device platform data
> - supports DT and non-DT(legacy) cases
> - removes du
On 8/28/2015 2:41 AM, Bjorn Andersson wrote:
From: Werner Johansson
The driver occasionally got stuck in suspend mode or other strange
states as those parts of the props struct were never initialized.
Acked-by: Milo Kim
Thanks for catching this.
--
To unsubscribe from this list: send the
On 8/28/2015 2:41 AM, Bjorn Andersson wrote:
From: Werner Johansson werner.johans...@sonymobile.com
The driver occasionally got stuck in suspend mode or other strange
states as those parts of the props struct were never initialized.
Acked-by: Milo Kim milo@ti.com
Thanks for catching
Has a kconfig forced a change? Grrr
--
$ git blame ./drivers/leds/Kconfig
--
c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 228) config
LEDS_LP55XX_COMMON
33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 229)
tristate "Common Driver for TI/National LP5521/552
a change? Grrr
--
$ git blame ./drivers/leds/Kconfig
--
c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 228) config
LEDS_LP55XX_COMMON
33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 229)
tristate Common Driver for TI/National LP5521/5523/55231/5562/8501
33b3a561f (Kim
Hi Paul,
On 7/11/2015 5:52 AM, Kim, Milo wrote:
Hi Paul,
On 7/11/2015 5:49 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:43 PM, Kim, Milo wrote:
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim wrote:
LP855x backlight device can be enabled
Hi Paul,
On 7/11/2015 5:49 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:43 PM, Kim, Milo wrote:
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim wrote:
LP855x backlight device can be enabled by external VDD input.
The 'supply' data is used
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim wrote:
LP855x backlight device can be enabled by external VDD input.
The 'supply' data is used for this purpose.
It's kind of private data which runs internally, so there is no reason to
expose to the
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim milo@ti.com wrote:
LP855x backlight device can be enabled by external VDD input.
The 'supply' data is used for this purpose.
It's kind of private data which runs internally, so there is no reason
Hi Paul,
On 7/11/2015 5:49 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:43 PM, Kim, Milo milo@ti.com wrote:
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim milo@ti.com wrote:
LP855x backlight device can be enabled by external VDD input
Hi Paul,
On 7/11/2015 5:52 AM, Kim, Milo wrote:
Hi Paul,
On 7/11/2015 5:49 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:43 PM, Kim, Milo milo@ti.com wrote:
Hi Paul,
On 7/11/2015 12:01 AM, Sean Paul wrote:
On Fri, Jul 10, 2015 at 4:26 AM, Milo Kim milo@ti.com wrote:
LP855x
On 5/13/2015 10:15 AM, Toshi Kikuchi wrote:
Add the usage of the new attributes for master faders.
Signed-off-by: Toshi Kikuchi
Acked-by: Milo Kim
Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi Jacek and Toshi,
On 5/12/2015 4:25 PM, Jacek Anaszewski wrote:
Hi Toshi,
On 05/11/2015 09:10 PM, Toshi Kikuchi wrote:
This patch introduces 4 new attributes:
master_fader_leds
master_fader1
master_fader2
master_fader3
Fo example, to map channel 0,6 to master_fader1,
map
Hi Jacek and Toshi,
On 5/12/2015 4:25 PM, Jacek Anaszewski wrote:
Hi Toshi,
On 05/11/2015 09:10 PM, Toshi Kikuchi wrote:
This patch introduces 4 new attributes:
master_fader_leds
master_fader1
master_fader2
master_fader3
Fo example, to map channel 0,6 to master_fader1,
map
On 5/13/2015 10:15 AM, Toshi Kikuchi wrote:
Add the usage of the new attributes for master faders.
Signed-off-by: Toshi Kikuchi tos...@chromium.org
Acked-by: Milo Kim milo@ti.com
Best regards,
Milo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Bryan,
On 5/12/2015 4:10 AM, Toshi Kikuchi wrote:
This patch introduces 4 new attributes:
master_fader_leds
master_fader1
master_fader2
master_fader3
Fo example, to map channel 0,6 to master_fader1,
map channel 1,7 to master_fader2,
map channel 2,8 to master_fader3, and
map
channel 3,4,5 to none
echo 123000123 master_fader_leds
A different factor can be set to each master_fader:
echo 255 master_fader1
echo 100 master_fader2
echo 0 master_fader3
Signed-off-by: Toshi Kikuchi tos...@chromium.org
Acked-by: Milo Kim milo@ti.com
Tested-by: Milo Kim milo
Hello Jonathan and Stanimir,
> >> See Documentation/ABI/sysfs-bus-iio
> >> Millivolts I think... We copied hwmon where possible.
> >
> > I'm a bit confused about these units. I searched references of
> > iio_read_channel_processed() and found a few.
> >
> > The iio_hwmon expecting milivolts. On
Hello Jonathan and Stanimir,
See Documentation/ABI/sysfs-bus-iio
Millivolts I think... We copied hwmon where possible.
I'm a bit confused about these units. I searched references of
iio_read_channel_processed() and found a few.
The iio_hwmon expecting milivolts. On the other side
Hi Bryan,
> -Original Message-
> From: Bryan Wu [mailto:coolo...@gmail.com]
> Sent: Wednesday, August 14, 2013 3:56 AM
> To: Milo Kim
> Cc: Pali Rohár; Linux LED Subsystem; lkml; Kim, Milo
> Subject: Re: [PATCH 01/10] leds: lp55xx: add common data structure for
> pro
Hi Bryan,
-Original Message-
From: Bryan Wu [mailto:coolo...@gmail.com]
Sent: Wednesday, August 14, 2013 3:56 AM
To: Milo Kim
Cc: Pali Rohár; Linux LED Subsystem; lkml; Kim, Milo
Subject: Re: [PATCH 01/10] leds: lp55xx: add common data structure for
program
On Thu, Aug 8, 2013
> Hello,
>
> git commit "leds-lp5523: use generic firmware interface"
> db6eaf8388a413a5ee1b4547ce78506b9c6456b0 introduced in kernel
> 3.10 changed user space API for modifing lp5523 led patterns via /sys.
>
> Before this commit there were sysfs attributes engineX_mode, engineX_load and
>
> > > Although, I think the 0 = 1, 1 = 2 ... stuff is really confusing. Is
> > > there nothing we can do about that?
> >
> > OK, enum value of lp3943_pwm_output can be changed as below because
> > LP3943_PWM_INVALID is not used anymore.
> >
> > enum lp3943_pwm_output {
> > LP3943_PWM_OUT0,
> >
Although, I think the 0 = 1, 1 = 2 ... stuff is really confusing. Is
there nothing we can do about that?
OK, enum value of lp3943_pwm_output can be changed as below because
LP3943_PWM_INVALID is not used anymore.
enum lp3943_pwm_output {
LP3943_PWM_OUT0,
Hello,
git commit leds-lp5523: use generic firmware interface
db6eaf8388a413a5ee1b4547ce78506b9c6456b0 introduced in kernel
3.10 changed user space API for modifing lp5523 led patterns via /sys.
Before this commit there were sysfs attributes engineX_mode, engineX_load and
engineX_leds
1 - 100 of 758 matches
Mail list logo
