All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Ingi Kim <ingi2.kim@samsung.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	sameo@linux.intel.com, lee.jones@linaro.org, rpurdie@rpsys.net,
	inki.dae@samsung.com, sw0312.kim@samsung.com,
	beomho.seo@samsung.com, andi.shyti@samsung.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-leds@vger.kernel.org
Subject: Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver
Date: Thu, 26 Nov 2015 10:43:25 +0100	[thread overview]
Message-ID: <5656D43D.106@samsung.com> (raw)
In-Reply-To: <5656BC88.2070603@samsung.com>

Hi Ingi,

On 11/26/2015 09:02 AM, Ingi Kim wrote:
[...]
>>> +torch_unlock:
>>> +    mutex_unlock(&led->lock);
>>> +    return ret;
>>> +}
>>> +
>>> +static int rt5033_led_flash_brightness_set(struct led_classdev_flash *fled_cdev,
>>> +                       u32 brightness)
>>> +{
>>> +    struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
>>> +    struct rt5033_led *led = sub_led_to_led(sub_led);
>>> +
>>> +    mutex_lock(&led->lock);
>>> +    sub_led->flash_brightness = brightness;
>>> +    mutex_unlock(&led->lock);
>>
>> Mutex protection is redundant in this case. You would need it if device
>> state was also changed here.
>
> Okay, I'll remove it.
>
>>
>> BTW why flash brightness can't be written to the device here?
>>
>
> Flash brightness is only affected when FLED flashed (strobing).
> So, I think it is better to be written in rt5033_led_flash_strobe_set function.

strobe_set op should strobe the flash ASAP, and delegating brightness
setting there extends a delay between calling strobe_set op
and actual flash strobe. If you set the brightness here, then you
wouldn't have to do that in the strobe_set op, of course unless the
the brightness is altered through the API of the other LED, in two
separate LEDs case.

>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int rt5033_led_flash_timeout_set(struct led_classdev_flash *fled_cdev,
>>> +                    u32 timeout)
>>> +{
>>> +    struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
>>> +    struct rt5033_led *led = sub_led_to_led(sub_led);
>>> +
>>> +    mutex_lock(&led->lock);
>>> +    sub_led->flash_timeout = timeout;
>>> +    mutex_unlock(&led->lock);
>>
>> Ditto.
>>

Timeout should be also written here.

If you will add regmap_write in both ops, then mutex protection will
have to be preserved, to assure consistency between registers state
and sub_led->flash_brightness and sub_led->flash_timeout state.

>
>>> +#define RT5033_FLED_CTRL4_VTRREG_MAX    0x60
>>
>> Rename DEF to MASK.

Hmm, here it should be: Rename MAX to MASK.

-- 
Best Regards,
Jacek Anaszewski

  parent reply	other threads:[~2015-11-26  9:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 10:22 [PATCH v6 0/2] Add RT5033 Flash LED driver Ingi Kim
2015-11-25 10:22 ` Ingi Kim
2015-11-25 10:22 ` [PATCH v6 1/2] leds: rt5033: Add DT binding for RT5033 Ingi Kim
2015-11-25 10:22 ` [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver Ingi Kim
2015-11-25 15:13   ` Jacek Anaszewski
2015-11-26  8:02     ` Ingi Kim
2015-11-26  9:12       ` Lee Jones
2015-11-26  9:43       ` Jacek Anaszewski [this message]
2015-11-30  2:31         ` Ingi Kim
2015-11-30 10:59           ` Jacek Anaszewski
2015-12-01  1:54             ` Ingi Kim
2015-12-01  7:55               ` Jacek Anaszewski
2015-11-26  9:11   ` Lee Jones
2015-11-30  2:35     ` Ingi Kim

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=5656D43D.106@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=andi.shyti@samsung.com \
    --cc=beomho.seo@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=ingi2.kim@samsung.com \
    --cc=inki.dae@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rpurdie@rpsys.net \
    --cc=sameo@linux.intel.com \
    --cc=sw0312.kim@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.