public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Nayden Kanchev <nkanchev@mm-sol.com>
To: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	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: Wed, 06 Apr 2011 11:38:08 +0300	[thread overview]
Message-ID: <4D9C2670.2000603@mm-sol.com> (raw)
In-Reply-To: <4D9C2000.9090500@maxwell.research.nokia.com>

Hi Sakari,

Thanks for the update. I have just one comment about strobe types.

<snip>


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,
> };
>

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 would also rename xxx_STROBE_WHENCE to xxx_STROBE_TYPE but it is just 
a suggestion :)

BR,
Nayden

  reply	other threads:[~2011-04-06  8:36 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 [this message]
2011-04-06  9:25   ` Sakari Ailus
2011-04-06 13:23     ` Laurent Pinchart
2011-04-09 16:17       ` Sakari Ailus
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=4D9C2670.2000603@mm-sol.com \
    --to=nkanchev@mm-sol.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=riverful@gmail.com \
    --cc=sakari.ailus@maxwell.research.nokia.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