Re: V2: Agenda for the Edinburgh mini-summit

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

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 #2: Type: application/pgp-signature, Size: 836 bytes --]