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