Hi folks,
On Wed, 23 Oct 2013, Hans Verkuil wrote:
- Paul Walmsley on behalf of Bryan Wu: LED / flash API integration
Currently functionality is accessible from two APIs: LED and flash. A proposal is presented to put V4L2 flash subdev on top of LED core. It would be better not to go via the LED trigger layer.
- One to one mapping between LED chips and V4L2 sub-devices. This probably means the LED flash driver needs to register the sub-device.
- Two interfaces: should the sysfs interface be disabled if an application chose the flash mode on V4L2 API? The flash driver has no knowledge of streaming state or capturing frames.
- Same requirements as for the LED API as the V4L2 flash API needs (LED flashes only).
- Currently there's no V4L2 API to put a sensor into a flash mode to automatically trigger a flash pin. This would have to be handled. It is also possible, that a V4L2 application uses a sensor, but only puts it into a "flash mode" (single-shot mode) for several frames. The LED might therefore have to be made busy always when the sensor is used. Situations, where an LED is busy should already happen, e.g. if one application wants to use it for a torch and another one for notifications.
Here are the notes I took of the discussion on this item:
1. There seemed to be broad consensus that there's no need to use the ledtrig-camera.c layer. Instead it's probably better for the v4l2 flash subdev code to call directly into the LED framework core.
2. How to register LED devices initially? How to associate LED chips to v4l2? In particular, how should this be modeled in DT data? There needs to be some link to connect sensors to flash chips in the DT data. The media controller API has the notion of groups; perhaps that can be expressed in DT with phandles.
3. How should hardware triggers be implemented? Some sensor hardware has the ability to automatically fire the flash when the sensor activates, without the involvement of any Linux-side software (beyond the initial configuration of the feature). There needs to be some knowledge in the LED core that can enable this.
4. Several concerns over races and multiple users: should the sysfs LED interface always be exposed, or not? For example, if a sysfs request comes in to the LED core while a hardware capture is occurring, should it return -EBUSY? Sakari felt that it was better to arbitrate this in userspace, since it was a matter of policy, while some others wanted it to be handled in the kernel. There was a debate and divergence of opinion on this. If the kernel will be responsible for this mutal exclusion, then it should also be possible to disable the use of other LED triggers once v4l2 is using it.
Also attached is the introductory slide created to depict the current situation.
best regards -
- Paul