From: Ingi Kim <ingi2.kim@samsung.com>
To: Jacek Anaszewski <j.anaszewski@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: Mon, 30 Nov 2015 11:31:44 +0900 [thread overview]
Message-ID: <565BB510.2040903@samsung.com> (raw)
In-Reply-To: <5656D43D.106@samsung.com>
Hi Jacek,
On 2015년 11월 26일 18:43, Jacek Anaszewski wrote:
> 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.
>
The brightness may be able to change its brightness in two separate LEDs case as you see.
So, I think it would be better to write brightness setting in strobe_op.
In consideration of delay, of course, the brightness is set just when it would be changed.
>>>> +
>>>> + 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.
>
The timeout may be able to change its flash timeout in two separate LEDs case as you see.
So, I think it would be better to write timeout setting in strobe_op.
In consideration of delay, of course, the timeout is set just when it would be changed.
> 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.
>
Thanks, but mutex protection is useless in this case.
so I try to remove it.
>>
>>>> +#define RT5033_FLED_CTRL4_VTRREG_MAX 0x60
>>>
>>> Rename DEF to MASK.
>
> Hmm, here it should be: Rename MAX to MASK.
>
Oh
Okay, Thanks :)
next prev parent reply other threads:[~2015-11-30 2:31 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
2015-11-30 2:31 ` Ingi Kim [this message]
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=565BB510.2040903@samsung.com \
--to=ingi2.kim@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=inki.dae@samsung.com \
--cc=j.anaszewski@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.