From: Luca Weiss <luca@z3ntu.xyz> To: linux-leds@vger.kernel.org, Jacek Anaszewski <jacek.anaszewski@gmail.com> 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, 08 Mar 2020 17:55:00 +0100 Message-ID: <1832610.usQuhbGJ8B@g550jk> (raw) In-Reply-To: <b58ddefc-b282-5a85-9dca-824e513705de@gmail.com> 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 :) > > /* 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
next prev parent reply index Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-27 18:50 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 [this message] 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=1832610.usQuhbGJ8B@g550jk \ --to=luca@z3ntu.xyz \ --cc=dmurphy@ti.com \ --cc=jacek.anaszewski@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git