From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Luca Weiss <luca@z3ntu.xyz>, linux-leds@vger.kernel.org
Cc: ~postmarketos/upstreaming@lists.sr.ht,
Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] leds: add sgm3140 driver
Date: Sun, 8 Mar 2020 17:47:17 +0100 [thread overview]
Message-ID: <b58ddefc-b282-5a85-9dca-824e513705de@gmail.com> (raw)
In-Reply-To: <4539487.31r3eYUQgx@g550jk>
Hi Luca,
On 3/8/20 12:32 PM, Luca Weiss wrote:
> Hi Jacek,
>
> Thanks for your review! Replies are inline below.
>
> I'm wondering if I should implement support for the flash-max-timeout-us dt
> property ("Maximum timeout in microseconds after which the flash LED is turned
> off.") to configure the timeout to turn the flash off as I've currently hardcoded
> 250ms but this might not be ideal for all uses of the sgm3140. The datasheet
> states:
>
>> Flash mode is usually used with a pulse of about 200 to 300 milliseconds to
>> generate a high intensity Flash.
>
> so it might be useful to have this configurable in the devicetree. The value of
> 250ms works fine for my use case.
Yeah, I was to mentioned that.
>
> Theoretically also the .timeout_set op could be implemented but I'm not sure
> if this fits nicely into the existing "timeout" API and if it even makes sense
> to implement that.
Why wouldn't it fit? You can implement timeout_set op and cache flash
timeout value in it. Then that cached value would be passed in
strobe_set to mod_timer() in place of currently hard coded 250.
>
> Regards,
> Luca
>
> On Donnerstag, 5. März 2020 22:09:16 CET Jacek Anaszewski wrote:
>> Hi Luca,
>>
>> Thank you for the patch.
>>
>> On 2/27/20 7:50 PM, Luca Weiss wrote:
>>> Add a driver for the SGMICRO SGM3140 Buck/Boost Charge Pump LED driver.
>>>
>>> This device is controller by two GPIO lines, one for enabling the LED
>>> and the second one for switching between torch and flash mode.
>>>
>>> The device will automatically switch to torch mode after being in flash
>>> mode for about 250-300ms, so after that time the driver will turn the
>>> LED off again automatically.
>>>
>>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>>> ---
>>> Hi, this driver is controllable via sysfs and v4l2 APIs (as documented
>>> in Documentation/leds/leds-class-flash.rst).
>>>
>>> The following is possible:
>>>
>>> # Torch on
>>> echo 1 > /sys/class/leds/white\:flash/brightness
>>> # Torch off
>>> echo 0 > /sys/class/leds/white\:flash/brightness
>>> # Activate flash
>>> echo 1 > /sys/class/leds/white\:flash/flash_strobe
>>>
>>> # Torch on
>>> v4l2-ctl -d /dev/video1 -c led_mode=2
>>> # Torch off
>>> v4l2-ctl -d /dev/video1 -c led_mode=0
>>> # Activate flash
>>> v4l2-ctl -d /dev/video1 -c strobe=1
>>
>> What is /dev/video1 ? Did you register vl42 flash subdev
>> in some v4l2 media controller device?
>
> On the Allwinner A64 SoC /dev/video0 is the node for cedrus (video encoder/
> decoder), so the sun6i-csi driver gets to be /dev/video1
>
> # v4l2-ctl --list-devices
> cedrus (platform:cedrus):
> /dev/video0
> /dev/media0
>
> sun6i-csi (platform:csi):
> /dev/video1
>
> Allwinner Video Capture Device (platform:sun6i-csi):
> /dev/media1
>
>
> Here's the relevant part from my dts:
>
> sgm3140 {
> compatible = "sgmicro,sgm3140";
> flash-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* FLASH_TRIGOUT: PD24 */
> enable-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* FLASH_EN: PC3 */
>
> sgm3140_flash: led {
> function = LED_FUNCTION_FLASH;
> color = <LED_COLOR_ID_WHITE>;
> };
> };
This needs to be documented in DT bindings for this driver.
> /* as subnode of csi (compatible: allwinner,sun50i-a64-csi) */
> ov5640: rear-camera@4c {
> compatible = "ovti,ov5640";
> <snip>
> flash-leds = <&sgm3140_flash>;
> };
And this in camera bindings.
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2020-03-08 16:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 18:50 [RFC PATCH] leds: add sgm3140 driver Luca Weiss
2020-02-27 19:50 ` Dan Murphy
2020-03-05 11:01 ` Luca Weiss
2020-03-05 12:54 ` Dan Murphy
2020-03-05 21:09 ` Jacek Anaszewski
2020-03-08 11:32 ` Luca Weiss
2020-03-08 16:47 ` Jacek Anaszewski [this message]
2020-03-08 16:55 ` Luca Weiss
2020-03-08 17:21 ` Jacek Anaszewski
2020-03-08 12:08 ` Pavel Machek
2020-03-08 12:31 ` Luca Weiss
2020-03-08 17:07 ` Jacek Anaszewski
2020-03-08 12:11 ` Pavel Machek
2020-03-08 12:37 ` Luca Weiss
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=b58ddefc-b282-5a85-9dca-824e513705de@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=luca@z3ntu.xyz \
--cc=pavel@ucw.cz \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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).