linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 18:21:08 +0100	[thread overview]
Message-ID: <568b079a-0a42-4eed-d2d7-12f0feef35e6@gmail.com> (raw)
In-Reply-To: <1832610.usQuhbGJ8B@g550jk>

On 3/8/20 5:55 PM, Luca Weiss wrote:
> Hi Jacek,
> 
> On Sonntag, 8. März 2020 17:47:17 CET Jacek Anaszewski wrote:
>> 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.
>>
> 
> I'll implement that then.
> 
>>> 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.
>>
> 
> I have already written some yesterday, will post them with my v1 :)

Good :-)

> 
>>> /* 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.
> 
> This is documented at 
> Documentation/devicetree/bindings/media/video-interfaces.txt:
> 
> - flash-leds: An array of phandles, each referring to a flash LED, a sub-node
>   of the LED driver device node.
> 
> Without referencing the flash device in a camera node, the v4l2 controls won't 
> even show up from what I saw.
> The binding is apparently only used in omap3-n9 and omap3-n950 currently; only 
> phones have flash leds normally and the phones that are currently in mainline 
> Linux don't have camera support yet.

I was rather thinking of mentioning this e.g. in
Documentation/devicetree/bindings/media/i2c/ov5640.txt in the form like
below (copied other occurrences thereof):

- flash-leds: See ../video-interfaces.txt

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2020-03-08 17:21 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
2020-03-08 16:55       ` Luca Weiss
2020-03-08 17:21         ` Jacek Anaszewski [this message]
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=568b079a-0a42-4eed-d2d7-12f0feef35e6@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).