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-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
