linux-kernel - Re: [RFC PATCH] leds: add sgm3140 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1832610.usQuhbGJ8B@g550jk>
Date:   Sun, 08 Mar 2020 17:55:00 +0100
From:   Luca Weiss <luca@...tu.xyz>
To:     linux-leds@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     ~postmarketos/upstreaming@...ts.sr.ht, Pavel Machek <pavel@....cz>,
        Dan Murphy <dmurphy@...com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] leds: add sgm3140 driver

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@...tu.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 :)

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

Regards
Luca