Re: V2: Agenda for the Edinburgh mini-summit

Re: V2: Agenda for the Edinburgh mini-summit

[Sylwester Nawrocki]

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.

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

--
Thanks,
Sylwester

Re: V2: Agenda for the Edinburgh mini-summit

[Thierry Reding]

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

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 --]

Re: V2: Agenda for the Edinburgh mini-summit

[Sakari Ailus]

Hi Thierry and Sylwester,

My apologies for the late answer.

On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
> 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.

The V4L2 flash API supports also xenon flashes, not only LED ones. That
said, I agree there's a common subset of functionality most LED flash
controllers implement.

> 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.

I originally thought one way to do this could be to make it as easy as
possible to support both APIs in driver which some aregued, to which I
agree, is rather poor desing.

Does the LED API have a user space interface library like libv4l2? If yes,
one option oculd be to implement the wrapper between the V4L2 and LED APIs
there so that the applications using the LED API could also access those
devices that implement the V4L2 flash API. Torch mode functionality is
common between the two right now AFAIU,

The V4L2 flash API also provides a way to strobe the flash using an external
trigger which typically connected to the sensor (and the user can choose
between that and software strobe). I guess that and Xenon flashes aren't
currently covered by the LED API.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Laurent Pinchart]

Hi Sakari,

On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
> > 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.
> 
> The V4L2 flash API supports also xenon flashes, not only LED ones. That
> said, I agree there's a common subset of functionality most LED flash
> controllers implement.
> 
> > 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.
> 
> I originally thought one way to do this could be to make it as easy as
> possible to support both APIs in driver which some aregued, to which I
> agree, is rather poor desing.
> 
> Does the LED API have a user space interface library like libv4l2? If yes,
> one option oculd be to implement the wrapper between the V4L2 and LED APIs
> there so that the applications using the LED API could also access those
> devices that implement the V4L2 flash API. Torch mode functionality is
> common between the two right now AFAIU,
> 
> The V4L2 flash API also provides a way to strobe the flash using an external
> trigger which typically connected to the sensor (and the user can choose
> between that and software strobe). I guess that and Xenon flashes aren't
> currently covered by the LED API.

The issue is that we have a LED API targetted at controlling LEDs, a V4L2 
flash API targetted at controlling flashes, and hardware devices somewhere in 
the middle that can be used to provide LED or flash function. Merging the two 
APIs on the kernel side, with a compatibility layer for both kernel space and 
user space APIs, might be an idea worth investigating.

-- 
Regards,

Laurent Pinchart

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Sakari,
>
> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>> > 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.
>>
>> The V4L2 flash API supports also xenon flashes, not only LED ones. That
>> said, I agree there's a common subset of functionality most LED flash
>> controllers implement.
>>
>> > 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.
>>
>> I originally thought one way to do this could be to make it as easy as
>> possible to support both APIs in driver which some aregued, to which I
>> agree, is rather poor desing.
>>
>> Does the LED API have a user space interface library like libv4l2? If yes,
>> one option oculd be to implement the wrapper between the V4L2 and LED APIs
>> there so that the applications using the LED API could also access those
>> devices that implement the V4L2 flash API. Torch mode functionality is
>> common between the two right now AFAIU,
>>
>> The V4L2 flash API also provides a way to strobe the flash using an external
>> trigger which typically connected to the sensor (and the user can choose
>> between that and software strobe). I guess that and Xenon flashes aren't
>> currently covered by the LED API.
>
> The issue is that we have a LED API targetted at controlling LEDs, a V4L2
> flash API targetted at controlling flashes, and hardware devices somewhere in
> the middle that can be used to provide LED or flash function. Merging the two
> APIs on the kernel side, with a compatibility layer for both kernel space and
> user space APIs, might be an idea worth investigating.
>

I'm so sorry for jumping in the discussion so late. Some how the
emails from linux-media was archived in my Gmail and I haven't
checkout this for several weeks.

I agree right now LED API doesn't  quite fit for the usage of V4L2
Flash API. But I'd also like to see a unified API.

Currently, LED API are exported to user space as sysfs interface,
while V4L2 Flash APIs are like IOCTL and user space library. We also
merged some LED Flash trigger into LED subsystem. My basic idea is
what about creating or expanding the LED Flash trigger driver and
provide a well defined sysfs interface, which can be wrapped into user
space libv4l2.

Thanks,
-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Laurent Pinchart]

Hi Bryan,

On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
> > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
> >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
> >> > 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.
> >> 
> >> The V4L2 flash API supports also xenon flashes, not only LED ones. That
> >> said, I agree there's a common subset of functionality most LED flash
> >> controllers implement.
> >> 
> >> > 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.
> >> 
> >> I originally thought one way to do this could be to make it as easy as
> >> possible to support both APIs in driver which some aregued, to which I
> >> agree, is rather poor desing.
> >> 
> >> Does the LED API have a user space interface library like libv4l2? If
> >> yes, one option oculd be to implement the wrapper between the V4L2 and
> >> LED APIs there so that the applications using the LED API could also
> >> access those devices that implement the V4L2 flash API. Torch mode
> >> functionality is common between the two right now AFAIU,
> >> 
> >> The V4L2 flash API also provides a way to strobe the flash using an
> >> external trigger which typically connected to the sensor (and the user
> >> can choose between that and software strobe). I guess that and Xenon
> >> flashes aren't currently covered by the LED API.
> > 
> > The issue is that we have a LED API targetted at controlling LEDs, a V4L2
> > flash API targetted at controlling flashes, and hardware devices somewhere
> > in the middle that can be used to provide LED or flash function. Merging
> > the two APIs on the kernel side, with a compatibility layer for both
> > kernel space and user space APIs, might be an idea worth investigating.
> 
> I'm so sorry for jumping in the discussion so late. Some how the
> emails from linux-media was archived in my Gmail and I haven't
> checkout this for several weeks.
> 
> I agree right now LED API doesn't  quite fit for the usage of V4L2
> Flash API. But I'd also like to see a unified API.
> 
> Currently, LED API are exported to user space as sysfs interface,
> while V4L2 Flash APIs are like IOCTL and user space library. We also
> merged some LED Flash trigger into LED subsystem. My basic idea is
> what about creating or expanding the LED Flash trigger driver and
> provide a well defined sysfs interface, which can be wrapped into user
> space libv4l2.

The biggest reason why we're not fond of sysfs-based APIs for media devices is 
that they can't provide atomicity. There's no way to set multiple parameters 
in a single operation.

We can't get rid of the sysfs LEDs API, but maybe we could have a unified 
kernel LED/flash subsystem that would provide both a sysfs-based API to ensure 
compatibility with current userspace software and an ioctl-based API (possibly 
through V4L2 controls). That way LED/flash devices would be registered with a 
single subsystem, and the corresponding drivers won't have to care about the 
API exposed to userspace. That would require a major refactoring of the in-
kernel APIs though.

-- 
Regards,

Laurent Pinchart

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Bryan,
>
> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>> > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>> >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>> >> > 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.
>> >>
>> >> The V4L2 flash API supports also xenon flashes, not only LED ones. That
>> >> said, I agree there's a common subset of functionality most LED flash
>> >> controllers implement.
>> >>
>> >> > 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.
>> >>
>> >> I originally thought one way to do this could be to make it as easy as
>> >> possible to support both APIs in driver which some aregued, to which I
>> >> agree, is rather poor desing.
>> >>
>> >> Does the LED API have a user space interface library like libv4l2? If
>> >> yes, one option oculd be to implement the wrapper between the V4L2 and
>> >> LED APIs there so that the applications using the LED API could also
>> >> access those devices that implement the V4L2 flash API. Torch mode
>> >> functionality is common between the two right now AFAIU,
>> >>
>> >> The V4L2 flash API also provides a way to strobe the flash using an
>> >> external trigger which typically connected to the sensor (and the user
>> >> can choose between that and software strobe). I guess that and Xenon
>> >> flashes aren't currently covered by the LED API.
>> >
>> > The issue is that we have a LED API targetted at controlling LEDs, a V4L2
>> > flash API targetted at controlling flashes, and hardware devices somewhere
>> > in the middle that can be used to provide LED or flash function. Merging
>> > the two APIs on the kernel side, with a compatibility layer for both
>> > kernel space and user space APIs, might be an idea worth investigating.
>>
>> I'm so sorry for jumping in the discussion so late. Some how the
>> emails from linux-media was archived in my Gmail and I haven't
>> checkout this for several weeks.
>>
>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>> Flash API. But I'd also like to see a unified API.
>>
>> Currently, LED API are exported to user space as sysfs interface,
>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>> merged some LED Flash trigger into LED subsystem. My basic idea is
>> what about creating or expanding the LED Flash trigger driver and
>> provide a well defined sysfs interface, which can be wrapped into user
>> space libv4l2.
>
> The biggest reason why we're not fond of sysfs-based APIs for media devices is
> that they can't provide atomicity. There's no way to set multiple parameters
> in a single operation.
>
> We can't get rid of the sysfs LEDs API, but maybe we could have a unified
> kernel LED/flash subsystem that would provide both a sysfs-based API to ensure
> compatibility with current userspace software and an ioctl-based API (possibly
> through V4L2 controls). That way LED/flash devices would be registered with a
> single subsystem, and the corresponding drivers won't have to care about the
> API exposed to userspace. That would require a major refactoring of the in-
> kernel APIs though.
>

I agree this. I'm thinking about expanding the ledtrig-camera.c
created by Milo Kim. This trigger will provide flashing and strobing
control of a LED device and for sure the LED device driver like
drivers/leds/leds-lm355x.c.

So we basically can do this:
1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to
userspace.
2. add the real flash torch functions into LED device driver like
leds-lm355x.c, this driver will still provide sysfs interface and
extended flash/torch control sysfs interface as well.

I'm not sure about whether we need some change in V4L2 internally. But
actually Andrzej Hajda's patchset is quite straightforward, but we
just need put those V4L2 Flash API into a LED trigger driver and the
real flash/torch operation in a LED device driver.

Milo, could you please give some comments here?

Thanks,
-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Laurent Pinchart]

Hi Bryan,

On Tuesday 15 October 2013 11:37:23 Bryan Wu wrote:
> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart wrote:
> > On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
> >> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
> >> > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
> >> >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
> >> >> > 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.
> >> >> 
> >> >> The V4L2 flash API supports also xenon flashes, not only LED ones.
> >> >> That said, I agree there's a common subset of functionality most LED
> >> >> flash controllers implement.
> >> >> 
> >> >> > 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.
> >> >> 
> >> >> I originally thought one way to do this could be to make it as easy as
> >> >> possible to support both APIs in driver which some aregued, to which I
> >> >> agree, is rather poor desing.
> >> >> 
> >> >> Does the LED API have a user space interface library like libv4l2? If
> >> >> yes, one option oculd be to implement the wrapper between the V4L2 and
> >> >> LED APIs there so that the applications using the LED API could also
> >> >> access those devices that implement the V4L2 flash API. Torch mode
> >> >> functionality is common between the two right now AFAIU,
> >> >> 
> >> >> The V4L2 flash API also provides a way to strobe the flash using an
> >> >> external trigger which typically connected to the sensor (and the user
> >> >> can choose between that and software strobe). I guess that and Xenon
> >> >> flashes aren't currently covered by the LED API.
> >> > 
> >> > The issue is that we have a LED API targetted at controlling LEDs, a
> >> > V4L2 flash API targetted at controlling flashes, and hardware devices
> >> > somewhere in the middle that can be used to provide LED or flash
> >> > function. Merging the two APIs on the kernel side, with a compatibility
> >> > layer for both kernel space and user space APIs, might be an idea worth
> >> > investigating.
> >> 
> >> I'm so sorry for jumping in the discussion so late. Some how the
> >> emails from linux-media was archived in my Gmail and I haven't
> >> checkout this for several weeks.
> >> 
> >> I agree right now LED API doesn't  quite fit for the usage of V4L2
> >> Flash API. But I'd also like to see a unified API.
> >> 
> >> Currently, LED API are exported to user space as sysfs interface,
> >> while V4L2 Flash APIs are like IOCTL and user space library. We also
> >> merged some LED Flash trigger into LED subsystem. My basic idea is
> >> what about creating or expanding the LED Flash trigger driver and
> >> provide a well defined sysfs interface, which can be wrapped into user
> >> space libv4l2.
> > 
> > The biggest reason why we're not fond of sysfs-based APIs for media
> > devices is that they can't provide atomicity. There's no way to set
> > multiple parameters in a single operation.
> > 
> > We can't get rid of the sysfs LEDs API, but maybe we could have a unified
> > kernel LED/flash subsystem that would provide both a sysfs-based API to
> > ensure compatibility with current userspace software and an ioctl-based
> > API (possibly through V4L2 controls). That way LED/flash devices would be
> > registered with a single subsystem, and the corresponding drivers won't
> > have to care about the API exposed to userspace. That would require a
> > major refactoring of the in- kernel APIs though.
> 
> I agree this. I'm thinking about expanding the ledtrig-camera.c
> created by Milo Kim. This trigger will provide flashing and strobing
> control of a LED device and for sure the LED device driver like
> drivers/leds/leds-lm355x.c.
> 
> So we basically can do this:
> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
> can provide trigger API to kernel drivers as well as V4L2 Flash API to
> userspace.
> 2. add the real flash torch functions into LED device driver like
> leds-lm355x.c, this driver will still provide sysfs interface and
> extended flash/torch control sysfs interface as well.
> 
> I'm not sure about whether we need some change in V4L2 internally. But
> actually Andrzej Hajda's patchset is quite straightforward, but we
> just need put those V4L2 Flash API into a LED trigger driver and the
> real flash/torch operation in a LED device driver.

I believe we should look at both ends of the problem and then try to draft an 
architecture for what goes between, based on what we already have. Those two 
ends are the LED controller chips on one side, and the application needs on 
the other side.

Regarding applications, I believe the needs have been captured by our current 
userspace APIs (LED sysfs API, triggers, and V4L2 flash API). Regarding the 
hardware, please have a look at the ADP1653 and AS3645A/LM3555. They're both 
pretty complex chips, and most of their features need to be exposed. Let's 
keep in mind that there can be pretty complex dependencies between the flash 
and torch features.

Would you be interesting in writing an architecture proposal ?

Do you plan to attend KS/ELC-E next week ?

> Milo, could you please give some comments here?

-- 
Regards,

Laurent Pinchart

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Tue, Oct 15, 2013 at 11:50 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Bryan,
>
> On Tuesday 15 October 2013 11:37:23 Bryan Wu wrote:
>> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart wrote:
>> > On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>> >> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>> >> > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>> >> >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>> >> >> > 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.
>> >> >>
>> >> >> The V4L2 flash API supports also xenon flashes, not only LED ones.
>> >> >> That said, I agree there's a common subset of functionality most LED
>> >> >> flash controllers implement.
>> >> >>
>> >> >> > 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.
>> >> >>
>> >> >> I originally thought one way to do this could be to make it as easy as
>> >> >> possible to support both APIs in driver which some aregued, to which I
>> >> >> agree, is rather poor desing.
>> >> >>
>> >> >> Does the LED API have a user space interface library like libv4l2? If
>> >> >> yes, one option oculd be to implement the wrapper between the V4L2 and
>> >> >> LED APIs there so that the applications using the LED API could also
>> >> >> access those devices that implement the V4L2 flash API. Torch mode
>> >> >> functionality is common between the two right now AFAIU,
>> >> >>
>> >> >> The V4L2 flash API also provides a way to strobe the flash using an
>> >> >> external trigger which typically connected to the sensor (and the user
>> >> >> can choose between that and software strobe). I guess that and Xenon
>> >> >> flashes aren't currently covered by the LED API.
>> >> >
>> >> > The issue is that we have a LED API targetted at controlling LEDs, a
>> >> > V4L2 flash API targetted at controlling flashes, and hardware devices
>> >> > somewhere in the middle that can be used to provide LED or flash
>> >> > function. Merging the two APIs on the kernel side, with a compatibility
>> >> > layer for both kernel space and user space APIs, might be an idea worth
>> >> > investigating.
>> >>
>> >> I'm so sorry for jumping in the discussion so late. Some how the
>> >> emails from linux-media was archived in my Gmail and I haven't
>> >> checkout this for several weeks.
>> >>
>> >> I agree right now LED API doesn't  quite fit for the usage of V4L2
>> >> Flash API. But I'd also like to see a unified API.
>> >>
>> >> Currently, LED API are exported to user space as sysfs interface,
>> >> while V4L2 Flash APIs are like IOCTL and user space library. We also
>> >> merged some LED Flash trigger into LED subsystem. My basic idea is
>> >> what about creating or expanding the LED Flash trigger driver and
>> >> provide a well defined sysfs interface, which can be wrapped into user
>> >> space libv4l2.
>> >
>> > The biggest reason why we're not fond of sysfs-based APIs for media
>> > devices is that they can't provide atomicity. There's no way to set
>> > multiple parameters in a single operation.
>> >
>> > We can't get rid of the sysfs LEDs API, but maybe we could have a unified
>> > kernel LED/flash subsystem that would provide both a sysfs-based API to
>> > ensure compatibility with current userspace software and an ioctl-based
>> > API (possibly through V4L2 controls). That way LED/flash devices would be
>> > registered with a single subsystem, and the corresponding drivers won't
>> > have to care about the API exposed to userspace. That would require a
>> > major refactoring of the in- kernel APIs though.
>>
>> I agree this. I'm thinking about expanding the ledtrig-camera.c
>> created by Milo Kim. This trigger will provide flashing and strobing
>> control of a LED device and for sure the LED device driver like
>> drivers/leds/leds-lm355x.c.
>>
>> So we basically can do this:
>> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
>> can provide trigger API to kernel drivers as well as V4L2 Flash API to
>> userspace.
>> 2. add the real flash torch functions into LED device driver like
>> leds-lm355x.c, this driver will still provide sysfs interface and
>> extended flash/torch control sysfs interface as well.
>>
>> I'm not sure about whether we need some change in V4L2 internally. But
>> actually Andrzej Hajda's patchset is quite straightforward, but we
>> just need put those V4L2 Flash API into a LED trigger driver and the
>> real flash/torch operation in a LED device driver.
>
> I believe we should look at both ends of the problem and then try to draft an
> architecture for what goes between, based on what we already have. Those two
> ends are the LED controller chips on one side, and the application needs on
> the other side.
>

Sound good to me. I will take a look in detail about the architecture.

> Regarding applications, I believe the needs have been captured by our current
> userspace APIs (LED sysfs API, triggers, and V4L2 flash API). Regarding the
> hardware, please have a look at the ADP1653 and AS3645A/LM3555. They're both
> pretty complex chips, and most of their features need to be exposed. Let's
> keep in mind that there can be pretty complex dependencies between the flash
> and torch features.
>

Actually recently I'm also working V4L2 SoC camera controller driver
for Tegra. We are using some similar LED/Flash chip you mentioned.

> Would you be interesting in writing an architecture proposal ?
>

Sure, I will do this. And probably post it our before the KS/ELC-E,
then you guys can discuss it during the mini-summit.

> Do you plan to attend KS/ELC-E next week ?
>

Unfortunately I won't, but I might ask some colleagues to present.

Thanks,
-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Sylwester Nawrocki]

On 10/15/2013 08:37 PM, Bryan Wu wrote:
> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
>> > <laurent.pinchart@ideasonboard.com>  wrote:
[...]
>> >  The biggest reason why we're not fond of sysfs-based APIs for media devices is
>> >  that they can't provide atomicity. There's no way to set multiple parameters
>> >  in a single operation.

I wonder what are your concerns WRT atomicity about usage of flash 
devices in
camera subsystems ? Is atomicity really so important here ? I don't 
disagree with
this argument, but I'm curious if you had any specific use cases in mind ?

>> >  We can't get rid of the sysfs LEDs API, but maybe we could have a unified
>> >  kernel LED/flash subsystem that would provide both a sysfs-based API to ensure

One of my original concerns were that same chip (often a multi-function 
device)
can be used as a camera Flash or an ordinary LED indicator. It depends 
on physical
system a chip is deployed, LED current configured, etc. So it appears 
bad from
design POV to have different drivers for different purposes of same device.

I believe led API should be a lower level layer, so each LED can be used as
a simple indicator.

>> >  compatibility with current userspace software and an ioctl-based API (possibly
>> >  through V4L2 controls). That way LED/flash devices would be registered with a
>> >  single subsystem, and the corresponding drivers won't have to care about the
>> >  API exposed to userspace. That would require a major refactoring of the in-
>> >  kernel APIs though.
>> >
>
> I agree this. I'm thinking about expanding the ledtrig-camera.c
> created by Milo Kim. This trigger will provide flashing and strobing
> control of a LED device and for sure the LED device driver like
> drivers/leds/leds-lm355x.c.
>
> So we basically can do this:
> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
> can provide trigger API to kernel drivers as well as V4L2 Flash API to
> userspace.

That sounds reasonable to me, I guess this could be a kernel config option,
so one can disable dependency on videodev module and the like at the LED
module if V4L2 flash API is not needed.

> 2. add the real flash torch functions into LED device driver like
> leds-lm355x.c, this driver will still provide sysfs interface and
> extended flash/torch control sysfs interface as well.

+1

> I'm not sure about whether we need some change in V4L2 internally. But
> actually Andrzej Hajda's patchset is quite straightforward, but we
> just need put those V4L2 Flash API into a LED trigger driver and the
> real flash/torch operation in a LED device driver.

I guess some changes will be needed at both subsystems, but these are
details. Such high level design sounds good to me.

Sorry for not replying earlier in this thread, have been busy and
travelling for last two weeks.

--
Thanks,
Sylwester

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Milo Kim]

Hi Bryan,

On 10/16/2013 03:37 AM, Bryan Wu wrote:
> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> Hi Bryan,
>>
>> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>>>> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>>>>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>>>>>> 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.
>>>>>
>>>>> The V4L2 flash API supports also xenon flashes, not only LED ones. That
>>>>> said, I agree there's a common subset of functionality most LED flash
>>>>> controllers implement.
>>>>>
>>>>>> 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.
>>>>>
>>>>> I originally thought one way to do this could be to make it as easy as
>>>>> possible to support both APIs in driver which some aregued, to which I
>>>>> agree, is rather poor desing.
>>>>>
>>>>> Does the LED API have a user space interface library like libv4l2? If
>>>>> yes, one option oculd be to implement the wrapper between the V4L2 and
>>>>> LED APIs there so that the applications using the LED API could also
>>>>> access those devices that implement the V4L2 flash API. Torch mode
>>>>> functionality is common between the two right now AFAIU,
>>>>>
>>>>> The V4L2 flash API also provides a way to strobe the flash using an
>>>>> external trigger which typically connected to the sensor (and the user
>>>>> can choose between that and software strobe). I guess that and Xenon
>>>>> flashes aren't currently covered by the LED API.
>>>>
>>>> The issue is that we have a LED API targetted at controlling LEDs, a V4L2
>>>> flash API targetted at controlling flashes, and hardware devices somewhere
>>>> in the middle that can be used to provide LED or flash function. Merging
>>>> the two APIs on the kernel side, with a compatibility layer for both
>>>> kernel space and user space APIs, might be an idea worth investigating.
>>>
>>> I'm so sorry for jumping in the discussion so late. Some how the
>>> emails from linux-media was archived in my Gmail and I haven't
>>> checkout this for several weeks.
>>>
>>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>>> Flash API. But I'd also like to see a unified API.
>>>
>>> Currently, LED API are exported to user space as sysfs interface,
>>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>>> merged some LED Flash trigger into LED subsystem. My basic idea is
>>> what about creating or expanding the LED Flash trigger driver and
>>> provide a well defined sysfs interface, which can be wrapped into user
>>> space libv4l2.
>>
>> The biggest reason why we're not fond of sysfs-based APIs for media devices is
>> that they can't provide atomicity. There's no way to set multiple parameters
>> in a single operation.
>>
>> We can't get rid of the sysfs LEDs API, but maybe we could have a unified
>> kernel LED/flash subsystem that would provide both a sysfs-based API to ensure
>> compatibility with current userspace software and an ioctl-based API (possibly
>> through V4L2 controls). That way LED/flash devices would be registered with a
>> single subsystem, and the corresponding drivers won't have to care about the
>> API exposed to userspace. That would require a major refactoring of the in-
>> kernel APIs though.
>>
>
> I agree this. I'm thinking about expanding the ledtrig-camera.c
> created by Milo Kim. This trigger will provide flashing and strobing
> control of a LED device and for sure the LED device driver like
> drivers/leds/leds-lm355x.c.
>
> So we basically can do this:
> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
> can provide trigger API to kernel drivers as well as V4L2 Flash API to
> userspace.
> 2. add the real flash torch functions into LED device driver like
> leds-lm355x.c, this driver will still provide sysfs interface and
> extended flash/torch control sysfs interface as well.
>
> I'm not sure about whether we need some change in V4L2 internally. But
> actually Andrzej Hajda's patchset is quite straightforward, but we
> just need put those V4L2 Flash API into a LED trigger driver and the
> real flash/torch operation in a LED device driver.
>
> Milo, could you please give some comments here?

General LED trigger APIs were created not for the application interface 
but for any kernel space driver.
The LED camera trigger APIs are used by a camera driver, not application.

Some LED devices provide basic LED functionalities and high current 
features like a flash and a torch.(eg. LM3554, LM3642)
The reason why I added the LED camera trigger is
   "for providing multiple operations(LEDs, flash and torch) by one LED 
device driver".

For example,
A LED indicator is controlled via the LED sysfs.
And flash and torch are controlled by a camera driver - calls exported 
LED trigger function, ledtrig_flash_ctrl().

My understanding is the V4L2 subsystem provides rich IOCTLs for the 
media device.
I agree that the V4L2 is more proper interface for camera *application*.

So, my suggestion is:
   - If a device has only flash/torch functionalities, then register the 
driver as the V4L2 sub-device.
   - If a device provides not only flash/torch but also LED features, 
then create the driver as the MFD.

For example, LM3555 (and AS3645A) is used only for the camera.
Then, this driver is registered as the V4L2 sub-device.
(drivers/media/i2c/as3645a.c) - no change at all.

On the other hands, LM3642 has an indicator mode with flash/torch.
Then, it will consist of 3 parts - MFD core, LED(indicator) and 
V4L2(flash/torch).

Then, ledtrig-camera will be removed after we complete to change the 
driver structure.

Best regards,
Milo

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Sylwester Nawrocki]

Hi,

On 16/10/13 03:49, Milo Kim wrote:
> General LED trigger APIs were created not for the application interface 
> but for any kernel space driver.
> The LED camera trigger APIs are used by a camera driver, not application.
> 
> Some LED devices provide basic LED functionalities and high current 
> features like a flash and a torch.(eg. LM3554, LM3642)
> The reason why I added the LED camera trigger is
>    "for providing multiple operations(LEDs, flash and torch) by one LED 
> device driver".
> 
> For example,
> A LED indicator is controlled via the LED sysfs.
> And flash and torch are controlled by a camera driver - calls exported 
> LED trigger function, ledtrig_flash_ctrl().
> 
> My understanding is the V4L2 subsystem provides rich IOCTLs for the 
> media device.
> I agree that the V4L2 is more proper interface for camera *application*.
> 
> So, my suggestion is:
>    - If a device has only flash/torch functionalities, then register the 
> driver as the V4L2 sub-device.

Presumably it's not something we want. I think a core module is needed
so drivers can expose both sysfs LED API and V4L2 Flash API with minimal
effort for a single device. Then LED API would be extended with standard
attributes for Torch/Flash and user applications can use either sysfs
or V4L2 subdev/controls API. No need to worry that for some of the devices
the kernel will expose only the sysfs and for some only the V4L2 interface.

Also for some multifunction devices integrating features like PMIC,
clock generator, Flash/Torch LED driver, etc. the LED might be used for
different purpose than originally intended. E.g. Torch LED as an
indicator. So it is not correct IMO to select a specific API based on
device's primary purpose only. I think there should be more flexibility.

>    - If a device provides not only flash/torch but also LED features, 
> then create the driver as the MFD.
> 
> For example, LM3555 (and AS3645A) is used only for the camera.
> Then, this driver is registered as the V4L2 sub-device.
> (drivers/media/i2c/as3645a.c) - no change at all.
> 
> On the other hands, LM3642 has an indicator mode with flash/torch.
> Then, it will consist of 3 parts - MFD core, LED(indicator) and 
> V4L2(flash/torch).
> 
> Then, ledtrig-camera will be removed after we complete to change the 
> driver structure.

I'm not sure it needs to be removed. We will still have hardware and
software triggered Flash LEDs. What would provide ledtrig-camera's
current functionality when you remove it ?

--
Regards,
Sylwester

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim <milo.kim@ti.com> wrote:
> Hi Bryan,
>
>
> On 10/16/2013 03:37 AM, Bryan Wu wrote:
>>
>> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>>>
>>> Hi Bryan,
>>>
>>> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>>>>
>>>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>>>>>
>>>>> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>>>>>>
>>>>>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> The V4L2 flash API supports also xenon flashes, not only LED ones.
>>>>>> That
>>>>>> said, I agree there's a common subset of functionality most LED flash
>>>>>> controllers implement.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> I originally thought one way to do this could be to make it as easy as
>>>>>> possible to support both APIs in driver which some aregued, to which I
>>>>>> agree, is rather poor desing.
>>>>>>
>>>>>> Does the LED API have a user space interface library like libv4l2? If
>>>>>> yes, one option oculd be to implement the wrapper between the V4L2 and
>>>>>> LED APIs there so that the applications using the LED API could also
>>>>>> access those devices that implement the V4L2 flash API. Torch mode
>>>>>> functionality is common between the two right now AFAIU,
>>>>>>
>>>>>> The V4L2 flash API also provides a way to strobe the flash using an
>>>>>> external trigger which typically connected to the sensor (and the user
>>>>>> can choose between that and software strobe). I guess that and Xenon
>>>>>> flashes aren't currently covered by the LED API.
>>>>>
>>>>>
>>>>> The issue is that we have a LED API targetted at controlling LEDs, a
>>>>> V4L2
>>>>> flash API targetted at controlling flashes, and hardware devices
>>>>> somewhere
>>>>> in the middle that can be used to provide LED or flash function.
>>>>> Merging
>>>>> the two APIs on the kernel side, with a compatibility layer for both
>>>>> kernel space and user space APIs, might be an idea worth investigating.
>>>>
>>>>
>>>> I'm so sorry for jumping in the discussion so late. Some how the
>>>> emails from linux-media was archived in my Gmail and I haven't
>>>> checkout this for several weeks.
>>>>
>>>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>>>> Flash API. But I'd also like to see a unified API.
>>>>
>>>> Currently, LED API are exported to user space as sysfs interface,
>>>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>>>> merged some LED Flash trigger into LED subsystem. My basic idea is
>>>> what about creating or expanding the LED Flash trigger driver and
>>>> provide a well defined sysfs interface, which can be wrapped into user
>>>> space libv4l2.
>>>
>>>
>>> The biggest reason why we're not fond of sysfs-based APIs for media
>>> devices is
>>> that they can't provide atomicity. There's no way to set multiple
>>> parameters
>>> in a single operation.
>>>
>>> We can't get rid of the sysfs LEDs API, but maybe we could have a unified
>>> kernel LED/flash subsystem that would provide both a sysfs-based API to
>>> ensure
>>> compatibility with current userspace software and an ioctl-based API
>>> (possibly
>>> through V4L2 controls). That way LED/flash devices would be registered
>>> with a
>>> single subsystem, and the corresponding drivers won't have to care about
>>> the
>>> API exposed to userspace. That would require a major refactoring of the
>>> in-
>>> kernel APIs though.
>>>
>>
>> I agree this. I'm thinking about expanding the ledtrig-camera.c
>> created by Milo Kim. This trigger will provide flashing and strobing
>> control of a LED device and for sure the LED device driver like
>> drivers/leds/leds-lm355x.c.
>>
>> So we basically can do this:
>> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
>> can provide trigger API to kernel drivers as well as V4L2 Flash API to
>> userspace.
>> 2. add the real flash torch functions into LED device driver like
>> leds-lm355x.c, this driver will still provide sysfs interface and
>> extended flash/torch control sysfs interface as well.
>>
>> I'm not sure about whether we need some change in V4L2 internally. But
>> actually Andrzej Hajda's patchset is quite straightforward, but we
>> just need put those V4L2 Flash API into a LED trigger driver and the
>> real flash/torch operation in a LED device driver.
>>
>> Milo, could you please give some comments here?
>
>
> General LED trigger APIs were created not for the application interface but
> for any kernel space driver.
> The LED camera trigger APIs are used by a camera driver, not application.
>

That's basically correct, but trigger sometime can also provide sysfs
interface which might be used by user space app.

Actually this camera flash/torch trigger API can also be used by V4L2
Flash subdev.
We create a V4L2 Flash subdev in the driver, which will expose V4L2
API to user space. And this V4L2 Flash subdev will use this
flash/torch trigger API to talk with our LED core and it really
doesn't need to know the details about the LED flash/torch chip, if we
can provide a good interface between trigger and LED device driver.

So benefits are
a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips
b) LED chip driver just need to provide standard or extended LED API
to support flash/torch
c) LED chip driver still keep those LED sysfs interface to user space
and won't break user space application

> Some LED devices provide basic LED functionalities and high current features
> like a flash and a torch.(eg. LM3554, LM3642)
> The reason why I added the LED camera trigger is
>   "for providing multiple operations(LEDs, flash and torch) by one LED
> device driver".
>
> For example,
> A LED indicator is controlled via the LED sysfs.
> And flash and torch are controlled by a camera driver - calls exported LED
> trigger function, ledtrig_flash_ctrl().
>
> My understanding is the V4L2 subsystem provides rich IOCTLs for the media
> device.
> I agree that the V4L2 is more proper interface for camera *application*.
>
> So, my suggestion is:
>   - If a device has only flash/torch functionalities, then register the
> driver as the V4L2 sub-device.
>   - If a device provides not only flash/torch but also LED features, then
> create the driver as the MFD.
>

We really don't need to separate them, one LED device driver can
provide flash/torch/normal functions in on driver. I think LED device
driver is trying to provide the LED chip's hardware functions, like
flash/torch/indicator etc. how to use it, we can choose different
trigger. That gives us the maxim flexibility.

> For example, LM3555 (and AS3645A) is used only for the camera.
> Then, this driver is registered as the V4L2 sub-device.
> (drivers/media/i2c/as3645a.c) - no change at all.
>

That's current solution, we plan to unify this two API since those
chip are basically LED.

> On the other hands, LM3642 has an indicator mode with flash/torch.
> Then, it will consist of 3 parts - MFD core, LED(indicator) and
> V4L2(flash/torch).
>

So if one LED device driver can support that, we don't need these 3 parts.

Thanks,
-Bryan

> Then, ledtrig-camera will be removed after we complete to change the driver
> structure.
>
> Best regards,
> Milo
>
>

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Milo Kim]

Hi Bryan,

On 10/17/2013 02:17 AM, Bryan Wu wrote:
> On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim <milo.kim@ti.com> wrote:
>> Hi Bryan,
>>
>>
>> On 10/16/2013 03:37 AM, Bryan Wu wrote:
>>>
>>> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
>>> <laurent.pinchart@ideasonboard.com> wrote:
>>>>
>>>> Hi Bryan,
>>>>
>>>> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>>>>>
>>>>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>>>>>>
>>>>>> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>>>>>>>
>>>>>>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> The V4L2 flash API supports also xenon flashes, not only LED ones.
>>>>>>> That
>>>>>>> said, I agree there's a common subset of functionality most LED flash
>>>>>>> controllers implement.
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> I originally thought one way to do this could be to make it as easy as
>>>>>>> possible to support both APIs in driver which some aregued, to which I
>>>>>>> agree, is rather poor desing.
>>>>>>>
>>>>>>> Does the LED API have a user space interface library like libv4l2? If
>>>>>>> yes, one option oculd be to implement the wrapper between the V4L2 and
>>>>>>> LED APIs there so that the applications using the LED API could also
>>>>>>> access those devices that implement the V4L2 flash API. Torch mode
>>>>>>> functionality is common between the two right now AFAIU,
>>>>>>>
>>>>>>> The V4L2 flash API also provides a way to strobe the flash using an
>>>>>>> external trigger which typically connected to the sensor (and the user
>>>>>>> can choose between that and software strobe). I guess that and Xenon
>>>>>>> flashes aren't currently covered by the LED API.
>>>>>>
>>>>>>
>>>>>> The issue is that we have a LED API targetted at controlling LEDs, a
>>>>>> V4L2
>>>>>> flash API targetted at controlling flashes, and hardware devices
>>>>>> somewhere
>>>>>> in the middle that can be used to provide LED or flash function.
>>>>>> Merging
>>>>>> the two APIs on the kernel side, with a compatibility layer for both
>>>>>> kernel space and user space APIs, might be an idea worth investigating.
>>>>>
>>>>>
>>>>> I'm so sorry for jumping in the discussion so late. Some how the
>>>>> emails from linux-media was archived in my Gmail and I haven't
>>>>> checkout this for several weeks.
>>>>>
>>>>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>>>>> Flash API. But I'd also like to see a unified API.
>>>>>
>>>>> Currently, LED API are exported to user space as sysfs interface,
>>>>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>>>>> merged some LED Flash trigger into LED subsystem. My basic idea is
>>>>> what about creating or expanding the LED Flash trigger driver and
>>>>> provide a well defined sysfs interface, which can be wrapped into user
>>>>> space libv4l2.
>>>>
>>>>
>>>> The biggest reason why we're not fond of sysfs-based APIs for media
>>>> devices is
>>>> that they can't provide atomicity. There's no way to set multiple
>>>> parameters
>>>> in a single operation.
>>>>
>>>> We can't get rid of the sysfs LEDs API, but maybe we could have a unified
>>>> kernel LED/flash subsystem that would provide both a sysfs-based API to
>>>> ensure
>>>> compatibility with current userspace software and an ioctl-based API
>>>> (possibly
>>>> through V4L2 controls). That way LED/flash devices would be registered
>>>> with a
>>>> single subsystem, and the corresponding drivers won't have to care about
>>>> the
>>>> API exposed to userspace. That would require a major refactoring of the
>>>> in-
>>>> kernel APIs though.
>>>>
>>>
>>> I agree this. I'm thinking about expanding the ledtrig-camera.c
>>> created by Milo Kim. This trigger will provide flashing and strobing
>>> control of a LED device and for sure the LED device driver like
>>> drivers/leds/leds-lm355x.c.
>>>
>>> So we basically can do this:
>>> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
>>> can provide trigger API to kernel drivers as well as V4L2 Flash API to
>>> userspace.
>>> 2. add the real flash torch functions into LED device driver like
>>> leds-lm355x.c, this driver will still provide sysfs interface and
>>> extended flash/torch control sysfs interface as well.
>>>
>>> I'm not sure about whether we need some change in V4L2 internally. But
>>> actually Andrzej Hajda's patchset is quite straightforward, but we
>>> just need put those V4L2 Flash API into a LED trigger driver and the
>>> real flash/torch operation in a LED device driver.
>>>
>>> Milo, could you please give some comments here?
>>
>>
>> General LED trigger APIs were created not for the application interface but
>> for any kernel space driver.
>> The LED camera trigger APIs are used by a camera driver, not application.
>>
>
> That's basically correct, but trigger sometime can also provide sysfs
> interface which might be used by user space app.
>
> Actually this camera flash/torch trigger API can also be used by V4L2
> Flash subdev.
> We create a V4L2 Flash subdev in the driver, which will expose V4L2
> API to user space. And this V4L2 Flash subdev will use this
> flash/torch trigger API to talk with our LED core and it really
> doesn't need to know the details about the LED flash/torch chip, if we
> can provide a good interface between trigger and LED device driver.
>
> So benefits are
> a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips
> b) LED chip driver just need to provide standard or extended LED API
> to support flash/torch
> c) LED chip driver still keep those LED sysfs interface to user space
> and won't break user space application
>
>> Some LED devices provide basic LED functionalities and high current features
>> like a flash and a torch.(eg. LM3554, LM3642)
>> The reason why I added the LED camera trigger is
>>    "for providing multiple operations(LEDs, flash and torch) by one LED
>> device driver".
>>
>> For example,
>> A LED indicator is controlled via the LED sysfs.
>> And flash and torch are controlled by a camera driver - calls exported LED
>> trigger function, ledtrig_flash_ctrl().
>>
>> My understanding is the V4L2 subsystem provides rich IOCTLs for the media
>> device.
>> I agree that the V4L2 is more proper interface for camera *application*.
>>
>> So, my suggestion is:
>>    - If a device has only flash/torch functionalities, then register the
>> driver as the V4L2 sub-device.
>>    - If a device provides not only flash/torch but also LED features, then
>> create the driver as the MFD.
>>
>
> We really don't need to separate them, one LED device driver can
> provide flash/torch/normal functions in on driver. I think LED device
> driver is trying to provide the LED chip's hardware functions, like
> flash/torch/indicator etc. how to use it, we can choose different
> trigger. That gives us the maxim flexibility.
>
>> For example, LM3555 (and AS3645A) is used only for the camera.
>> Then, this driver is registered as the V4L2 sub-device.
>> (drivers/media/i2c/as3645a.c) - no change at all.
>>
>
> That's current solution, we plan to unify this two API since those
> chip are basically LED.
>
>> On the other hands, LM3642 has an indicator mode with flash/torch.
>> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>> V4L2(flash/torch).
>>
>
> So if one LED device driver can support that, we don't need these 3 parts.

Let me clarify our discussion briefly.

For the flash and torch, there are scattered user-space APIs.
We need to unify them.

We are considering supporting V4L2 structures in the LED camera trigger.
Then, camera application controls the flash/torch via not the LED sysfs 
but the V4L2 ioctl interface.
So, changing point is the ledtrig-camera.c. No chip driver changes at all.

Is it correct?

Best regards,
Milo

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Wed, Oct 16, 2013 at 4:36 PM, Milo Kim <milo.kim@ti.com> wrote:
>
> Hi Bryan,
>
>
> On 10/17/2013 02:17 AM, Bryan Wu wrote:
>>
>> On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim <milo.kim@ti.com> wrote:
>>>
>>> Hi Bryan,
>>>
>>>
>>> On 10/16/2013 03:37 AM, Bryan Wu wrote:
>>>>
>>>>
>>>> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
>>>> <laurent.pinchart@ideasonboard.com> wrote:
>>>>>
>>>>>
>>>>> Hi Bryan,
>>>>>
>>>>> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The V4L2 flash API supports also xenon flashes, not only LED ones.
>>>>>>>> That
>>>>>>>> said, I agree there's a common subset of functionality most LED
>>>>>>>> flash
>>>>>>>> controllers implement.
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I originally thought one way to do this could be to make it as easy
>>>>>>>> as
>>>>>>>> possible to support both APIs in driver which some aregued, to which
>>>>>>>> I
>>>>>>>> agree, is rather poor desing.
>>>>>>>>
>>>>>>>> Does the LED API have a user space interface library like libv4l2?
>>>>>>>> If
>>>>>>>> yes, one option oculd be to implement the wrapper between the V4L2
>>>>>>>> and
>>>>>>>> LED APIs there so that the applications using the LED API could also
>>>>>>>> access those devices that implement the V4L2 flash API. Torch mode
>>>>>>>> functionality is common between the two right now AFAIU,
>>>>>>>>
>>>>>>>> The V4L2 flash API also provides a way to strobe the flash using an
>>>>>>>> external trigger which typically connected to the sensor (and the
>>>>>>>> user
>>>>>>>> can choose between that and software strobe). I guess that and Xenon
>>>>>>>> flashes aren't currently covered by the LED API.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The issue is that we have a LED API targetted at controlling LEDs, a
>>>>>>> V4L2
>>>>>>> flash API targetted at controlling flashes, and hardware devices
>>>>>>> somewhere
>>>>>>> in the middle that can be used to provide LED or flash function.
>>>>>>> Merging
>>>>>>> the two APIs on the kernel side, with a compatibility layer for both
>>>>>>> kernel space and user space APIs, might be an idea worth
>>>>>>> investigating.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm so sorry for jumping in the discussion so late. Some how the
>>>>>> emails from linux-media was archived in my Gmail and I haven't
>>>>>> checkout this for several weeks.
>>>>>>
>>>>>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>>>>>> Flash API. But I'd also like to see a unified API.
>>>>>>
>>>>>> Currently, LED API are exported to user space as sysfs interface,
>>>>>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>>>>>> merged some LED Flash trigger into LED subsystem. My basic idea is
>>>>>> what about creating or expanding the LED Flash trigger driver and
>>>>>> provide a well defined sysfs interface, which can be wrapped into user
>>>>>> space libv4l2.
>>>>>
>>>>>
>>>>>
>>>>> The biggest reason why we're not fond of sysfs-based APIs for media
>>>>> devices is
>>>>> that they can't provide atomicity. There's no way to set multiple
>>>>> parameters
>>>>> in a single operation.
>>>>>
>>>>> We can't get rid of the sysfs LEDs API, but maybe we could have a
>>>>> unified
>>>>> kernel LED/flash subsystem that would provide both a sysfs-based API to
>>>>> ensure
>>>>> compatibility with current userspace software and an ioctl-based API
>>>>> (possibly
>>>>> through V4L2 controls). That way LED/flash devices would be registered
>>>>> with a
>>>>> single subsystem, and the corresponding drivers won't have to care
>>>>> about
>>>>> the
>>>>> API exposed to userspace. That would require a major refactoring of the
>>>>> in-
>>>>> kernel APIs though.
>>>>>
>>>>
>>>> I agree this. I'm thinking about expanding the ledtrig-camera.c
>>>> created by Milo Kim. This trigger will provide flashing and strobing
>>>> control of a LED device and for sure the LED device driver like
>>>> drivers/leds/leds-lm355x.c.
>>>>
>>>> So we basically can do this:
>>>> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
>>>> can provide trigger API to kernel drivers as well as V4L2 Flash API to
>>>> userspace.
>>>> 2. add the real flash torch functions into LED device driver like
>>>> leds-lm355x.c, this driver will still provide sysfs interface and
>>>> extended flash/torch control sysfs interface as well.
>>>>
>>>> I'm not sure about whether we need some change in V4L2 internally. But
>>>> actually Andrzej Hajda's patchset is quite straightforward, but we
>>>> just need put those V4L2 Flash API into a LED trigger driver and the
>>>> real flash/torch operation in a LED device driver.
>>>>
>>>> Milo, could you please give some comments here?
>>>
>>>
>>>
>>> General LED trigger APIs were created not for the application interface
>>> but
>>> for any kernel space driver.
>>> The LED camera trigger APIs are used by a camera driver, not application.
>>>
>>
>> That's basically correct, but trigger sometime can also provide sysfs
>> interface which might be used by user space app.
>>
>> Actually this camera flash/torch trigger API can also be used by V4L2
>> Flash subdev.
>> We create a V4L2 Flash subdev in the driver, which will expose V4L2
>> API to user space. And this V4L2 Flash subdev will use this
>> flash/torch trigger API to talk with our LED core and it really
>> doesn't need to know the details about the LED flash/torch chip, if we
>> can provide a good interface between trigger and LED device driver.
>>
>> So benefits are
>> a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips
>> b) LED chip driver just need to provide standard or extended LED API
>> to support flash/torch
>> c) LED chip driver still keep those LED sysfs interface to user space
>> and won't break user space application
>>
>>> Some LED devices provide basic LED functionalities and high current
>>> features
>>> like a flash and a torch.(eg. LM3554, LM3642)
>>> The reason why I added the LED camera trigger is
>>>    "for providing multiple operations(LEDs, flash and torch) by one LED
>>> device driver".
>>>
>>> For example,
>>> A LED indicator is controlled via the LED sysfs.
>>> And flash and torch are controlled by a camera driver - calls exported
>>> LED
>>> trigger function, ledtrig_flash_ctrl().
>>>
>>> My understanding is the V4L2 subsystem provides rich IOCTLs for the media
>>> device.
>>> I agree that the V4L2 is more proper interface for camera *application*.
>>>
>>> So, my suggestion is:
>>>    - If a device has only flash/torch functionalities, then register the
>>> driver as the V4L2 sub-device.
>>>    - If a device provides not only flash/torch but also LED features,
>>> then
>>> create the driver as the MFD.
>>>
>>
>> We really don't need to separate them, one LED device driver can
>> provide flash/torch/normal functions in on driver. I think LED device
>> driver is trying to provide the LED chip's hardware functions, like
>> flash/torch/indicator etc. how to use it, we can choose different
>> trigger. That gives us the maxim flexibility.
>>
>>> For example, LM3555 (and AS3645A) is used only for the camera.
>>> Then, this driver is registered as the V4L2 sub-device.
>>> (drivers/media/i2c/as3645a.c) - no change at all.
>>>
>>
>> That's current solution, we plan to unify this two API since those
>> chip are basically LED.
>>
>>> On the other hands, LM3642 has an indicator mode with flash/torch.
>>> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>>> V4L2(flash/torch).
>>>
>>
>> So if one LED device driver can support that, we don't need these 3 parts.
>
>
> Let me clarify our discussion briefly.
>
> For the flash and torch, there are scattered user-space APIs.
> We need to unify them.
>
> We are considering supporting V4L2 structures in the LED camera trigger.
> Then, camera application controls the flash/torch via not the LED sysfs but
> the V4L2 ioctl interface.
> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>

Yeah, my proposal is to add V4L2 interface into ledtrig-camera.c. For
existing chip driver like yours LM3555, I guess we don't need to big
change but for future support for new chip or adding flash/torch to
existing chip, we need to create or change chip driver. Because
eventually those flash/torch/indicator operation happens in chip
driver.

Thanks,
-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Wed, Oct 16, 2013 at 4:54 PM, Bryan Wu <cooloney@gmail.com> wrote:
> On Wed, Oct 16, 2013 at 4:36 PM, Milo Kim <milo.kim@ti.com> wrote:
>>
>> Hi Bryan,
>>
>>
>> On 10/17/2013 02:17 AM, Bryan Wu wrote:
>>>
>>> On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim <milo.kim@ti.com> wrote:
>>>>
>>>> Hi Bryan,
>>>>
>>>>
>>>> On 10/16/2013 03:37 AM, Bryan Wu wrote:
>>>>>
>>>>>
>>>>> On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
>>>>> <laurent.pinchart@ideasonboard.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Bryan,
>>>>>>
>>>>>> On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The V4L2 flash API supports also xenon flashes, not only LED ones.
>>>>>>>>> That
>>>>>>>>> said, I agree there's a common subset of functionality most LED
>>>>>>>>> flash
>>>>>>>>> controllers implement.
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I originally thought one way to do this could be to make it as easy
>>>>>>>>> as
>>>>>>>>> possible to support both APIs in driver which some aregued, to which
>>>>>>>>> I
>>>>>>>>> agree, is rather poor desing.
>>>>>>>>>
>>>>>>>>> Does the LED API have a user space interface library like libv4l2?
>>>>>>>>> If
>>>>>>>>> yes, one option oculd be to implement the wrapper between the V4L2
>>>>>>>>> and
>>>>>>>>> LED APIs there so that the applications using the LED API could also
>>>>>>>>> access those devices that implement the V4L2 flash API. Torch mode
>>>>>>>>> functionality is common between the two right now AFAIU,
>>>>>>>>>
>>>>>>>>> The V4L2 flash API also provides a way to strobe the flash using an
>>>>>>>>> external trigger which typically connected to the sensor (and the
>>>>>>>>> user
>>>>>>>>> can choose between that and software strobe). I guess that and Xenon
>>>>>>>>> flashes aren't currently covered by the LED API.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The issue is that we have a LED API targetted at controlling LEDs, a
>>>>>>>> V4L2
>>>>>>>> flash API targetted at controlling flashes, and hardware devices
>>>>>>>> somewhere
>>>>>>>> in the middle that can be used to provide LED or flash function.
>>>>>>>> Merging
>>>>>>>> the two APIs on the kernel side, with a compatibility layer for both
>>>>>>>> kernel space and user space APIs, might be an idea worth
>>>>>>>> investigating.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm so sorry for jumping in the discussion so late. Some how the
>>>>>>> emails from linux-media was archived in my Gmail and I haven't
>>>>>>> checkout this for several weeks.
>>>>>>>
>>>>>>> I agree right now LED API doesn't  quite fit for the usage of V4L2
>>>>>>> Flash API. But I'd also like to see a unified API.
>>>>>>>
>>>>>>> Currently, LED API are exported to user space as sysfs interface,
>>>>>>> while V4L2 Flash APIs are like IOCTL and user space library. We also
>>>>>>> merged some LED Flash trigger into LED subsystem. My basic idea is
>>>>>>> what about creating or expanding the LED Flash trigger driver and
>>>>>>> provide a well defined sysfs interface, which can be wrapped into user
>>>>>>> space libv4l2.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The biggest reason why we're not fond of sysfs-based APIs for media
>>>>>> devices is
>>>>>> that they can't provide atomicity. There's no way to set multiple
>>>>>> parameters
>>>>>> in a single operation.
>>>>>>
>>>>>> We can't get rid of the sysfs LEDs API, but maybe we could have a
>>>>>> unified
>>>>>> kernel LED/flash subsystem that would provide both a sysfs-based API to
>>>>>> ensure
>>>>>> compatibility with current userspace software and an ioctl-based API
>>>>>> (possibly
>>>>>> through V4L2 controls). That way LED/flash devices would be registered
>>>>>> with a
>>>>>> single subsystem, and the corresponding drivers won't have to care
>>>>>> about
>>>>>> the
>>>>>> API exposed to userspace. That would require a major refactoring of the
>>>>>> in-
>>>>>> kernel APIs though.
>>>>>>
>>>>>
>>>>> I agree this. I'm thinking about expanding the ledtrig-camera.c
>>>>> created by Milo Kim. This trigger will provide flashing and strobing
>>>>> control of a LED device and for sure the LED device driver like
>>>>> drivers/leds/leds-lm355x.c.
>>>>>
>>>>> So we basically can do this:
>>>>> 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
>>>>> can provide trigger API to kernel drivers as well as V4L2 Flash API to
>>>>> userspace.
>>>>> 2. add the real flash torch functions into LED device driver like
>>>>> leds-lm355x.c, this driver will still provide sysfs interface and
>>>>> extended flash/torch control sysfs interface as well.
>>>>>
>>>>> I'm not sure about whether we need some change in V4L2 internally. But
>>>>> actually Andrzej Hajda's patchset is quite straightforward, but we
>>>>> just need put those V4L2 Flash API into a LED trigger driver and the
>>>>> real flash/torch operation in a LED device driver.
>>>>>
>>>>> Milo, could you please give some comments here?
>>>>
>>>>
>>>>
>>>> General LED trigger APIs were created not for the application interface
>>>> but
>>>> for any kernel space driver.
>>>> The LED camera trigger APIs are used by a camera driver, not application.
>>>>
>>>
>>> That's basically correct, but trigger sometime can also provide sysfs
>>> interface which might be used by user space app.
>>>
>>> Actually this camera flash/torch trigger API can also be used by V4L2
>>> Flash subdev.
>>> We create a V4L2 Flash subdev in the driver, which will expose V4L2
>>> API to user space. And this V4L2 Flash subdev will use this
>>> flash/torch trigger API to talk with our LED core and it really
>>> doesn't need to know the details about the LED flash/torch chip, if we
>>> can provide a good interface between trigger and LED device driver.
>>>
>>> So benefits are
>>> a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips
>>> b) LED chip driver just need to provide standard or extended LED API
>>> to support flash/torch
>>> c) LED chip driver still keep those LED sysfs interface to user space
>>> and won't break user space application
>>>
>>>> Some LED devices provide basic LED functionalities and high current
>>>> features
>>>> like a flash and a torch.(eg. LM3554, LM3642)
>>>> The reason why I added the LED camera trigger is
>>>>    "for providing multiple operations(LEDs, flash and torch) by one LED
>>>> device driver".
>>>>
>>>> For example,
>>>> A LED indicator is controlled via the LED sysfs.
>>>> And flash and torch are controlled by a camera driver - calls exported
>>>> LED
>>>> trigger function, ledtrig_flash_ctrl().
>>>>
>>>> My understanding is the V4L2 subsystem provides rich IOCTLs for the media
>>>> device.
>>>> I agree that the V4L2 is more proper interface for camera *application*.
>>>>
>>>> So, my suggestion is:
>>>>    - If a device has only flash/torch functionalities, then register the
>>>> driver as the V4L2 sub-device.
>>>>    - If a device provides not only flash/torch but also LED features,
>>>> then
>>>> create the driver as the MFD.
>>>>
>>>
>>> We really don't need to separate them, one LED device driver can
>>> provide flash/torch/normal functions in on driver. I think LED device
>>> driver is trying to provide the LED chip's hardware functions, like
>>> flash/torch/indicator etc. how to use it, we can choose different
>>> trigger. That gives us the maxim flexibility.
>>>
>>>> For example, LM3555 (and AS3645A) is used only for the camera.
>>>> Then, this driver is registered as the V4L2 sub-device.
>>>> (drivers/media/i2c/as3645a.c) - no change at all.
>>>>
>>>
>>> That's current solution, we plan to unify this two API since those
>>> chip are basically LED.
>>>
>>>> On the other hands, LM3642 has an indicator mode with flash/torch.
>>>> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>>>> V4L2(flash/torch).
>>>>
>>>
>>> So if one LED device driver can support that, we don't need these 3 parts.
>>
>>
>> Let me clarify our discussion briefly.
>>
>> For the flash and torch, there are scattered user-space APIs.
>> We need to unify them.
>>
>> We are considering supporting V4L2 structures in the LED camera trigger.
>> Then, camera application controls the flash/torch via not the LED sysfs but
>> the V4L2 ioctl interface.
>> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>>
>
> Yeah, my proposal is to add V4L2 interface into ledtrig-camera.c. For
> existing chip driver like yours LM3555, I guess we don't need to big
> change but for future support for new chip or adding flash/torch to
> existing chip, we need to create or change chip driver. Because
> eventually those flash/torch/indicator operation happens in chip
> driver.
>
> Thanks,
> -Bryan

Remove my old email address.

-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Andy Walls]

On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote:

> > That's current solution, we plan to unify this two API since those
> > chip are basically LED.
> >
> >> On the other hands, LM3642 has an indicator mode with flash/torch.
> >> Then, it will consist of 3 parts - MFD core, LED(indicator) and
> >> V4L2(flash/torch).
> >>
> >
> > So if one LED device driver can support that, we don't need these 3 parts.
> 
> Let me clarify our discussion briefly.
> 
> For the flash and torch, there are scattered user-space APIs.
> We need to unify them.

Sorry for the late input.

There are also subject matter illuminators (is that the same as torch?).
They may be LED or halogen incadescent bulbs that are integral to a
device such as the QX5 microscope:

http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152

The V4L2 user controls ioctl()'s are used to control those two lamps
currently.  Their activation seemed like a switch the user would want to
turn easily, via a GUI that contained other V4L2 device controls.

Do these fit in anywhere into the unification?  Not that I'm advocating
that. I just thought cases like this shouldn't be overlooked in deciding
what to do.

Regards,
Andy

> We are considering supporting V4L2 structures in the LED camera trigger.
> Then, camera application controls the flash/torch via not the LED sysfs 
> but the V4L2 ioctl interface.
> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
> 
> Is it correct?
> 
> Best regards,
> Milo

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

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

On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote:
>
>> > That's current solution, we plan to unify this two API since those
>> > chip are basically LED.
>> >
>> >> On the other hands, LM3642 has an indicator mode with flash/torch.
>> >> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>> >> V4L2(flash/torch).
>> >>
>> >
>> > So if one LED device driver can support that, we don't need these 3 parts.
>>
>> Let me clarify our discussion briefly.
>>
>> For the flash and torch, there are scattered user-space APIs.
>> We need to unify them.
>
> Sorry for the late input.
>
> There are also subject matter illuminators (is that the same as torch?).
> They may be LED or halogen incadescent bulbs that are integral to a
> device such as the QX5 microscope:
>
> http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152
>
> The V4L2 user controls ioctl()'s are used to control those two lamps
> currently.  Their activation seemed like a switch the user would want to
> turn easily, via a GUI that contained other V4L2 device controls.
>
> Do these fit in anywhere into the unification?  Not that I'm advocating
> that. I just thought cases like this shouldn't be overlooked in deciding
> what to do.
>
> Regards,
> Andy
>
>> We are considering supporting V4L2 structures in the LED camera trigger.
>> Then, camera application controls the flash/torch via not the LED sysfs
>> but the V4L2 ioctl interface.
>> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>>
>> Is it correct?
>>
>> Best regards,
>> Milo
>
>

Please find my proposal attached and probably my colleague Paul
Walmsley will show up for this media mini summit if he is available.

Thanks,
-Bryan

[-- Attachment #2: Unify LED and V4L2 Flash API.pdf --]
[-- Type: application/pdf, Size: 31693 bytes --]

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Bryan Wu]

On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
> Please find the multi selection api proposal attached.
>
> See you in Edinburgh.
>
>
> Thanks
>
> On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu <cooloney@gmail.com> wrote:
>> On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>>> On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote:
>>>
>>>> > That's current solution, we plan to unify this two API since those
>>>> > chip are basically LED.
>>>> >
>>>> >> On the other hands, LM3642 has an indicator mode with flash/torch.
>>>> >> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>>>> >> V4L2(flash/torch).
>>>> >>
>>>> >
>>>> > So if one LED device driver can support that, we don't need these 3 parts.
>>>>
>>>> Let me clarify our discussion briefly.
>>>>
>>>> For the flash and torch, there are scattered user-space APIs.
>>>> We need to unify them.
>>>
>>> Sorry for the late input.
>>>
>>> There are also subject matter illuminators (is that the same as torch?).
>>> They may be LED or halogen incadescent bulbs that are integral to a
>>> device such as the QX5 microscope:
>>>
>>> http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152
>>>
>>> The V4L2 user controls ioctl()'s are used to control those two lamps
>>> currently.  Their activation seemed like a switch the user would want to
>>> turn easily, via a GUI that contained other V4L2 device controls.
>>>
>>> Do these fit in anywhere into the unification?  Not that I'm advocating
>>> that. I just thought cases like this shouldn't be overlooked in deciding
>>> what to do.
>>>
>>> Regards,
>>> Andy
>>>
>>>> We are considering supporting V4L2 structures in the LED camera trigger.
>>>> Then, camera application controls the flash/torch via not the LED sysfs
>>>> but the V4L2 ioctl interface.
>>>> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>>>>
>>>> Is it correct?
>>>>
>>>> Best regards,
>>>> Milo
>>>
>>>
>>
>> Please find my proposal attached and probably my colleague Paul
>> Walmsley will show up for this media mini summit if he is available.
>>
>> Thanks,
>> -Bryan
>
>

Is the time and location of media mini-summit fixed? My colleague
might show up if it's not conflicted with ARM mini-summit.

Thanks,
-Bryan

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Hans Verkuil]

On 10/21/2013 06:40 PM, Bryan Wu wrote:
> On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
>> Please find the multi selection api proposal attached.
>>
>> See you in Edinburgh.
>>
>>
>> Thanks
>>
>> On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu <cooloney@gmail.com> wrote:
>>> On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>>>> On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote:
>>>>
>>>>>> That's current solution, we plan to unify this two API since those
>>>>>> chip are basically LED.
>>>>>>
>>>>>>> On the other hands, LM3642 has an indicator mode with flash/torch.
>>>>>>> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>>>>>>> V4L2(flash/torch).
>>>>>>>
>>>>>>
>>>>>> So if one LED device driver can support that, we don't need these 3 parts.
>>>>>
>>>>> Let me clarify our discussion briefly.
>>>>>
>>>>> For the flash and torch, there are scattered user-space APIs.
>>>>> We need to unify them.
>>>>
>>>> Sorry for the late input.
>>>>
>>>> There are also subject matter illuminators (is that the same as torch?).
>>>> They may be LED or halogen incadescent bulbs that are integral to a
>>>> device such as the QX5 microscope:
>>>>
>>>> http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152
>>>>
>>>> The V4L2 user controls ioctl()'s are used to control those two lamps
>>>> currently.  Their activation seemed like a switch the user would want to
>>>> turn easily, via a GUI that contained other V4L2 device controls.
>>>>
>>>> Do these fit in anywhere into the unification?  Not that I'm advocating
>>>> that. I just thought cases like this shouldn't be overlooked in deciding
>>>> what to do.
>>>>
>>>> Regards,
>>>> Andy
>>>>
>>>>> We are considering supporting V4L2 structures in the LED camera trigger.
>>>>> Then, camera application controls the flash/torch via not the LED sysfs
>>>>> but the V4L2 ioctl interface.
>>>>> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>>>>>
>>>>> Is it correct?
>>>>>
>>>>> Best regards,
>>>>> Milo
>>>>
>>>>
>>>
>>> Please find my proposal attached and probably my colleague Paul
>>> Walmsley will show up for this media mini summit if he is available.
>>>
>>> Thanks,
>>> -Bryan
>>
>>
> 
> Is the time and location of media mini-summit fixed? My colleague
> might show up if it's not conflicted with ARM mini-summit.

It's in the Glamis room on Wednesday. We start at 9 am and the LED topic
is currently scheduled as the second topic so I expect that it will be
discussed between 9 and 10 am.

Regards,

	Hans

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Hans Verkuil]

On 10/21/2013 07:29 PM, Ricardo Ribalda Delgado wrote:
> I thought that i was second...

You are right, I was looking at an older version.

The LED topic is third, around 9:50.

Sorry for the confusion.

 btw could i borrow somebodys notebook for presenting the slides?

Sure. Put them on a USB stick or make them available on the web for download and I
can present them for you. I've saved the slides you mailed me earlier to my laptop.

Regards,

	Hans

> 
> Thanks
> 
> On 21 Oct 2013 19:53, "Hans Verkuil" <hverkuil@xs4all.nl <mailto:hverkuil@xs4all.nl>> wrote:
> 
>     On 10/21/2013 06:40 PM, Bryan Wu wrote:
>     > On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado
>     > <ricardo.ribalda@gmail.com <mailto:ricardo.ribalda@gmail.com>> wrote:
>     >> Please find the multi selection api proposal attached.
>     >>
>     >> See you in Edinburgh.
>     >>
>     >>
>     >> Thanks
>     >>
>     >> On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu <cooloney@gmail.com <mailto:cooloney@gmail.com>> wrote:
>     >>> On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@md.metrocast.net <mailto:awalls@md.metrocast.net>> wrote:
>     >>>> On Thu, 2013-10-17 <tel:2013-10-17> at 08:36 +0900, Milo Kim wrote:
>     >>>>
>     >>>>>> That's current solution, we plan to unify this two API since those
>     >>>>>> chip are basically LED.
>     >>>>>>
>     >>>>>>> On the other hands, LM3642 has an indicator mode with flash/torch.
>     >>>>>>> Then, it will consist of 3 parts - MFD core, LED(indicator) and
>     >>>>>>> V4L2(flash/torch).
>     >>>>>>>
>     >>>>>>
>     >>>>>> So if one LED device driver can support that, we don't need these 3 parts.
>     >>>>>
>     >>>>> Let me clarify our discussion briefly.
>     >>>>>
>     >>>>> For the flash and torch, there are scattered user-space APIs.
>     >>>>> We need to unify them.
>     >>>>
>     >>>> Sorry for the late input.
>     >>>>
>     >>>> There are also subject matter illuminators (is that the same as torch?).
>     >>>> They may be LED or halogen incadescent bulbs that are integral to a
>     >>>> device such as the QX5 microscope:
>     >>>>
>     >>>> http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152
>     >>>>
>     >>>> The V4L2 user controls ioctl()'s are used to control those two lamps
>     >>>> currently.  Their activation seemed like a switch the user would want to
>     >>>> turn easily, via a GUI that contained other V4L2 device controls.
>     >>>>
>     >>>> Do these fit in anywhere into the unification?  Not that I'm advocating
>     >>>> that. I just thought cases like this shouldn't be overlooked in deciding
>     >>>> what to do.
>     >>>>
>     >>>> Regards,
>     >>>> Andy
>     >>>>
>     >>>>> We are considering supporting V4L2 structures in the LED camera trigger.
>     >>>>> Then, camera application controls the flash/torch via not the LED sysfs
>     >>>>> but the V4L2 ioctl interface.
>     >>>>> So, changing point is the ledtrig-camera.c. No chip driver changes at all.
>     >>>>>
>     >>>>> Is it correct?
>     >>>>>
>     >>>>> Best regards,
>     >>>>> Milo
>     >>>>
>     >>>>
>     >>>
>     >>> Please find my proposal attached and probably my colleague Paul
>     >>> Walmsley will show up for this media mini summit if he is available.
>     >>>
>     >>> Thanks,
>     >>> -Bryan
>     >>
>     >>
>     >
>     > Is the time and location of media mini-summit fixed? My colleague
>     > might show up if it's not conflicted with ARM mini-summit.
> 
>     It's in the Glamis room on Wednesday. We start at 9 am and the LED topic
>     is currently scheduled as the second topic so I expect that it will be
>     discussed between 9 and 10 am.
> 
>     Regards,
> 
>             Hans
> 

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Hans Verkuil]

On 10/21/2013 06:52 PM, Hans Verkuil wrote:
> On 10/21/2013 06:40 PM, Bryan Wu wrote:
>> Is the time and location of media mini-summit fixed? My colleague
>> might show up if it's not conflicted with ARM mini-summit.
> 
> It's in the Glamis room on Wednesday. We start at 9 am and the LED topic
> is currently scheduled as the second topic so I expect that it will be
> discussed between 9 and 10 am.


I just posted the final (at least, I really hope it will be the final) version of
the agenda to linux-media and media-workshop. The LED topic moved to a somewhat
later slot and is currently scheduled for 10:50. All these times are tentative so
for this topic you should probably be there at 10:30 to be safe.

Regards,

	Hans

Re: V2: Agenda for the Edinburgh mini-summit

[Thierry Reding]

[-- 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 --]