Re: [RFC] V4L2 API for flash devices

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

Laurent Pinchart wrote:
> Hi Sakari,

Heippa,

> On Wednesday 13 April 2011 14:16:38 Sakari Ailus wrote:
>> Sung Hee Park wrote:
>>> Here are two more use-cases for flash that might help inform the API
>>> design. Sakari encouraged me to post these. The person writing this is
>>> Andrew Adams, but I'm sending this from Sung Hee's account, because I
>>> only just subscribed to linux-media and can't immediately figure out how
>>> to reply to messages from before I subscribed. Sung Hee and I are both
>>> grad students at Stanford who work on FCam
>>> (http://fcam.garage.maemo.org/)
>>
>> Hi Andrew,
>>
>> Many thanks for the comments.
>>
>>> Second-curtain-sync:
>>>
>>> Sometimes you want to fire the flash at the end of a long exposure time.
>>> It's usually a way to depict motion. Here's an example:
>>> http://www.flickr.com/photos/latitudes/133206615/.
>>>
>>> This only really applies to xenon flashes because you can't get a crisp
>>> image out of a longer duration LED flash. Even then it's somewhat
>>> problematic on rolling-shutter sensors but still possible provided you
>>> don't mind a slight shear to the crisp part of the image. From an API
>>> perspective, it requires you to be able to specify a trigger time at
>>> some number of microseconds into the exposure. On the N900 we did this
>>> with a real-time thread.
>>>
>>> Triggering external hardware:
>>>
>>> This use-case is a little weirder, but it has the same API requirement.
>>> Some photographic setups require you to synchronize some piece of
>>> hardware with the exposure (e.g. an oscilloscope, or an external slave
>>> flash). On embedded devices this is generally difficult. If you can at
>>> least fire the flash at a precise delay into the exposure, you can
>>> attach a photodiode to it, and use the flash+photodiode as an
>>> opto-isolator to trigger your external hardware.
>>>
>>> So we're in favor of having user-settable flash duration, and also
>>> user-settable trigger times (with reference to the start of the exposure
>>> time). I'm guessing that in a SMIA++ driver the trigger time would
>>> actually be a control on the sensor device, but it seemed relevant to
>>> bring up while you guys were talking about the flash API.
>>
>> From this I reckon that in a general case the handling of the flash
>> timing cannot be left for the drivers only. There must be a way to
>> control it.
>>
>> So I'd think that also the level/edge trigger for the flash should be
>> visible. On edge trigger, the only limiting factor for the flash
>> duration on hardware would be the relatively coarse watchdog timer, and
>> I'd think the user should be able to know that.
> 
> I agree that the user should be able to query the limit. The limit value 
> should come from platform data.

Agreed.

>> The flash timing controls should be exposed by the sensor driver since
>> the sensor is what actually performs the timing.
>>
>> Laurent; what do you think?
> 
> As already discussed with you offline, I think we will need flash timing 
> controls on the sensor when the flash controller is configured with external 
> strobe in level triggered mode. I'm still not sure if the edge/level-triggered 
> names are the best option. They confused me in the beginning, so I find them 
> confusing :-) If we keep them, they will need to be very precisely documented.

I'm fine with other naming --- edge/level is from the AS3645
documentation. ADP1653 does not call it with a name as far as I
remember. Other similar chips can be found here:

<URL:http://www.austriamicrosystems.com/eng/Products/Lighting-Management/>

I tried to download the datasheets but couldn't. The AS3645 datasheet,
however, is also available here:

<URL:http://www.cdiweb.com/datasheets/austriamicro/AS3645_Datasheet_v1-6.pdf>

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com