Re: [PATCH/RFC v4 00/21] LED / flash API integration

[Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]

On 08/14/2014 07:03 AM, Sakari Ailus wrote:
> Hi Jacek,
>
> On Thu, Aug 07, 2014 at 10:21:14AM +0200, Jacek Anaszewski wrote:
>> On 08/06/2014 08:53 AM, Sakari Ailus wrote:
>>> Hi Jacek,
>>>
>>> On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote:
>>> ...
>>>> 1) Who should register V4L2 Flash sub-device?
>>>>
>>>> LED Flash Class devices, after introduction of the Flash Manager,
>>>> are not tightly coupled with any media controller. They are maintained
>>>> by the Flash Manager and made available for dynamic assignment to
>>>> any media system they are connected to through multiplexing devices.
>>>>
>>>> In the proposed rough solution, when support for V4L2 Flash sub-devices
>>>> is enabled, there is a v4l2_device created for them to register in.
>>>> This however implies that V4L2 Flash device will not be available
>>>> in any media controller, which calls its existence into question.
>>>>
>>>> Therefore I'd like to consult possible ways of solving this issue.
>>>> The option I see is implementing a mechanism for moving V4L2 Flash
>>>> sub-devices between media controllers. A V4L2 Flash sub-device
>>>> would initially be assigned to one media system in the relevant
>>>> device tree binding, but it could be dynamically reassigned to
>>>> the other one. However I'm not sure if media controller design
>>>> is prepared for dynamic modifications of its graph and how many
>>>> modifications in the existing drivers this solution would require.
>>>
>>> Do you have a use case where you would need to strobe a flash from multiple
>>> media devices at different times, or is this entirely theoretical? Typically
>>> flash controllers are connected to a single source of hardware strobe (if
>>> there's one) since the flash LEDs are in fact mounted next to a specific
>>> camera sensor.
>>
>> I took into account such arrangements in response to your message
>> [1], where you were considering configurations like "one flash but
>> two
>> cameras", "one camera and two flashes". And you also called for
>> proposing generic solution.
>>
>> One flash and two (or more) cameras case is easily conceivable -
>> You even mentioned stereo cameras. One camera and many flashes
>> arrangement might be useful in case of some professional devices which
>> might be designed so that they would be able to apply different scene
>> lighting. I haven't heard about such devices, but as you said
>> such a configuration isn't unthinkable.
>>
>>> If this is a real issue the way to solve it would be to have a single media
>>> device instead of many.
>>
>> I was considering adding media device, that would be a representation
>> of a flash manager, gathering all the registered flashes. Nonetheless,
>> finally I came to conclusion that a v4l2-device alone should suffice,
>> just to provide a Flash Manager representation allowing for
>> v4l2-flash sub-devices to register in.
>> All the features provided by the media device are useless in case
>> of a set of V4L2 Flash sub-devices. They couldn't have any linkage
>> in such a device. The only benefit from having media device gathering
>> V4L2 Flash devices would be possibility of listing them.
>
> Not quite so. The flash is associated to the sensor (and lens) using the
> group ID in the Media controller. The user space doesn't need to "know" this
> association.
>
> More complex use cases such as the above may need extensions to the Media
> controller API.

I think that I have unnecessarily complicated the issue. Generally
there will be always one media controller created for all camera
sensors available in the system. If there is a single media controller
then we can easily use async subdev registration API. A media-dev
driver would have to parse list of flash device phandles from
the ISP device's DT node and register them as async sub-devices.

Best Regards,
Jacek Anaszewski

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html