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

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

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