Resending using Bryan's correct email address. On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: > On 09/23/2013 06:37 PM, Oliver Schinagl wrote: > >On 09/23/13 16:45, Sylwester Nawrocki wrote: > >>Hi, > >> > >>I would like to have a short discussion on LED flash devices support > >>in the kernel. Currently there are two APIs: the V4L2 and LED class > >>API exposed by the kernel, which I believe is not good from user space > >>POV. Generic applications will need to implement both APIs. I think we > >>should decide whether to extend the led class API to add support for > >>more advanced LED controllers there or continue to use the both APIs > >>with overlapping functionality. > >>There has been some discussion about this on the ML, but without any > >>consensus reached [1]. > > > >What about the linux-pwm framework and its support for the backlight via > >dts? > > > >Or am I talking way to uninformed here. Copying backlight to flashlight > >with some minor modification sounds sensible in a way... > > I'd assume we don't need yet another user interface for the LEDs ;) AFAICS > the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED > controllers are already handled in the leds-class API, there is the > leds_pwm > driver (drivers/leds/leds-pwm.c). > > I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct > me if I got anything wrong. The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm). The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing. > Presumably, what we need is a few enhancements to support in a standard way > devices like MAX77693, LM3560 or MAX8997. There is already a led > class driver > for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it > uses some > device-specific sysfs attributes. > > Thus similar devices are currently being handled by different subsystems. > The split between the V4L2 Flash and the leds class API WRT to Flash LED > controller drivers is included in RFC [1], it seems still up to date. > > > >>[1] http://www.spinics.net/lists/linux-leds/msg00899.html Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added. If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that. Thierry
Attachment:
pgpnzhAVCmYaf.pgp
Description: PGP signature
