From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: "Kim, Milo" <milo.kim@ti.com>
Cc: devicetree@vger.kernel.org, lee.jones@linaro.org,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH RESEND 15/16] leds: add LM3633 driver
Date: Tue, 10 Nov 2015 14:44:51 +0100 [thread overview]
Message-ID: <5641F4D3.7000800@samsung.com> (raw)
In-Reply-To: <56419F0C.90009@ti.com>
On 11/10/2015 08:38 AM, Kim, Milo wrote:
> 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 0000000..c1d8759
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
>>> @@ -0,0 +1,60 @@
>>> +LM3633 LED driver generates programmable pattern via the sysfs.
>>> +
>>> +LED Pattern Generator Structure
>>> +
>>> + (3)
>>> + (a) ---------------> ___________
>>> + / \
>>> + (2) / \ (4)
>>> + (b) ----> _________/ \_________ ...
>>> + (1) (5)
>>> +
>>> + |<----- period -----> |
>>> +
>>> +What: /sys/class/leds/<led>/pattern_times
>>
>> "time" noun is uncountable.
>>
>>> +Date: Oct 2015
>>> +KernelVersion: 4.3
>>
>> These properties certainly will not appear in 4.3.
>
> Oops! 4.4 gonna be OK?
We have currently 4.4 merge window, so the most plausible is 4.5.
>>
>>> +Contact: Milo Kim <milo.kim@ti.com>
>>> +Description: read/write
>>> + Set pattern time dimension. There are five arguments.
>>> + (1) startup delay
>>> + (2) rising dimming time
>>> + (3) how much time stays at high level
>>> + (4) falling dimming time
>>> + (5) how much time stays at low level
>>> + Ranges are
>>> + (1), (3), (5): 0 ~ 10000. Unit is millisecond.
>>> + (2), (4): 0 ~ 16000. Unit is millisecond.
>>> +
>>> + Example:
>>> + No delay, rising 200ms, high 300ms, falling 100ms,
>>> low 400ms.
>>> + echo "0 200 300 100 400" >
>>> /sys/class/leds/<led>/pattern_times
>>> +
>>> + cat /sys/class/leds/<led>/pattern_times
>>> + delay: 0, rise: 200, high: 300, fall: 100, low: 400
>>
>> Generally a sysfs attribute should represent a single value.
>> There are cases where the attribute comprises a list of space separated
>> values, but certainly colons and commas adds to much noise, and are
>> cumbersome to parse. I'd opt for creating a separate sysfs attribute
>> for each of the above 5 properties.
>
> Got it, thanks!
>
>>
>>> +What: /sys/class/leds/<led>/pattern_levels
>>> +Date: Oct 2015
>>> +KernelVersion: 4.3
>>> +Contact: Milo Kim <milo.kim@ti.com>
>>> +Description: read/write
>>> + Set pattern level(brightness). There are two arguments.
>>> + (a) Low brightness level
>>> + (b) High brightness level
>>> + Ranges are from 0 to 255.
>>> +
>>> + Example:
>>> + Low level is 0, high level is 255.
>>> + echo "0 255" > /sys/class/leds/<led>/pattern_levels
>>
>> I'd go also for two separate attributes. E.g. pattern_brightness_lo and
>> pattern_brightness_hi, or maybe you'll have better idea.
>
> OK.
>
>>
>>> + cat /sys/class/leds/<led>/pattern_levels
>>> + low brightness: 0, high brightness: 255
>>> +
>>> +What: /sys/class/leds/<led>/run_pattern
>>> +Date: Oct 2015
>>> +KernelVersion: 4.3
>>> +Contact: Milo Kim <milo.kim@ti.com>
>>> +Description: write only
>>> + After 'pattern_times' and 'pattern_levels' are updated,
>>> + run the pattern by writing 1 to 'run_pattern'.
>>> + To stop running pattern, writes 0 to 'run_pattern'.
>>
>> I wonder how registering an in-driver trigger would work. It would
>> allow for hiding above pattern attributes when the trigger is inactive,
>> and thus making the sysfs interface more transparent. You could avoid
>> the need for run_pattern attribute, as setting the trigger would itself
>> activate the pattern, and setting brightness to 0 would turn it off.
>
> I like this idea, let me try to fix it.
>
>>> +/**
>>> + * struct ti_lmu_led
>>> + *
>>> + * @chip: Pointer to parent LED device
>>> + * @bank_id: LED bank ID
>>> + * @cdev: LED subsystem device structure
>>> + * @name: LED channel name
>>> + * @led_string: LED string configuration.
>>> + * Bit mask is set on parsing DT.
>>> + * @imax: [Optional] Max current index.
>>> + * It's result of ti_lmu_get_current_code().
>>
>> Why is this optional?
>
> You're correct, this is not optional. DT property is optional.
>
>>> +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 = to_ti_lmu_led(dev);
>>> + struct ti_lmu_led_chip *chip = lmu_led->chip;
>>> + unsigned int low, high;
>>> + u8 reg, offset, val;
>>> + int ret;
>>> +
>>> + /*
>>> + * Sequence
>>> + *
>>> + * 1) Read pattern level data
>>> + * 2) Disable a bank before programming a pattern
>>> + * 3) Update LOW BRIGHTNESS register
>>> + * 4) Update HIGH BRIGHTNESS register
>>> + *
>>> + * Level register addresses have offset number based on the LED
>>> bank.
>>> + */
>>> +
>>> + ret = sscanf(buf, "%u %u", &low, &high);
>>> + if (ret != 2)
>>> + return -EINVAL;
>>> +
>>> + low = min_t(unsigned int, low, LM3633_LED_MAX_BRIGHTNESS);
>>
>> Why don't you take into account the value defined by led-max-microamp
>> DT property here?
>
> 'low' and 'high' are brightness value. The range is from 0 to 255. It is
> mostly related with LED sysfs - /sys/class/led/<led>/brightness.
> On the other hand, led-max-microamp is current limit. It is from 5mA to
> 30mA. It's different configuration in this device.
Doesn't the current has direct influence on the LED brightness?
Are there other means for adjusting brightness than current setting?
I see in your enum ti_lmu_max_current, that there are 26 possible
current levels. I think that they should reflect 26 possible
brightness levels, so max_brightness can be at most 26.
led-max-microamp was designed for defining max brightness limit.
It should be converted into max brightness level in the driver and
assigned to max_brightness property of struct led_classdev.
This attribute overrides legacy 0-255 brightness scale.
>>> +static void lm3633_led_work(struct work_struct *work)
>>> +{
>>> + struct ti_lmu_led *lmu_led = container_of(work, struct ti_lmu_led,
>>> + work);
>>> + struct ti_lmu_led_chip *chip = lmu_led->chip;
>>> + int ret;
>>> +
>>> + mutex_lock(&chip->lock);
>>> +
>>> + ret = ti_lmu_write_byte(chip->lmu,
>>> + LM3633_REG_BRT_LVLED_BASE + lmu_led->bank_id,
>>> + lmu_led->brightness);
>>> + if (ret) {
>>> + mutex_unlock(&chip->lock);
>>> + return;
>>> + }
>>> +
>>> + if (lmu_led->brightness == 0)
>>> + lm3633_led_disable_bank(lmu_led);
>>> + else
>>> + lm3633_led_enable_bank(lmu_led);
>>
>> Is it possible to control a brightness of a whole bank only,
>> and not individual LEDs?
>
> No, LM3633 has internal control banks. Let me assume that two LED groups
> are assigned below.
> LED 1, 2, 3 - RGB
> LED 4 - status
> Two control banks should be allocated. The bank should be controlled
> separately. If we try to enable/disabe all banks, then 6 output LED
> channels are controlled at the same time.
OK, I'll wait for the next version of the patch to discuss this in
detail.
>>> +static int lm3633_led_init(struct ti_lmu_led *lmu_led, int bank_id)
>>> +{
>>> + struct device *dev = lmu_led->chip->dev;
>>> + char name[12];
>>> + int ret;
>>> +
>>> + /*
>>> + * Sequence
>>> + *
>>> + * 1) Configure LED bank which is used for brightness control
>>> + * 2) Set max current for each output channel
>>> + * 3) Add LED device
>>> + */
>>> +
>>> + ret = lm3633_led_config_bank(lmu_led);
>>> + if (ret) {
>>> + dev_err(dev, "Output bank register err: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = lm3633_led_set_max_current(lmu_led);
>>> + if (ret) {
>>> + dev_err(dev, "Set max current err: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + lmu_led->cdev.max_brightness = LM3633_LED_MAX_BRIGHTNESS;
>>
>> The value assigned here should be determined by led-max-microamp
>> DT property.
>
> Ditto. Current limit is different configuration from brightness value.
It should be converted to the corresponding brightness level. See other
LED class drivers using led-max-microamp property (e.g. leds-aat1290).
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-11-10 13:44 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-02 5:24 [PATCH RESEND 00/16] Support TI LMU devices Milo Kim
[not found] ` <1446441875-1256-1-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-02 5:24 ` [PATCH RESEND 01/16] Documentation: dt-bindings: mfd: add TI LMU device binding information Milo Kim
2015-11-06 2:00 ` Rob Herring
2015-11-11 9:49 ` Lee Jones
2015-11-12 0:05 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 02/16] Documentation: dt-bindings: backlight: add TI LMU backlight " Milo Kim
2015-11-02 15:02 ` Rob Herring
2015-11-03 7:13 ` Kim, Milo
2015-11-03 15:32 ` Rob Herring
2015-11-02 5:24 ` [PATCH RESEND 04/16] Documentation: dt-bindings: leds: add LM3633 LED " Milo Kim
[not found] ` <1446441875-1256-5-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-03 16:15 ` Jacek Anaszewski
2015-11-10 7:01 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 05/16] Documentation: dt-bindings: regulator: add LM363x regulator " Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 08/16] backlight: ti-lmu-backlight: add LM3532 driver Milo Kim
[not found] ` <1446441875-1256-9-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-02 5:37 ` kbuild test robot
[not found] ` <201511021324.3ZsaAzBu%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-11-02 7:33 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 11/16] backlight: ti-lmu-backlight: add LM3633 driver Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 12/16] backlight: ti-lmu-backlight: add LM3695 driver Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 13/16] backlight: ti-lmu-backlight: add LM3697 driver Milo Kim
2015-11-02 8:59 ` [PATCH RESEND 00/16] Support TI LMU devices Lee Jones
2015-11-03 6:52 ` Kim, Milo
2015-11-03 8:33 ` Lee Jones
2015-11-03 9:08 ` Kim, Milo
2015-11-25 8:51 ` Kim, Milo
2015-11-25 9:05 ` Lee Jones
2015-11-02 5:24 ` [PATCH RESEND 03/16] Documentation: dt-bindings: hwmon: add TI LMU HWMON binding information Milo Kim
[not found] ` <1446441875-1256-4-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-06 1:57 ` Rob Herring
2015-11-06 3:48 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 06/16] mfd: add TI LMU driver Milo Kim
2015-11-23 10:30 ` Lee Jones
2015-11-24 2:35 ` Kim, Milo
2015-11-24 6:39 ` Kim, Milo
2015-11-24 8:18 ` Lee Jones
2015-11-25 8:10 ` Kim, Milo
[not found] ` <56556D01.9070804-l0cyMroinI0@public.gmane.org>
2015-11-25 8:15 ` Lee Jones
2015-11-02 5:24 ` [PATCH RESEND 07/16] backlight: add TI LMU backlight common driver Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 09/16] backlight: ti-lmu-backlight: add LM3631 driver Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 10/16] backlight: ti-lmu-backlight: add LM3632 driver Milo Kim
2015-11-02 5:24 ` [PATCH RESEND 14/16] hwmon: add TI LMU hardware fault monitoring driver Milo Kim
[not found] ` <1446441875-1256-15-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-02 14:27 ` Guenter Roeck
2015-11-03 7:01 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 15/16] leds: add LM3633 driver Milo Kim
2015-11-03 16:15 ` Jacek Anaszewski
[not found] ` <5638DD99.9070502-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-11-10 7:38 ` Kim, Milo
2015-11-10 13:44 ` Jacek Anaszewski [this message]
[not found] ` <5641F4D3.7000800-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-11-11 2:16 ` Kim, Milo
2015-11-12 9:04 ` Jacek Anaszewski
2015-11-20 9:22 ` Jacek Anaszewski
2015-11-22 23:40 ` Kim, Milo
[not found] ` <56525262.60308-l0cyMroinI0@public.gmane.org>
2015-11-23 11:17 ` Jacek Anaszewski
2015-11-02 5:24 ` [PATCH RESEND 16/16] regulator: add LM363X driver Milo Kim
2015-11-02 12:26 ` Mark Brown
2015-11-03 6:59 ` Kim, Milo
2015-11-04 13:59 ` Mark Brown
[not found] ` <20151104135911.GC1717-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-11-10 7:54 ` Kim, Milo
2015-11-02 9:00 ` [PATCH RESEND 00/16] Support TI LMU devices Lee Jones
2015-11-03 6:56 ` Kim, Milo
2015-11-03 8:35 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5641F4D3.7000800@samsung.com \
--to=j.anaszewski@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=milo.kim@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).