public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Nayden Kanchev <nkanchev@mm-sol.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Cohen David Abraham <david.cohen@nokia.com>,
	Kim HeungJun <riverful@gmail.com>
Subject: Re: [RFC v2] V4L2 API for flash devices
Date: Sat, 09 Apr 2011 19:17:34 +0300	[thread overview]
Message-ID: <4DA0869E.4030505@maxwell.research.nokia.com> (raw)
In-Reply-To: <201104061523.19756.laurent.pinchart@ideasonboard.com>

Laurent Pinchart wrote:
> Hi Sakari,

Hi Laurent,

And thanks for the comments.

> On Wednesday 06 April 2011 11:25:56 Sakari Ailus wrote:
>> Nayden Kanchev wrote:
>>> On 04/06/2011 11:10 AM, Sakari Ailus wrote:
>>>> - Added an open question on a new control:
>>>> V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE.
>>>
>>> <snip>
>>>
>>>> 2. External strobe edge / level
>>>> -------------------------------
>>>>
>>>> No use is seen currently for this, but it may well appear, and the
>>>> hardware supports this. Level based trigger should be used since it is
>>>> more precise.
>>>>
>>>>     V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE
>>>>
>>>> Whether the flash controller considers external strobe as edge, when the
>>>> only limit of the strobe is the timeout on flash controller, or level,
>>>> when the flash strobe will last as long as the strobe signal, or as long
>>>> until the timeout expires.
>>>>
>>>> enum v4l2_flash_external_strobe_whence {
>>>>
>>>>     V4L2_CID_FLASH_EXTERNAL_STROBE_LEVEL,
>>>>     V4L2_CID_FLASH_EXTERNAL_STROBE_EDGE,
>>>>
>>>> };
>>
>> Removed "CID_":
>>
>> enum v4l2_flash_external_strobe_whence {
>> 	V4L2_FLASH_EXTERNAL_STROBE_LEVEL,
>> 	V4L2_FLASH_EXTERNAL_STROBE_EDGE,
>> };
>>
>> I guess this should be an rw menu control for LED flash?
>>
>>> I agree that control over the strobe usage (level/edge) is required.
>>> Although we have some bad experience will lack of detailed information
>>> how exactly the flash chip will use those signals.
>>>
>>> For example with AS3645A flash driver strobing by edge produced really
>>> strange flash output - light intensity was changing during the process
>>> and flash was stopped before the HW timeout.
>>>
>>> On the other hand strobing by level didn't cause problems.
>>>
>>> So even if HW supports some functionally we should prevent such
>>> malfunctioning by adding some restrictions in the board code also.
>>
>> I agree.
>>
>> The control should be probably exposed to tell which kind of
>> functionality does the flash chip provide, even if the menu has just one
>> option in it.
>>
>>> I would also rename xxx_STROBE_WHENCE to xxx_STROBE_TYPE but it is just
>>> a suggestion :)
>>
>> Sounds good to me.
>>
>> V4L2_CID_FLASH_STROBE_MODE should be renamed to
>> V4L2_CID_FLASH_STROBE_WHENCE. That proper use of whence IMO. :-)
> 
> Does this really need to be exposed to userspace ? Shouldn't it just be static 
> information coming from platform data ?

If the sensor is expected to set the strobe length, the value needs to
be programmed to the sensor. The sensor driver should be able to do this
as it has all the timing related information on the sensor state.

What if the user wants to expose more than one frame with flash?

The sensor should be able to export the total required exposure time of
the full frame. The exposure of each line begins at different time so
the exposure time of the full frame exceeds the exposure time of a
single pixel --- it may be almost double.

The user must be able to know that the exposure time required to expose
the frame is smaller or equal to the maximum possible exposure time of
the flash.

To the user there is no significant difference between the two. There
may be effects on the following frames beyond the one(s) exposed with flash.

I agree we could omit this, at least for now.

Regards,

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

  reply	other threads:[~2011-04-09 16:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06  8:10 [RFC v2] V4L2 API for flash devices Sakari Ailus
2011-04-06  8:38 ` Nayden Kanchev
2011-04-06  9:25   ` Sakari Ailus
2011-04-06 13:23     ` Laurent Pinchart
2011-04-09 16:17       ` Sakari Ailus [this message]
2011-04-11 15:34         ` Laurent Pinchart
2011-04-06 13:39 ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DA0869E.4030505@maxwell.research.nokia.com \
    --to=sakari.ailus@maxwell.research.nokia.com \
    --cc=david.cohen@nokia.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=nkanchev@mm-sol.com \
    --cc=riverful@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox