On 9/10/20 2:29 PM, Pavel Machek wrote:

Hi!

quoted

quoted

quoted

+{
+     struct mt6360_led *led = container_of(lcdev, struct mt6360_led, flash.led_cdev);
+     struct mt6360_priv *priv = led->priv;
+     u32 enable_mask = MT6360_TORCHEN_MASK | MT6360_FLCSEN_MASK(led->led_no);
+     u32 val = (level) ? MT6360_FLCSEN_MASK(led->led_no) : 0;
+     u32 prev = priv->fled_torch_used, curr;
+     int ret;
+
+     dev_dbg(lcdev->dev, "[%d] brightness %d\n", led->led_no, level);
+     if (priv->fled_strobe_used) {
+             dev_warn(lcdev->dev, "Please disable strobe first [%d]\n", priv->fled_strobe_used);
+             return -EINVAL;
+     }

So... how does its userland interface look like?

1. set FLED1 brightness
# echo 1 > /sys/class/leds/white:flash1/flash_brightness
2. enable FLED1 strobe
# echo 1 > /sys/class/leds/white:flash1/flash_strobe
3 . turn off FLED1 strobe (just used to gaurantee the strobe mode
flash leds must be turned off)
# echo 0 > /sys/class/leds/white:flash1/flash_strobe

I believe I'd preffer only exposing torch functionality in
/sys/class/leds. .. strobe can be supported using v4l2 APIs.

Actually having LED flash class without strobe is pointless.
If you looked at led_classdev_flash_register_ext() you would see that
it fails with uninitialized strobe_set op. And V4L2 API for strobing
flash calls strobe_set from LED flash class beneath.

That was the idea behind LED and V4L2 flash API unification - there
is one hardware driver needed, the V4L2 Flash layer just takes over
control over it when needed.

-- 
Best regards,
Jacek Anaszewski

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel