devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).