RE: [RFC 0/2] V4L2 API for exposing flash subdevs as LED class device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andrzej,

> -----Original Message-----
> From: linux-leds-owner@xxxxxxxxxxxxxxx [mailto:linux-leds-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Andrzej Hajda
> Sent: Monday, May 06, 2013 6:34 PM
> To: linux-media@xxxxxxxxxxxxxxx; linux-leds@xxxxxxxxxxxxxxx;
> devicetree-discuss@xxxxxxxxxxxxxxxx
> Cc: Laurent Pinchart; Sylwester Nawrocki; Sakari Ailus; Kyungmin Park;
> hj210.choi@xxxxxxxxxxx; sw0312.kim@xxxxxxxxxxx; Bryan Wu; Richard
> Purdie; Andrzej Hajda
> Subject: [RFC 0/2] V4L2 API for exposing flash subdevs as LED class
> device
> 
> This RFC proposes generic API for exposing flash subdevices via LED
> framework.
> 
> Rationale
> 
> Currently there are two frameworks which are used for exposing LED
> flash to
> user space:
> - V4L2 flash controls,
> - LED framework(with custom sysfs attributes).
> 
> The list below shows flash drivers in mainline kernel with initial
> commit date
> and typical chip application (according to producer):
> 
> LED API:
>     lm3642: 2012-09-12, Cameras
>     lm355x: 2012-09-05, Cameras
>     max8997: 2011-12-14, Cameras (?)
>     lp3944: 2009-06-19, Cameras, Lights, Indicators, Toys
>     pca955x: 2008-07-16, Cameras, Indicators (?)
> V4L2 API:
>     as3645a:  2011-05-05, Cameras
>     adp1653: 2011-05-05, Cameras
> 
> V4L2 provides richest functionality, but there is often demand from
> application
> developers to provide already established LED API.
> We would like to have an unified user interface for flash devices. Some
> of
> devices already have the LED API driver exposing limited set of a Flash
> IC
> functionality. In order to support all required features the LED API
> would
> have to be extended or the V4L2 API would need to be used. However when
> switching from a LED to a V4L2 Flash driver existing LED API interface
> would
> need to be retained.
> 
> Proposed solution
> 
> This patch adds V4L2 helper functions to register existing V4L2 flash
> subdev
> as LED class device.
> After registration via v4l2_leddev_register appropriate entry in
> /sys/class/leds/ is created.
> During registration all V4L2 flash controls are enumerated and
> corresponding
> attributes are added.
> 
> I have attached also patch with new max77693-led driver using
> v4l2_leddev.
> This patch requires presence of the patch "max77693: added device tree
> support":
> https://patchwork.kernel.org/patch/2414351/ .
> 
> Additional features
> 
> - simple API to access all V4L2 flash controls via sysfs,
> - V4L2 subdevice should not be registered by V4L2 device to use it,
> - LED triggers API can be used to control the device,
> - LED device is optional - it will be created only if V4L2_LEDDEV
> configuration
>   option is enabled and the subdev driver calls v4l2_leddev_register.
> 
> Doubts
> 
> This RFC is a result of a uncertainty which API developers should
> expose by
> their flash drivers. It is a try to gluing together both APIs.
> I am not sure if it is the best solution, but I hope there will be some
> discussion and hopefully some decisions will be taken which way we
> should follow.

The LED subsystem provides similar APIs for the Camera driver.
With LED trigger event, flash and torch are enabled/disabled.
I'm not sure this is applicable for you.
Could you take a look at LED camera trigger feature?

For the camera LED trigger,
https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=f
or-next&id=48a1d032c954b9b06c3adbf35ef4735dd70ab757

Example of camera flash driver,
https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=f
or-next&id=313bf0b1a0eaeaac17ea8c4b748f16e28fce8b7a

Thanks,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux