On 10/15/2013 08:37 PM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
> <laurent.pinchart@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
