Re: [RFC] V4L2 brainstorming meeting in Cambridge, August 2011

[Sakari Ailus]

On Fri, Jun 17, 2011 at 10:56:11AM +0200, Laurent Pinchart wrote:
 Hello everybody,

Hi Laurent and all others,

 Following our (not so) long-standing tradition of V4L2 brainstorming 
 meetings, 
 I would like to propose Cambridge, UK as a possible location for the next 
 brainstorming session on the first week of August (1st to 5th).
 
 Linaro developers will gather for a one-week sprint session at the same time 
 and place, and they will have a 3 half-day graphics summit where graphic 
 memory management will be discussed (https://wiki.linaro.org/Events/2011-08-
 LDS/Schedule). Collocating the V4L2 brainstorming meeting with the Linaro 
 sprint would allow those of us who are interested in both topics to attend 
 the 
 Linaro graphics summit as well.
 
 Topics to be discussed include pipeline configuration and per-frame 
 configuration. Other topics can be proposed as well, but this should be 
 enough 
 to fill our usual 3 days agenda.

What about sub-subdevs? Or is everything concerning them clear? :-)

Regards,

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2 api for flash drivers

[Andy Shevchenko]

On Thu, 2011-06-30 at 14:26 +0300, Sakari Ailus wrote: 
   [1] http://www.spinics.net/lists/linux-media/msg32527.html
 Yeah, that's my expectation as well unless there are further issues found
 with them.
I had not been subscribed to ML when you discussed the topic. So, might
be I missed something. However, the question is why have you chosen
hardware units for *_INTENSITY instead of, let say, hundredth of
percents (like 0 .. 1)?

-- 
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some comments on the new autocluster patches

[Hans Verkuil]

OK, I'm back to work after my vacation, so it's time to go through the
backlog...

On Tuesday, July 12, 2011 15:25:02 Hans de Goede wrote:
 Hi,
 
 On 07/04/2011 11:43 AM, Hans Verkuil wrote:
  On Saturday, July 02, 2011 16:31:47 Hans de Goede wrote:
  Hi,
 
  On 07/02/2011 01:10 PM, Hans Verkuil wrote:
  On Saturday, July 02, 2011 12:28:35 Hans de Goede wrote:
  Hi,
 
  snip snip snip
 
  Ok, thinking about this some more and reading Hans V's comments
  I think that the current code in Hans V's core8c branch is fine,
  and should go to 3.1 (rather then be delayed to 3.2).
 
  As for the fundamental question what to do with foo
  controls when autofoo goes from auto to manual, as discussed
  there are 2 options:
  1) Restore the last known / previous manual setting
  2) Keep foo at the current setting, iow the last setting
configured by autofoo
 
  Or option 3:
 
  Just don't report the automatic foo values at all. What possible purpose
  does it serve?
  Reporting should be seen separate of what to do with the actual
  setting of for example gain as in use by the device when autogain
  gets turned off, that is what I'm talking about here, when autogain
  gets turned off (iow gain gets set to manual) there are 2 and only
  2 options
 
  1) leave the gain at the value last set by the devices
   autogain function (this may not be supported on all hardware)
  2) restore the last known manual gain setting
 
  What we report or not report for gain while autogain is active
  is irrelevant for this choice, when switching to manual we can
  either leave gain as is, or we restore the last known setting.
  Independent of any values we may have reported.
 
  It is relevant. Take an application that saves the current state of all
  controls and restores it the next time it is started. If you report the
  device's autogain value instead of the manual gain, then that manual gain
  value is lost. I consider this a major drawback.
 
 If autogain is on, then the gain is RO, so it should not be saved. Let alone
 restored.

Marking gain as inactive is fine, but marking it as read-only is not so clear.
Currently the RO flag is static. This allows control panels to use e.g. a text
field instead of an input field to show the value.

I would like to keep that functionality. If we make the RO flag dynamic, then
GUIs won't know whether to show it as a disabled input field or as a text field.

Whereas with the inactive flag they will know that it has to be a disabled
input field.

When the inactive flag is set, it is still allowed to set the value. However,
if we add a volatile flag as well, then we may want to have the combination
'inactive and volatile' return an error when an application attempts to set the
value.

Or is this too complex and should we just discard the value in a case like that?

 
  It is my impression that drivers implement it 'just because
  they can', and not because it is meaningful.
 
  Well it is drivers responsibility to export hardware functionality
  (in a standardized manner), then it is up to applications whether
  they use it or not. And it is actually quite meaning full, you
  are very much thinking TV and not webcams here, being able to
  see that the autofoo is actually doing something, and what
  it is doing is very useful for webcams. For example maybe it is
  choosing a low exposure (to get highframerate) high gain, which
  leads to more noise in the picture then the user wants
 
  webcams are like photography, you've a shutter and a sensitivity
  (iso) setting being able to see what a camera chooses in full
  auto mode is quite useful.
 
  OK, but it is not useful that this means that you don't see the manual value
  anymore.
 
 
 In normal webcam use the lighting conditions are constantly changing, so
 the gain value manually set 5 minutes ago is of little value, as it
 is likely wrong for the current situation.

True.
 
  I'm not aware of any application that actually refreshes e.g. gain values
  when autogain is on, so end-users never see it anyway.
 
  v4l2ucp has an option to update the ctrl readings every 1 / 2 / 5
  seconds. And I use this often to track what the autofoo is doing
  and / or to verify that it doing anything at all.
 
  OK, good to know.
 
  But I think we should stop supporting volatile writable controls.
 
  NACK, and note that we already don't do that, what we do is switch
  a control from volatile read only (inactive) to non volatile rw-mode
  and back. The only question is what to do at the transition.
 
  No, the question is also what to return.
 
 What to return sort of follows from what you do when turning
 of autogain, if you keep the last autogain set gain, then it
 makes sense to return the autogain set value when reading gain, if
 you switch back to the last manually set gain, then it
 makes sense to just report the last manually set gain as long
 as autogain is on.
 
 I still believe that everything boils down to 2 possible scenarios,
 and 

Re: v4l2 api for flash drivers

[Sakari Ailus]

Hi Andy,

On Tue, Jul 26, 2011 at 12:12:02PM +0300, Andy Shevchenko wrote:
 On Thu, 2011-06-30 at 14:26 +0300, Sakari Ailus wrote: 
[1] http://www.spinics.net/lists/linux-media/msg32527.html
  Yeah, that's my expectation as well unless there are further issues found
  with them.
 I had not been subscribed to ML when you discussed the topic. So, might
 be I missed something. However, the question is why have you chosen
 hardware units for *_INTENSITY instead of, let say, hundredth of
 percents (like 0 .. 1)?

Current is not that hardware specific.

There is some value in knowing the actual current. For example, if you have
two different flash controllers with the same LED, you can achieve the same
luminous output by choosing the same current on both controllers, without
knowing which one you're actually using.

Regards,

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Binning on sensors

[Hans Verkuil]

On Friday, July 15, 2011 14:46:26 Sakari Ailus wrote:
 On Fri, Jul 15, 2011 at 01:38:35PM +0200, Laurent Pinchart wrote:
  On Thursday 14 July 2011 19:56:10 Guennadi Liakhovetski wrote:
   On Thu, 14 Jul 2011, Sakari Ailus wrote:
Hi all,

I was thinking about the sensor binning controls.
   
   What wrong with just doing S_FMT on the subdev pad? Binning does in fact
   implement scaling.
  
  That's indeed one solution. The downside, compared to controls, is that a 
  sensor that implements binning, skipping and scaling would need to expose 3 
  entities, to let applications configure them 3 scalers independently. If 
  binning and skipping were implemented as controls (which might not be a 
  good 
  idea, I still haven't made up my mind on this), a single entity would 
  (probably) be enough.
 
 Different hardware may do these operations in a different order. Scaling
 should be the last, but I'm not sure if that holds for all hardware. The
 order will affect the end result, and likely also to user's decision on
 configuration.
 
 However, when one considers such decisions (s)he typically has otherwise a
 very good understanding of the hardware and thus knows the order of these
 operations.
 
 

Hmm, this was discussed already during the cropping/pipeline configuration
brainstorm:

http://www.spinics.net/lists/linux-media/msg34541.html

The suggestion was to add an S_FRAMESIZE ioctl to select one size in the
ENUM_FRAMESIZES list. Each size in that list defines a specific binning and
skipping combination. With S_FMT you can select the output size (and thus
the scaler if there is one).

This approach does not allow you to select whether you want binning or
skipping. It should select what gives the best results. If there is a
need to select between binning or skipping, then controls can be added
that select which approach should be used.

An alternative approach might be to add a flags field to struct
v4l2_frmsize_discrete that shows whether binning or skipping is used and
add the same flags to the S_FRAMESIZE ioctl.

Actually, I think that is nicer than adding more controls.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Migrate from soc_camera to v4l2

[Hans Verkuil]

On Friday, July 15, 2011 17:31:13 Guennadi Liakhovetski wrote:
 Hello Teresa
 
 On Fri, 15 Jul 2011, Teresa Gamez wrote:
 
  Hello Guennadi,
  
  Am Mittwoch, den 13.07.2011, 09:14 +0200 schrieb Guennadi Liakhovetski:
   On Wed, 13 Jul 2011, LBM wrote:
   
my dear Guennadi
 I'm wrong about that v4l2-int-device,maybe it just V4L2.  
   Now i have a board of OMAP3530 and a cmos camera MT9M111,so i 
want to get the image from the mt9m111.
 and ,I want to use the V4L2 API. But in the linux kernel 2.6.38,the 
driver of the mt9m111 is  a soc_camera.I see some thing about how to 
convert the soc_camera to V4L2,like soc-camera: (partially) convert to 
v4l2-(sub)dev API.
  Can you tell me how to migrate from soc_camera to v4l2,and
 or do you tell me some experience about that?
   
   Currently there's no standard way to make a driver to work with both 
   soc-camera and (pure) v4l2-subdev APIs. It is being worked on:
   
   http://www.spinics.net/lists/linux-media/msg34878.html
   
   and, hopefully, beginning with the next kernel version 3.1 it will become 
   at least theoretically possible. For now you just have to hack the driver 
   yourself for your local uses by removing all soc-camera specific code and 
   replacing it with your own glue, something along these lines:
  
  We are also interested in the support of the MT9M111 and MT9V022 for 
  OMAP-4460/OMAP-4430/OMAP-3525.
  I have not taken a deeper look at it yet. But what do you mean by 
  theoretically possible?
 
 By this I mean, that most important APIs, required for a proper 
 conversion, suitable for the mainline, should be in place by then. 
 Although there still might be one thing, preventing this: controls. 
 Unfortunately, it looks like Hans haven't found the time yet to submit a 
 new version of his soc-camera conversion to the new v4l2 control 
 framework, and even if he did, it would be very difficult for me ATM to 
 find time to review, merge and push it.

This has been delayed by discussions on how to handle autogain/gain-like
controls (and my vacation as well). As soon as that has been resolved I can
continue with this.

A tree with a fairly up-to-date control conversion is here:

http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/soc-camera

Missing is any support for the new control event, but that can wait until
the poll() changes are merged anyway.

 So, I'm not sure if it would be 
 possible to do a proper conversion without that, maybe not, then we'd 
 have to work on controls conversion too.

I'm pretty sure you need this.

Regards,

Hans

  Could it work out of the box? Or is there more work to do? 
 
 No, first the APIs have to be made compatible, then individual drivers 
 have to be converted one by one.
 
 Thanks
 Guennadi
 
  
  Regards,
  Teresa
  
   http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11691
   
   Thanks
   Guennadi
   ---
   Guennadi Liakhovetski, Ph.D.
   Freelance Open-Source Software Developer
   http://www.open-technology.de/
   --
   To unsubscribe from this list: send the line unsubscribe linux-media in
   the body of a message to majord...@vger.kernel.org
   More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
  
 
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] v4l: Move event documentation from SUBSCRIBE_EVENT to DQEVENT

[Hans Verkuil]

On Tuesday, July 19, 2011 15:38:06 Sakari Ailus wrote:
 Move documentation of structures used in DQEVENT from SUBSCRIBE_EVENT to
 DQEVENT.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi

Acked-by: Hans Verkuil hans.verk...@cisco.com

This is a much better place!

Regards,

Hans

 ---
  Documentation/DocBook/media/v4l/vidioc-dqevent.xml |  107 
 
  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  107 
 
  2 files changed, 107 insertions(+), 107 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
 b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 index 7769642..5200b68 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 @@ -135,6 +135,113 @@
/tgroup
  /table
  
 +table frame=none pgwide=1 id=v4l2-event-vsync
 +  titlestruct structnamev4l2_event_vsync/structname/title
 +  tgroup cols=3
 + cs-str;
 + tbody valign=top
 +   row
 + entry__u8/entry
 + entrystructfieldfield/structfield/entry
 + entryThe upcoming field. See v4l2-field;./entry
 +   /row
 + /tbody
 +  /tgroup
 +/table
 +
 +table frame=none pgwide=1 id=v4l2-event-ctrl
 +  titlestruct structnamev4l2_event_ctrl/structname/title
 +  tgroup cols=4
 + cs-str;
 + tbody valign=top
 +   row
 + entry__u32/entry
 + entrystructfieldchanges/structfield/entry
 + entry/entry
 + entryA bitmask that tells what has changed. See xref 
 linkend=changes-flags /./entry
 +   /row
 +   row
 + entry__u32/entry
 + entrystructfieldtype/structfield/entry
 + entry/entry
 + entryThe type of the control. See v4l2-ctrl-type;./entry
 +   /row
 +   row
 + entryunion (anonymous)/entry
 + entry/entry
 + entry/entry
 + entry/entry
 +   /row
 +   row
 + entry/entry
 + entry__s32/entry
 + entrystructfieldvalue/structfield/entry
 + entryThe 32-bit value of the control for 32-bit control types.
 + This is 0 for string controls since the value of a string
 + cannot be passed using VIDIOC-DQEVENT;./entry
 +   /row
 +   row
 + entry/entry
 + entry__s64/entry
 + entrystructfieldvalue64/structfield/entry
 + entryThe 64-bit value of the control for 64-bit control 
 types./entry
 +   /row
 +   row
 + entry__u32/entry
 + entrystructfieldflags/structfield/entry
 + entry/entry
 + entryThe control flags. See xref linkend=control-flags 
 /./entry
 +   /row
 +   row
 + entry__s32/entry
 + entrystructfieldminimum/structfield/entry
 + entry/entry
 + entryThe minimum value of the control. See 
 v4l2-queryctrl;./entry
 +   /row
 +   row
 + entry__s32/entry
 + entrystructfieldmaximum/structfield/entry
 + entry/entry
 + entryThe maximum value of the control. See 
 v4l2-queryctrl;./entry
 +   /row
 +   row
 + entry__s32/entry
 + entrystructfieldstep/structfield/entry
 + entry/entry
 + entryThe step value of the control. See v4l2-queryctrl;./entry
 +   /row
 +   row
 + entry__s32/entry
 + entrystructfielddefault_value/structfield/entry
 + entry/entry
 + entryThe default value value of the control. See 
 v4l2-queryctrl;./entry
 +   /row
 + /tbody
 +  /tgroup
 +/table
 +
 +table pgwide=1 frame=none id=changes-flags
 +  titleChanges/title
 +  tgroup cols=3
 + cs-def;
 + tbody valign=top
 +   row
 + entryconstantV4L2_EVENT_CTRL_CH_VALUE/constant/entry
 + entry0x0001/entry
 + entryThis control event was triggered because the value of the 
 control
 + changed. Special case: if a button control is pressed, then this
 + event is sent as well, even though there is not explicit value
 + associated with a button control./entry
 +   /row
 +   row
 + entryconstantV4L2_EVENT_CTRL_CH_FLAGS/constant/entry
 + entry0x0002/entry
 + entryThis control event was triggered because the control flags
 + changed./entry
 +   /row
 + /tbody
 +  /tgroup
 +/table
/refsect1
refsect1
  return-value;
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 69c0d8a..275be96 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -183,113 +183,6 @@
/tgroup
  /table
  
 -table frame=none pgwide=1 id=v4l2-event-vsync
 -  titlestruct structnamev4l2_event_vsync/structname/title
 -  tgroup cols=3
 - cs-str;
 - tbody 

Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

[Hans Verkuil]

Just some typos/documentation improvements:

On Wednesday, July 20, 2011 10:43:08 Guennadi Liakhovetski wrote:
 A possibility to preallocate and initialise buffers of different sizes
 in V4L2 is required for an efficient implementation of asnapshot mode.
 This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
 VIDIOC_PREPARE_BUF and defines respective data structures.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 
 It's been almost a month since v2, the only comments were a request to 
 increase the reserved space in the new ioctl() and to improve 
 documentation. The reserved field is increased in this version, 
 documentation also has been improved in multiple locations. I think, 
 documentation can be further improved at any time, but if there are no 
 objections against the actual contents of this patch, maybe we can commit 
 this version. I still don't see v3.0;-), so, maybe we even can push it for 
 3.1. A trivial comparison with v2 shows the size of the reserved field as 
 the only change in the API, and the compatibility fix as the only two 
 functional changes.
 
 v3: addressed multiple comments by Sakari Ailus
 
 1. increased reserved field in struct v4l2_create_buffers to 8 32-bit 
ints
 2. multiple documentation fixes and improvements
 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit compatibility 
processing
 
 v2:
 
 1. add preliminary Documentation
 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN
 3. remove VIDIOC_DESTROY_BUFS
 4. rename SUBMIT to VIDIOC_PREPARE_BUF
 5. add reserved field to struct v4l2_create_buffers
 6. cache handling flags moved to struct v4l2_buffer for processing during 
VIDIOC_PREPARE_BUF
 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument
 
 
  Documentation/DocBook/media/v4l/io.xml |   17 +++
  Documentation/DocBook/media/v4l/v4l2.xml   |2 +
  .../DocBook/media/v4l/vidioc-create-bufs.xml   |  152 
 
  .../DocBook/media/v4l/vidioc-prepare-buf.xml   |   96 
  drivers/media/video/v4l2-compat-ioctl32.c  |   68 -
  drivers/media/video/v4l2-ioctl.c   |   32 
  include/linux/videodev2.h  |   16 ++
  include/media/v4l2-ioctl.h |2 +
  8 files changed, 377 insertions(+), 8 deletions(-)
  create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
  create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
 
 diff --git a/Documentation/DocBook/media/v4l/io.xml 
 b/Documentation/DocBook/media/v4l/io.xml
 index 227e7ac..6249d0e 100644
 --- a/Documentation/DocBook/media/v4l/io.xml
 +++ b/Documentation/DocBook/media/v4l/io.xml
 @@ -927,6 +927,23 @@ ioctl is called./entry
  Applications set or clear this flag before calling the
  constantVIDIOC_QBUF/constant ioctl./entry
 /row
 +   row
 + 
 entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry
 + entry0x0400/entry
 + entryCaches do not have to be invalidated for this buffer.
 +Typically applications shall use this flag, if the data, captured in the 
 buffer

The two commas can be removed in the line above.

 +is not going to br touched by the CPU, instead the buffer will, probably, be

typo: br - be

 +passed on to a DMA-capable hardware unit for further processing or output.
 +/entry
 +   /row
 +   row
 + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry
 + entry0x0800/entry
 + entryCaches do not have to be cleaned for this buffer.
 +Typically applications shall use this flag for output buffers, if the data

Comma can be removed.

 +in this buffer has not been created by the CPU, but by some DMA-capable unit,

Comma before 'but' can be removed.

 +in which case caches have not been used./entry
 +   /row
   /tbody
/tgroup
  /table
 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
 b/Documentation/DocBook/media/v4l/v4l2.xml
 index 0d05e87..06bb179 100644
 --- a/Documentation/DocBook/media/v4l/v4l2.xml
 +++ b/Documentation/DocBook/media/v4l/v4l2.xml
 @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark
  sub-close;
  sub-ioctl;
  !-- All ioctls go here. --
 +sub-create-bufs;
  sub-cropcap;
  sub-dbg-g-chip-ident;
  sub-dbg-g-register;
 @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark
  sub-queryctrl;
  sub-query-dv-preset;
  sub-querystd;
 +sub-prepare-buf;
  sub-reqbufs;
  sub-s-hw-freq-seek;
  sub-streamon;
 diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml 
 b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
 new file mode 100644
 index 000..5f0158c
 --- /dev/null
 +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
 @@ -0,0 +1,152 @@
 +refentry id=vidioc-create-bufs
 +  refmeta
 +refentrytitleioctl VIDIOC_CREATE_BUFS/refentrytitle
 +manvol;
 +  

Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

[Hans Verkuil]

On Wednesday, July 20, 2011 17:19:46 Sakari Ailus wrote:
 On Wed, Jul 20, 2011 at 04:47:46PM +0200, Guennadi Liakhovetski wrote:
  On Wed, 20 Jul 2011, Sakari Ailus wrote:
  
   Hi, Guennadi!
   
   Thanks for the patch!
   
   On Wed, Jul 20, 2011 at 10:43:08AM +0200, Guennadi Liakhovetski wrote:
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of asnapshot mode.
This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

It's been almost a month since v2, the only comments were a request to 
increase the reserved space in the new ioctl() and to improve 
documentation. The reserved field is increased in this version, 
documentation also has been improved in multiple locations. I think, 
documentation can be further improved at any time, but if there are no 
objections against the actual contents of this patch, maybe we can 
commit 
this version. I still don't see v3.0;-), so, maybe we even can push it 
for 
3.1. A trivial comparison with v2 shows the size of the reserved field 
as 
the only change in the API, and the compatibility fix as the only two 
functional changes.

v3: addressed multiple comments by Sakari Ailus

1. increased reserved field in struct v4l2_create_buffers to 8 32-bit 
   ints
2. multiple documentation fixes and improvements
3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit 
compatibility 
   processing

v2:

1. add preliminary Documentation
2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN
3. remove VIDIOC_DESTROY_BUFS
4. rename SUBMIT to VIDIOC_PREPARE_BUF
5. add reserved field to struct v4l2_create_buffers
6. cache handling flags moved to struct v4l2_buffer for processing 
during 
   VIDIOC_PREPARE_BUF
7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument


 Documentation/DocBook/media/v4l/io.xml |   17 +++
 Documentation/DocBook/media/v4l/v4l2.xml   |2 +
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |  152 

 .../DocBook/media/v4l/vidioc-prepare-buf.xml   |   96 
 drivers/media/video/v4l2-compat-ioctl32.c  |   68 -
 drivers/media/video/v4l2-ioctl.c   |   32 
 include/linux/videodev2.h  |   16 ++
 include/media/v4l2-ioctl.h |2 +
 8 files changed, 377 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
 create mode 100644 
Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml

diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 227e7ac..6249d0e 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -927,6 +927,23 @@ ioctl is called./entry
 Applications set or clear this flag before calling the
 constantVIDIOC_QBUF/constant ioctl./entry
  /row
+ row
+   
entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry
+   entry0x0400/entry
+   entryCaches do not have to be invalidated for this buffer.
+Typically applications shall use this flag, if the data, captured in 
the buffer
+is not going to br touched by the CPU, instead the buffer will, 
probably, be
+passed on to a DMA-capable hardware unit for further processing or 
output.
+/entry
+ /row
+ row
+   
entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry
+   entry0x0800/entry
+   entryCaches do not have to be cleaned for this buffer.
+Typically applications shall use this flag for output buffers, if the 
data
+in this buffer has not been created by the CPU, but by some 
DMA-capable unit,
+in which case caches have not been used./entry
+ /row
/tbody
   /tgroup
 /table
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index 0d05e87..06bb179 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark
 sub-close;
 sub-ioctl;
 !-- All ioctls go here. --
+sub-create-bufs;
 sub-cropcap;
 sub-dbg-g-chip-ident;
 sub-dbg-g-register;
@@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark
 sub-queryctrl;
 sub-query-dv-preset;
 sub-querystd;
+sub-prepare-buf;
 

Re: [PATCH] adp1653: check platform_data before usage

[Sakari Ailus]

Hi, Andy!

On Mon, Jul 25, 2011 at 05:16:41PM +0300, Andy Shevchenko wrote:
 The driver requires platform_data to be present. That's why we need to check
 and fail in case of the absence of necessary data.
 
 Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/adp1653.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

Thanks for the patch. I'll add this to my next pull req.

 
 diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
 index be7befd..8ad89ff 100644
 --- a/drivers/media/video/adp1653.c
 +++ b/drivers/media/video/adp1653.c
 @@ -413,6 +413,10 @@ static int adp1653_probe(struct i2c_client *client,
   struct adp1653_flash *flash;
   int ret;
  
 + /* we couldn't work without platform data */
 + if (client-dev.platform_data == NULL)
 + return -ENODEV;
 +
   flash = kzalloc(sizeof(*flash), GFP_KERNEL);
   if (flash == NULL)
   return -ENOMEM;
 -- 
 1.7.5.4
 

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

[Sakari Ailus]

Hi Hans and Guennadi,

On Tue, Jul 26, 2011 at 01:05:29PM +0200, Hans Verkuil wrote:
 On Wednesday, July 20, 2011 17:19:46 Sakari Ailus wrote:
  On Wed, Jul 20, 2011 at 04:47:46PM +0200, Guennadi Liakhovetski wrote:
   On Wed, 20 Jul 2011, Sakari Ailus wrote:
   
Hi, Guennadi!

Thanks for the patch!

On Wed, Jul 20, 2011 at 10:43:08AM +0200, Guennadi Liakhovetski wrote:
 A possibility to preallocate and initialise buffers of different sizes
 in V4L2 is required for an efficient implementation of asnapshot mode.
 This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
 VIDIOC_PREPARE_BUF and defines respective data structures.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 
 It's been almost a month since v2, the only comments were a request 
 to 
 increase the reserved space in the new ioctl() and to improve 
 documentation. The reserved field is increased in this version, 
 documentation also has been improved in multiple locations. I think, 
 documentation can be further improved at any time, but if there are 
 no 
 objections against the actual contents of this patch, maybe we can 
 commit 
 this version. I still don't see v3.0;-), so, maybe we even can push 
 it for 
 3.1. A trivial comparison with v2 shows the size of the reserved 
 field as 
 the only change in the API, and the compatibility fix as the only two 
 functional changes.
 
 v3: addressed multiple comments by Sakari Ailus
 
 1. increased reserved field in struct v4l2_create_buffers to 8 
 32-bit 
ints
 2. multiple documentation fixes and improvements
 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit 
 compatibility 
processing
 
 v2:
 
 1. add preliminary Documentation
 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN
 3. remove VIDIOC_DESTROY_BUFS
 4. rename SUBMIT to VIDIOC_PREPARE_BUF
 5. add reserved field to struct v4l2_create_buffers
 6. cache handling flags moved to struct v4l2_buffer for processing 
 during 
VIDIOC_PREPARE_BUF
 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument
 
 
  Documentation/DocBook/media/v4l/io.xml |   17 +++
  Documentation/DocBook/media/v4l/v4l2.xml   |2 +
  .../DocBook/media/v4l/vidioc-create-bufs.xml   |  152 
 
  .../DocBook/media/v4l/vidioc-prepare-buf.xml   |   96 
 
  drivers/media/video/v4l2-compat-ioctl32.c  |   68 -
  drivers/media/video/v4l2-ioctl.c   |   32 
  include/linux/videodev2.h  |   16 ++
  include/media/v4l2-ioctl.h |2 +
  8 files changed, 377 insertions(+), 8 deletions(-)
  create mode 100644 
 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
  create mode 100644 
 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
 
 diff --git a/Documentation/DocBook/media/v4l/io.xml 
 b/Documentation/DocBook/media/v4l/io.xml
 index 227e7ac..6249d0e 100644
 --- a/Documentation/DocBook/media/v4l/io.xml
 +++ b/Documentation/DocBook/media/v4l/io.xml
 @@ -927,6 +927,23 @@ ioctl is called./entry
  Applications set or clear this flag before calling the
  constantVIDIOC_QBUF/constant ioctl./entry
 /row
 +   row
 + 
 entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry
 + entry0x0400/entry
 + entryCaches do not have to be invalidated for this buffer.
 +Typically applications shall use this flag, if the data, captured in 
 the buffer
 +is not going to br touched by the CPU, instead the buffer will, 
 probably, be
 +passed on to a DMA-capable hardware unit for further processing or 
 output.
 +/entry
 +   /row
 +   row
 + 
 entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry
 + entry0x0800/entry
 + entryCaches do not have to be cleaned for this buffer.
 +Typically applications shall use this flag for output buffers, if 
 the data
 +in this buffer has not been created by the CPU, but by some 
 DMA-capable unit,
 +in which case caches have not been used./entry
 +   /row
   /tbody
/tgroup
  /table
 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
 b/Documentation/DocBook/media/v4l/v4l2.xml
 index 0d05e87..06bb179 100644
 --- a/Documentation/DocBook/media/v4l/v4l2.xml
 +++ b/Documentation/DocBook/media/v4l/v4l2.xml
 @@ -462,6 +462,7 @@ and discussions on the V4L mailing 
 list./revremark
  sub-close;
  sub-ioctl;
  !-- All ioctls go here. --
 +sub-create-bufs;
  sub-cropcap;
  sub-dbg-g-chip-ident;
  

Re: [RFC 2/3] v4l: events: Define frame start event

[Hans Verkuil]

On Tuesday, July 19, 2011 15:38:07 Sakari Ailus wrote:
 Define a frame start event to tell user space when the reception of a frame
 starts.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   26 
 
  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   18 +
  include/linux/videodev2.h  |   12 +++--
  3 files changed, 53 insertions(+), 3 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
 b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 index 5200b68..d2cb8db 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
 @@ -88,6 +88,12 @@
 /row
 row
   entry/entry
 + entryv4l2-event-frame-sync;/entry
 +entrystructfieldframe/structfield/entry
 + entryEvent data for event V4L2_EVENT_FRAME_START./entry

The name of the struct and the event are not in sync (pardon the expression :-) 
).

Both should either be named FRAME_SYNC or FRAME_START.

 +   /row
 +   row
 + entry/entry
   entry__u8/entry
  entrystructfielddata/structfield[64]/entry
   entryEvent data. Defined by the event type. The union
 @@ -220,6 +226,26 @@
/tgroup
  /table
  
 +table frame=none pgwide=1 id=v4l2-event-frame-sync
 +  titlestruct structnamev4l2_event_frame_sync/structname/title
 +  tgroup cols=3
 + cs-str;
 + tbody valign=top
 +   row
 + entry__u32/entry
 + entrystructfieldbuffer_sequence/structfield/entry
 + entry
 +   The sequence number of the buffer to be handled next or
 +   currently handled by the driver.

So this refers to the sequence field in struct v4l2_buffer? Assuming it is,
then you definitely need to refer to that struct.

And to answer question 2 in the RFC: buffer_sequence is specific to this
event, and so belongs to a v4l2_event_frame_sync struct.

BTW, using 'id' to specify a specific line in the future seems reasonable to me.
Initially id is just set to 0, meaning the start of the frame.

Regards,

Hans

 + /entry
 +   /row
 + /tbody
 +  /tgroup
 +/table
 +
 +parav4l2-event-frame-sync; is associated with
 +constantV4L2_EVENT_FRAME_START/constant event./para
 +
  table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 275be96..7ec42bb 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -139,6 +139,24 @@
   /entry
 /row
 row
 + entryconstantV4L2_EVENT_FRAME_START/constant/entry
 + entry4/entry
 + entry
 +   paraTriggered immediately when the reception of a
 +   frame has begun. This event has a
 +   v4l2-event-frame-sync; associated with it./para
 +
 +   paraA driver will only generate this event when the
 +   hardware can generate it. This might not be the case
 +   e.g. when the hardware has no DMA buffer to write the
 +   image data to. In such cases the
 +   structfieldbuffer_sequence/structfield field in
 +   v4l2-event-frame-sync; will not be incremented either.
 +   This causes two consecutive buffer sequence numbers to
 +   have n times frame interval in between them./para
 + /entry
 +   /row
 +   row
   entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
   entry0x0800/entry
   entryBase event number for driver-private events./entry
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index fca24cc..4265102 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
  #define V4L2_EVENT_VSYNC 1
  #define V4L2_EVENT_EOS   2
  #define V4L2_EVENT_CTRL  3
 +#define V4L2_EVENT_FRAME_START   4
  #define V4L2_EVENT_PRIVATE_START 0x0800
  
  /* Payload for V4L2_EVENT_VSYNC */
 @@ -2032,12 +2033,17 @@ struct v4l2_event_ctrl {
   __s32 default_value;
  };
  
 +struct v4l2_event_frame_sync {
 + __u32 buffer_sequence;
 +};
 +
  struct v4l2_event {
   __u32   type;
   union {
 - struct v4l2_event_vsync vsync;
 - struct v4l2_event_ctrl  ctrl;
 - __u8data[64];
 + struct v4l2_event_vsync vsync;
 + struct v4l2_event_ctrl  ctrl;
 + struct v4l2_event_frame_syncframe_sync;
 + __u8

Re: driver problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition

[Doychin Dokov]

I'm having the same problem, on Ubuntu Server 11.04 x64, kernel 
2.6.38-10. I've also tried Debian with the same results. Here's the 
debug log from the Ubuntu installation:

[416830.888124] cx231xx #0: cx231xx #0/0: registered device video3 [v4l2]
[416830.888243] cx231xx #0: cx231xx #0/0: registered device vbi3
[416830.888251] cx231xx #0: V4L2 device registered as video3 and vbi3
[416830.888260] cx231xx #0: cx231xx-audio.c: probing for cx231xx non 
standard usbaudio

[416830.888684] cx231xx #0: EndPoint Addr 0x83, Alternate settings: 3
[416830.888695] cx231xx #0: Alternate setting 0, max size= 512
[416830.888703] cx231xx #0: Alternate setting 1, max size= 28
[416830.888710] cx231xx #0: Alternate setting 2, max size= 52
[416830.888720] cx231xx #0: EndPoint Addr 0x84, Alternate settings: 5
[416830.888728] cx231xx #0: Alternate setting 0, max size= 512
[416830.888735] cx231xx #0: Alternate setting 1, max size= 184
[416830.888742] cx231xx #0: Alternate setting 2, max size= 728
[416830.888749] cx231xx #0: Alternate setting 3, max size= 2892
[416830.888756] cx231xx #0: Alternate setting 4, max size= 1800
[416830.888763] cx231xx #0: EndPoint Addr 0x85, Alternate settings: 2
[416830.888771] cx231xx #0: Alternate setting 0, max size= 512
[416830.888778] cx231xx #0: Alternate setting 1, max size= 512
[416830.888786] cx231xx #0: EndPoint Addr 0x86, Alternate settings: 2
[416830.888794] cx231xx #0: Alternate setting 0, max size= 512
[416830.01] cx231xx #0: Alternate setting 1, max size= 576
[416830.890957] cx231xx #0 cx231xx_v4l2_open :open dev=video3 
type=vid-cap users

[416830.890975] cx231xx #0:  setPowerMode::mode = 48, No Change req.
[416830.890986] cx231xx #0 cx231xx_set_video_alternate 
:dev-video_mode.alt= 3
[416830.890996] cx231xx #0 cx231xx_set_video_alternate :minimum isoc 
packet size
[416830.891007] cx231xx #0 cx231xx_set_video_alternate :setting 
alternate 3 with

[416830.903131] cx231xx #0: cannot change alt number to 3 (error=-71)
[416830.906687] cx231xx #0: (pipe 0x80001280): IN:  c0 04 29 88 21 04 01 
00 FAIL
[416830.914736] cx231xx #0: UsbInterface::sendCommand, failed with 
status --71
[416830.914752] cx231xx #0: (pipe 0x80001200): OUT:  40 00 21 88 00 00 
03 00 
[416830.922983] cx231xx #0: UsbInterface::sendCommand, failed with 
status --71

[416830.923028] cx231xx #0 video: VIDIOC_QUERYCAP
[416830.923060] cx231xx #0 cx231xx_v4l2_open :open dev=vbi3 type=vbi-cap 
users=1

[416830.923089] cx231xx #0 vbi: VIDIOC_QUERYCAP
[416830.923123] cx231xx #0 cx231xx_v4l2_close :users=2
[416830.923128] cx231xx #0 cx231xx_v4l2_close :users=2
[416830.923181] cx231xx #0 cx231xx_v4l2_close :users=1
[416830.923188] cx231xx #0 cx231xx_v4l2_close :users=1
[416830.923199] cx231xx #0 cx231xx_uninit_isoc :cx231xx: called 
cx231xx_uninit_i

[416830.923208] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
[416830.923220] cx231xx #0: (pipe 0x80001280): IN:  c0 0d 0f 00 18 00 04 
00 FAIL
[416830.931259] cx231xx #0 cx231xx_set_alt_setting :setting alternate 0 
with wMa

[416830.939483] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71)

This is with the stock kernel, no media_build tree installed (I'm 
currently compiling it).




На 20.1.2011 г. 14:11 ч., Gerard Toonstra написа:

Hello,

I'm using a Hauppauge USB live2 video capture stick with Ubuntu 11.04,
netbook edition.
On Ubuntu 10.04, I pulled v4l from a development mercurial branch,
where cx231xx drivers were provided. That worked ok.

Ubuntu since then was upgraded to 10.10 with kernel 2.6.35, which is
where I couldn't use that branch anymore. Since the driver was
upstreamed,
I decided to give the media_build branch a go. I ran into problems
trying to compile media_build on 10.10, because that uses kernel
2.6.35,
and decided to upgrade to Ubuntu alpha 11.04, which uses kernel
2.6.37, so that the v4l would be better supported.

After deactivating two modules in .config that created some problems
in media_build, I was able to get a successful build and 'make
install'
them. After a reboot and sticking in the capture stick, tvtime, xawtv
or other applications do start, but only a black screen is the result.
The standard camera from the netbook itself does give output, so it's
not likely an overall video or X issue. I tried to remove the stick,
replug it back in,
replug it into different ports, start up with the stick already in,
but nothing worked. The output @ dmesg is always the same and repeats
itself infinitely.

dmesg and lsusb information is attached.

Further details:
- hardware: Siemens N210 netbook  (has another built-in camera @ /dev/video0)
- Ubuntu 11.04 netbook edition
- Linux 2.6.37-12-generic 32-bit i686 GNU/Linux  (stock kernel that
comes with Ubuntu 11.04)
- Code pulled from media_build.git, cloned yesterday
- Hauppauge USB Live2 video capture card, using cx231xx driver.


Are there any workarounds or quick patches available, or is the best
bet to revert to 10.04 for now?

Rgds,

--
Gerard Toonstra



--
To unsubscribe from this list: send 

Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

[Hans Verkuil]

On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote:
 Hi Hans and Guennadi,

snip

  I realized that it is not clear from the documentation whether it is 
  possible to call
  VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards.
 
 That's actually a must if one wants to release buffers. Currently no other
 method than requesting 0 buffers using REQBUFS is provided (apart from
 closing the file handle).

I was referring to the non-0 use-case :-)

  I can't remember whether the code allows it or not, but it should be 
  clearly documented.
 
 I would guess no user application would have to call REQBUFS with other than
 zero buffers when using CREATE_BUFS. This must be an exception if mixing
 REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a
 reason to prohibit either, but perhaps Guennadi has more informed opinion
 on this.
 
snip

 Future functionality which would be nice:
 
 - Format counters. Every format set by S_FMT (or gotten by G_FMT) 
 should
   come with a counter value so that the user would know the format of
   dequeued buffers when setting the format on-the-fly. Currently 
 there are
   only bytesperline and length, but the format can't be explicitly
   determined from those.
  
  Actually, the index field will give you that information. When you create 
  the
  buffers you know that range [index, index + count - 1] is associated with 
  that
  specific format.
 
 Some hardware is able to change the format while streaming is ongoing (for
 example: OMAP 3). The problem is that the user should be able to know which
 frame has the new format.

Ah, of course.

 Of course one could stop streaming but this would mean lost frames.
 
 A flag has been proposed to this previously. That's one option but forces
 the user to keep track of the changes since only one change is allowed until
 it has taken effect.

Something to discuss next week, I think.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: driver problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition

[Devin Heitmueller]

On Tue, Jul 26, 2011 at 7:53 AM, Doychin Dokov r...@net1.cc wrote:
 [416830.939483] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71)

 This is with the stock kernel, no media_build tree installed (I'm currently
 compiling it).

Patches for this issue were submitted over the weekend.  Check the
mailing list for posts from Saturday or wait a few days for the
patches to be merged into the linux_media tree.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: driver problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition

[Doychin Dokov]

На 26.7.2011 г. 15:17 ч., Devin Heitmueller написа:

On Tue, Jul 26, 2011 at 7:53 AM, Doychin Dokovr...@net1.cc  wrote:

[416830.939483] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71)

This is with the stock kernel, no media_build tree installed (I'm currently
compiling it).


Patches for this issue were submitted over the weekend.  Check the
mailing list for posts from Saturday or wait a few days for the
patches to be merged into the linux_media tree.



I find only the Sunday fix for the power ramp issue, which states it's 
for a problem caused by the config hz being different of 100. Is this 
the patch you point me to, and do you think it's the solution in my case?


# cat /boot/config-2.6.38-10-server | grep CONFIG_HZ
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100

Kind regards,
Doychin

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: driver problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition

[Devin Heitmueller]

On Tue, Jul 26, 2011 at 8:40 AM, Doychin Dokov r...@net1.cc wrote:
 I find only the Sunday fix for the power ramp issue, which states it's for a
 problem caused by the config hz being different of 100. Is this the patch
 you point me to, and do you think it's the solution in my case?

 # cat /boot/config-2.6.38-10-server | grep CONFIG_HZ
 CONFIG_HZ_100=y
 # CONFIG_HZ_250 is not set
 # CONFIG_HZ_300 is not set
 # CONFIG_HZ_1000 is not set
 CONFIG_HZ=100

There were actually two patches sent over the weekend, but the power
ramp issue was only for people who had CONFIG_HZ set to 1000.  In your
case, you only need the first patch.

See the email with subject: [PATCH] Fix regression introduced which
broke the Hauppauge USBLive 2 for the patch you need.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some comments on the new autocluster patches

[Hans de Goede]

Hi,

On 07/26/2011 11:26 AM, Hans Verkuil wrote:

OK, I'm back to work after my vacation, so it's time to go through the
backlog...



Welcome back :)


On Tuesday, July 12, 2011 15:25:02 Hans de Goede wrote:

Hi,

On 07/04/2011 11:43 AM, Hans Verkuil wrote:


snip snip


It is relevant. Take an application that saves the current state of all
controls and restores it the next time it is started. If you report the
device's autogain value instead of the manual gain, then that manual gain
value is lost. I consider this a major drawback.


If autogain is on, then the gain is RO, so it should not be saved. Let alone
restored.


Marking gain as inactive is fine, but marking it as read-only is not so clear.
Currently the RO flag is static. This allows control panels to use e.g. a text
field instead of an input field to show the value.

I would like to keep that functionality. If we make the RO flag dynamic, then
GUIs won't know whether to show it as a disabled input field or as a text field.

Whereas with the inactive flag they will know that it has to be a disabled
input field.



Agreed, where I wrote read only I meant inactive, which does make it less clear
that the control should not be saved / restored by a save / restore app.


When the inactive flag is set, it is still allowed to set the value. However,
if we add a volatile flag as well, then we may want to have the combination
'inactive and volatile' return an error when an application attempts to set the
value.


I think that is a good solution to indicate dynamic-readonly ness (more or 
less),
and thus to indicate that the control should not be written (and thus not saved/
restored).


Or is this too complex and should we just discard the value in a case like that?


I would prefer returning an error, so that things don't silently fail, also
unless we actually return an error many apps are likely to get this wrong.

snip snip


I still believe that everything boils down to 2 possible scenarios,
and the rest follows from that. With the 2 scenarios being:

1) There is a manual setting which is constant until explicitly
changed, when (ie) gain switches from auto mode to manual mode
then the actual used gain is reset to this manual setting

2) There is a single gain setting / register, which is r/w when the
control is in manual mode and ro when in auto mode. When auto mode
gets switched off, the gain stays at the last value set by auto mode.

2) Is what most webcam sensors (and the pwc firmware) implement at
the hardware level, and what to me also makes the most sense for webcams.

To me this whole discussion centers around these 2 scenarios, with you
being a proponent of 1), and I guess that for video capture boards 1 makes
a lot of sense, and me being a proponent of 2.

Proposal: lets agree that these 2 methods of handling autofoo controls
both exist and both have merits in certain cases, this means letting
it be up to the driver to choose which method to implement.


OK.


If we can agree on this, then the next step would be to document both
methods, as well as how the controls should behave in either scenario.
I'm willing to write up a first draft for this.


I can do that as well, see below.


Ah great, you just saved me some work I always like it when people
save me work :)

snip snip


I think we need to agree that we disagree :)


Actually, I agree with much of what you wrote :-)



Good :)


OK, so we have two scenarios:

1) There is a manual setting which is constant until explicitly changed, when 
e.g.
gain switches from auto mode to manual mode then the actual used gain is reset 
to
this manual setting.

In this case the e.g. gain control is *not* marked volatile, but just inactive.
If the hardware can return the gain as set by the autogain circuit, then that 
has
to be exported as a separate read-only control (e.g. 'Current Gain').


2) There is a single gain setting / register, which is active when the control 
is in
manual mode and inactive and volatile when in auto mode. When auto mode gets 
switched
off, the gain stays at the last value set by auto mode.

This scenario is only possible, of course, if you can obtain the gain value as 
set
by the autogain circuitry.



I fully agree with the above, +1


An open question is whether writing to an inactive and volatile control should 
return
an error or not.


I would prefer an error return.


Webcams should follow scenario 2 (if possible).

It is less obvious what to recommend for video capture devices. I'd leave it up 
to
the driver for now.


Sounds good to me.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/3] v4l: events: Define frame start event

[Sakari Ailus]

On Tue, Jul 26, 2011 at 01:52:44PM +0200, Hans Verkuil wrote:
 On Tuesday, July 19, 2011 15:38:07 Sakari Ailus wrote:
  Define a frame start event to tell user space when the reception of a frame
  starts.
  
  Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
  ---
   Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   26 
  
   .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   18 +
   include/linux/videodev2.h  |   12 +++--
   3 files changed, 53 insertions(+), 3 deletions(-)
  
  diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
  b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
  index 5200b68..d2cb8db 100644
  --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
  +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
  @@ -88,6 +88,12 @@
/row
row
  entry/entry
  +   entryv4l2-event-frame-sync;/entry
  +entrystructfieldframe/structfield/entry
  +   entryEvent data for event V4L2_EVENT_FRAME_START./entry
 
 The name of the struct and the event are not in sync (pardon the expression 
 :-) ).
 
 Both should either be named FRAME_SYNC or FRAME_START.

Should they be in sync? FRAME_START event is for frame start, not for other
purposes.

The buffer sequence number, however, could be used by other events, too.
This is directly related to the question of how to subscribe line-based
events. Albeit whether they are really ever needed is another question.

Getting _one_ event giving frame synchronisation timestamps is important,
however; that's also why I sent the RFC.

What I might do now is that we define a FRAME_SYNC (or FRAME_START) event
and specify the id == 0 always, and worry about the rest later on. It is
quite possible that line based events will never be needed.

If they are, then we must also specify how to subscribe them.

  + /row
  + row
  +   entry/entry
  entry__u8/entry
   entrystructfielddata/structfield[64]/entry
  entryEvent data. Defined by the event type. The union
  @@ -220,6 +226,26 @@
 /tgroup
   /table
   
  +table frame=none pgwide=1 id=v4l2-event-frame-sync
  +  titlestruct structnamev4l2_event_frame_sync/structname/title
  +  tgroup cols=3
  +   cs-str;
  +   tbody valign=top
  + row
  +   entry__u32/entry
  +   entrystructfieldbuffer_sequence/structfield/entry
  +   entry
  + The sequence number of the buffer to be handled next or
  + currently handled by the driver.
 
 So this refers to the sequence field in struct v4l2_buffer? Assuming it is,
 then you definitely need to refer to that struct.

Yes, it does.

 And to answer question 2 in the RFC: buffer_sequence is specific to this
 event, and so belongs to a v4l2_event_frame_sync struct.

Agreed.

 BTW, using 'id' to specify a specific line in the future seems reasonable to 
 me.
 Initially id is just set to 0, meaning the start of the frame.
 
 Regards,
 
   Hans
 
  +   /entry
  + /row
  +   /tbody
  +  /tgroup
  +/table
  +
  +parav4l2-event-frame-sync; is associated with
  +constantV4L2_EVENT_FRAME_START/constant event./para
  +
   table pgwide=1 frame=none id=changes-flags
 titleChanges/title
 tgroup cols=3
  diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
  b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
  index 275be96..7ec42bb 100644
  --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
  +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
  @@ -139,6 +139,24 @@
  /entry
/row
row
  +   entryconstantV4L2_EVENT_FRAME_START/constant/entry
  +   entry4/entry
  +   entry
  + paraTriggered immediately when the reception of a
  + frame has begun. This event has a
  + v4l2-event-frame-sync; associated with it./para
  +
  + paraA driver will only generate this event when the
  + hardware can generate it. This might not be the case
  + e.g. when the hardware has no DMA buffer to write the
  + image data to. In such cases the
  + structfieldbuffer_sequence/structfield field in
  + v4l2-event-frame-sync; will not be incremented either.
  + This causes two consecutive buffer sequence numbers to
  + have n times frame interval in between them./para
  +   /entry
  + /row
  + row
  entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
  entry0x0800/entry
  entryBase event number for driver-private events./entry
  diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
  index fca24cc..4265102 100644
  --- a/include/linux/videodev2.h
  +++ b/include/linux/videodev2.h
  @@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
   #define V4L2_EVENT_VSYNC   1
   #define V4L2_EVENT_EOS 2
   #define 

Re: [RFC 2/3] v4l: events: Define frame start event

[Hans Verkuil]

On Tuesday, July 26, 2011 15:51:26 Sakari Ailus wrote:
 On Tue, Jul 26, 2011 at 01:52:44PM +0200, Hans Verkuil wrote:
  On Tuesday, July 19, 2011 15:38:07 Sakari Ailus wrote:
   Define a frame start event to tell user space when the reception of a 
   frame
   starts.
   
   Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
   ---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   26 
   
.../DocBook/media/v4l/vidioc-subscribe-event.xml   |   18 +
include/linux/videodev2.h  |   12 +++--
3 files changed, 53 insertions(+), 3 deletions(-)
   
   diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
   b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
   index 5200b68..d2cb8db 100644
   --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
   +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
   @@ -88,6 +88,12 @@
   /row
   row
 entry/entry
   + entryv4l2-event-frame-sync;/entry
   +entrystructfieldframe/structfield/entry
   + entryEvent data for event V4L2_EVENT_FRAME_START./entry
  
  The name of the struct and the event are not in sync (pardon the expression 
  :-) ).
  
  Both should either be named FRAME_SYNC or FRAME_START.
 
 Should they be in sync? FRAME_START event is for frame start, not for other
 purposes.

Ah, you expect other events to reuse the same payload struct. I missed
that part.
 
 The buffer sequence number, however, could be used by other events, too.
 This is directly related to the question of how to subscribe line-based
 events. Albeit whether they are really ever needed is another question.
 
 Getting _one_ event giving frame synchronisation timestamps is important,
 however; that's also why I sent the RFC.
 
 What I might do now is that we define a FRAME_SYNC (or FRAME_START) event
 and specify the id == 0 always, and worry about the rest later on. It is
 quite possible that line based events will never be needed.

I would go for that.

 If they are, then we must also specify how to subscribe them.

Using 'id' as the line number seems sensible to me, but I would definitely
leave that part out for now. I am not convinced it is possible to use that
reliably in any case due to the difficult timing requirements.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/3] v4l: events: Define frame start event

[Sakari Ailus]

Thanks for your comments, Hans!

On Tue, Jul 26, 2011 at 03:59:38PM +0200, Hans Verkuil wrote:
 On Tuesday, July 26, 2011 15:51:26 Sakari Ailus wrote:
  On Tue, Jul 26, 2011 at 01:52:44PM +0200, Hans Verkuil wrote:
   On Tuesday, July 19, 2011 15:38:07 Sakari Ailus wrote:
Define a frame start event to tell user space when the reception of a 
frame
starts.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   26 

 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   18 +
 include/linux/videodev2.h  |   12 +++--
 3 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 5200b68..d2cb8db 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -88,6 +88,12 @@
  /row
  row
entry/entry
+   entryv4l2-event-frame-sync;/entry
+entrystructfieldframe/structfield/entry
+   entryEvent data for event V4L2_EVENT_FRAME_START./entry
   
   The name of the struct and the event are not in sync (pardon the 
   expression :-) ).
   
   Both should either be named FRAME_SYNC or FRAME_START.
  
  Should they be in sync? FRAME_START event is for frame start, not for other
  purposes.
 
 Ah, you expect other events to reuse the same payload struct. I missed
 that part.
  
  The buffer sequence number, however, could be used by other events, too.
  This is directly related to the question of how to subscribe line-based
  events. Albeit whether they are really ever needed is another question.
  
  Getting _one_ event giving frame synchronisation timestamps is important,
  however; that's also why I sent the RFC.
  
  What I might do now is that we define a FRAME_SYNC (or FRAME_START) event
  and specify the id == 0 always, and worry about the rest later on. It is
  quite possible that line based events will never be needed.
 
 I would go for that.

Ack.

  If they are, then we must also specify how to subscribe them.
 
 Using 'id' as the line number seems sensible to me, but I would definitely
 leave that part out for now. I am not convinced it is possible to use that
 reliably in any case due to the difficult timing requirements.

Ah, I momentarily forgot how this works on controls. :-)

I think FRAME_SYNC is better name since it's reusable in the future as well
so I choose that one and resend the set.

Cheers,

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some comments on the new autocluster patches

[Hans Verkuil]

On Tuesday, July 26, 2011 15:51:58 Hans de Goede wrote:

snip

  OK, so we have two scenarios:
 
  1) There is a manual setting which is constant until explicitly changed, 
  when e.g.
  gain switches from auto mode to manual mode then the actual used gain is 
  reset to
  this manual setting.
 
  In this case the e.g. gain control is *not* marked volatile, but just 
  inactive.
  If the hardware can return the gain as set by the autogain circuit, then 
  that has
  to be exported as a separate read-only control (e.g. 'Current Gain').
 
 
  2) There is a single gain setting / register, which is active when the 
  control is in
  manual mode and inactive and volatile when in auto mode. When auto mode 
  gets switched
  off, the gain stays at the last value set by auto mode.
 
  This scenario is only possible, of course, if you can obtain the gain value 
  as set
  by the autogain circuitry.
 
 
 I fully agree with the above, +1
 
  An open question is whether writing to an inactive and volatile control 
  should return
  an error or not.
 
 I would prefer an error return.

I am worried about backwards compatibility, though. Right now inactive controls
can be written safely. Suddenly you add the volatile flag and doing the same 
thing
causes an error.

Also, a program that saves control values will have to skip any control that:

1) Is read or write only
2) Is inactive and volatile

The first is obvious, but the second not so much.

Another reason for not returning an error is that it makes v4l2-ctrls.c more 
complex: if
autogain is on and I call VIDIOC_S_EXT_CTRLS to set autogain to off and gain to 
a new
manual value, then it is quite difficult to detect that in this case setting 
gain is OK
(since autogain is turned off at the same time).

The more I think about it, the more I think this should just be allowed. The 
value
disappears into a black hole, but at least it won't break any apps.

Regards,

Hans

 
  Webcams should follow scenario 2 (if possible).
 
  It is less obvious what to recommend for video capture devices. I'd leave 
  it up to
  the driver for now.
 
 Sounds good to me.
 
 Regards,
 
 Hans
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some comments on the new autocluster patches

[Hans de Goede]

Hi,

On 07/26/2011 04:19 PM, Hans Verkuil wrote:

On Tuesday, July 26, 2011 15:51:58 Hans de Goede wrote:



snip


An open question is whether writing to an inactive and volatile control should 
return
an error or not.


I would prefer an error return.


I am worried about backwards compatibility, though. Right now inactive controls
can be written safely. Suddenly you add the volatile flag and doing the same 
thing
causes an error.

Also, a program that saves control values will have to skip any control that:

1) Is read or write only
2) Is inactive and volatile

The first is obvious, but the second not so much.

Another reason for not returning an error is that it makes v4l2-ctrls.c more 
complex: if
autogain is on and I call VIDIOC_S_EXT_CTRLS to set autogain to off and gain to 
a new
manual value, then it is quite difficult to detect that in this case setting 
gain is OK
(since autogain is turned off at the same time).

The more I think about it, the more I think this should just be allowed. The 
value
disappears into a black hole, but at least it won't break any apps.


Ok disappear into a black hole it is :)

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] V4L2 brainstorming meeting in Cambridge, August 2011

[Laurent Pinchart]

Hi Sakari,

On Tuesday 26 July 2011 10:52:16 Sakari Ailus wrote:
 On Fri, Jun 17, 2011 at 10:56:11AM +0200, Laurent Pinchart wrote:
  Hello everybody,
 
 Hi Laurent and all others,
 
  Following our (not so) long-standing tradition of V4L2 brainstorming
  meetings, I would like to propose Cambridge, UK as a possible location
  for the next brainstorming session on the first week of August (1st to
  5th).
  
  Linaro developers will gather for a one-week sprint session at the same
  time and place, and they will have a 3 half-day graphics summit where
  graphic memory management will be discussed
  (https://wiki.linaro.org/Events/2011-08- LDS/Schedule). Collocating the
  V4L2 brainstorming meeting with the Linaro sprint would allow those of
  us who are interested in both topics to attend the Linaro graphics
  summit as well.
  
  Topics to be discussed include pipeline configuration and per-frame
  configuration. Other topics can be proposed as well, but this should be
  enough to fill our usual 3 days agenda.
 
 What about sub-subdevs? Or is everything concerning them clear? :-)

Please see the meeting's agenda I've just posted :-)

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix regression introduced which broke the Hauppauge USBLive 2

[Doychin Dokov]

На 24.7.2011 г. 04:17 ч., Devin Heitmueller написа:

The following patch addresses the regression introduced in the cx231xx
driver which stopped the Hauppauge USBLive2 from working.

Confirmed working by both myself and the user who reported the issue
on the KernelLabs blog (Robert DeLuca).



I can also confirm this patch works fine for me.

[  839.052752] cx231xx: Cx231xx Audio Extension initialized
[  850.221325] cx231xx #0: cx231xx_start_stream():: ep_mask = 4
[  850.224774] cx231xx #0: cx231xx_init_audio_isoc: Starting ISO AUDIO 
transfers

[  851.150358] cx231xx #0: cx231xx_stop_stream():: ep_mask = 4

It was not possible to capture audio from the device before that.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANN] Agenda for the Cambourne meeting

[Laurent Pinchart]

On Tuesday 26 July 2011 16:47:18 Laurent Pinchart wrote:
 Agenda for V4L2 brainstorm meeting in Cambourne, August 1-5 2011
 

[snip]

 *Attendees*
 
 Cisco Systems Norway:
   Hans Verkuil (Chair) hverk...@xs4all.nl

Copy and paste can be bad. I'm the meeting's chair this time. Sorry Hans for 
worrying you :-)

 Ideas On Board:
   Laurent Pinchart laurent.pinch...@ideasonboard.com
 
 Intel:
   Tuukka Toivonen tuukka.toivo...@intel.com
 
 Nokia:
   Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 
 Samsung Poland RD Center:
   Sylwester Nawrocki s.nawro...@samsung.com
   Tomasz Stanislawski t.stanisl...@samsung.com

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] imon: don't parse scancodes until intf configured

[Jarod Wilson]

Chris W wrote:

On 20/07/11 23:18, Jarod Wilson wrote:

On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote:

On 20/07/11 02:12, Jarod Wilson wrote:

The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon context's rc_dev pointer is filled in, which is
necessary for imon 0xffdc device auto-detection to work properly, but
we need to make sure we don't actually run the callback routines until
we've entirely filled in the necessary bits for each given interface,
lest we wind up oopsing. Technically, any imon device could have hit
this, but the issue is exacerbated on the 0xffdc devices, which send a
constant stream of interrupts, even when they have no valid key data.



OK.  The patch applies and everything continues to work.   There is no
obvious difference in the dmesg output on module load, with my device
remaining unidentified.  I don't know if that is indicative of anything.

Did you apply this patch on top of the earlier patch, or instead of it?


On top of it.   I've reversed the patches and installed just the last
one with this result on loading the module:

input: iMON Panel, Knob and Mouse(15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input8
imon 4-2:1.0: 0xffdc iMON VFD, iMON IR (id 0x24)
Registered IR keymap rc-imon-pad
input: iMON Remote (15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input9
rc3: iMON Remote (15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3
imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3  initialized
usbcore: registered new interface driver imon

Much better.


Yeah, that looks sane now. We missed 3.0, but I'll try to flag this one 
to go into the various stable trees when it gets merged for 3.1.




intf0 decoded packet: 00 00 00 00 00 00 24 01
intf0 decoded packet: 00 00 00 00 00 00 24 01
intf0 decoded packet: 00 00 00 00 00 00 24 01

One other amusing tidbit: you get continuous spew like the above, because
to date, I thought all the ffdc devices had nothing to report spew that
started with 0xff, which we filter out. Sigh. I hate imon hardware...


I am beginning to understand why. That output was only printed with the
debug=1 option and is not printed with the patched module.


Yup. The additional filtering was added because my own ffdc imon devices 
were so noisy, it was next to impossible to see what was going on when 
trying to debug anything.



--
Jarod Wilson
ja...@redhat.com


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

v4l-utils: rds-saa6588 doesn't compile if i2c-tools is installed

[Frédéric L . W . Meunier]

Not sure if it's the right place to report it.

At least here, v4l-utils doesn't compile if i2c-tools is installed, 
because the latter installs a i2c-dev.h, like the kernel does with make 
headers_install, but which is incompatible if used with i2c.h.


While rds-saa6588 isn't installed by default, it's compiled, and aborts:

In file included from rds-saa6588.c:16:0:
/usr/local/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg'
/usr/include/linux/i2c.h:67:8: note: originally defined here
/usr/local/include/linux/i2c-dev.h:90:7: error: redefinition of 'union 
i2c_smbus_data'
/usr/include/linux/i2c.h:125:7: note: originally defined here

The same would happen if i2c-tools was installed in /usr, overwriting 
the kernel header.


I think that a fix would be something like the following, which worked 
in all scenarios for me:


diff -urN rds.old/Makefile rds/Makefile
--- rds.old/Makefile2011-07-17 13:06:39.0 -0300
+++ rds/Makefile2011-07-26 15:15:31.0 -0300
@@ -1,5 +1,7 @@
 TARGETS = rds-saa6588

+override CPPFLAGS += -DLINUX_I2C_DEV_H
+
 all: $(TARGETS)

 -include *.d
diff -urN rds.old/rds-saa6588.c rds/rds-saa6588.c
--- rds.old/rds-saa6588.c   2011-07-17 13:06:39.0 -0300
+++ rds/rds-saa6588.c   2011-07-26 15:16:13.0 -0300
@@ -12,8 +12,12 @@
 #include errno.h
 #include sys/ioctl.h
 #include linux/types.h
+#ifdef LINUX_I2C_DEV_H
+#include linux/i2c-dev.h
+#else
 #include linux/i2c.h
 #include linux/i2c-dev.h
+#endif

 int debug;

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Frame synchronisation events and support for them in the OMAP 3 ISP driver

[Sakari Ailus]

Hi all,

The OMAP 3 ISP driver implements an HS_VS event which is triggered when
the reception of a frame begins. This functionality is very, very likely
not specific to OMAP 3 ISP so it should be standardised.

I have a few patches to do that. Additionally the next expected buffer
sequence number is provided with the event, unlike earlier.

The questions I had over the RFC (under otherwise same subject field on
this list) have been resolved:

1) Other frame synchronisation events, if they ever are needed, can be
implemented by using the id field as the line number the event should be
triggered on, as proposed by Sylwester and Hans. Currently, the id field
is not separately mentioned in the documentation, meaning that
FRAME_SYNC events have id field set to 0 meaning frame start.

2) It was also concluded that the buffer sequence number is specific to
FRAME_SYNC event and deserves its own struct: struct v4l2_event_frame_sync.

Changes to the RFC:

- Renamed V4L2_EVENT_FRAME_START to V4L2_EVENT_FRAME_SYNC.
- Removed extra reference to V4L2_EVENT_FRAME_START in documentation; it
is mentioned in the same page struct v4l2_event_frame_sync is related to it.
- The OMAP 3 ISP driver check that the id field is zero in anticipation
of such events.

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] v4l: Move event documentation from SUBSCRIBE_EVENT to DQEVENT

[Sakari Ailus]

Move documentation of structures used in DQEVENT from SUBSCRIBE_EVENT to
DQEVENT.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |  107 
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |  107 
 2 files changed, 107 insertions(+), 107 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 7769642..5200b68 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -135,6 +135,113 @@
   /tgroup
 /table
 
+table frame=none pgwide=1 id=v4l2-event-vsync
+  titlestruct structnamev4l2_event_vsync/structname/title
+  tgroup cols=3
+   cs-str;
+   tbody valign=top
+ row
+   entry__u8/entry
+   entrystructfieldfield/structfield/entry
+   entryThe upcoming field. See v4l2-field;./entry
+ /row
+   /tbody
+  /tgroup
+/table
+
+table frame=none pgwide=1 id=v4l2-event-ctrl
+  titlestruct structnamev4l2_event_ctrl/structname/title
+  tgroup cols=4
+   cs-str;
+   tbody valign=top
+ row
+   entry__u32/entry
+   entrystructfieldchanges/structfield/entry
+   entry/entry
+   entryA bitmask that tells what has changed. See xref 
linkend=changes-flags /./entry
+ /row
+ row
+   entry__u32/entry
+   entrystructfieldtype/structfield/entry
+   entry/entry
+   entryThe type of the control. See v4l2-ctrl-type;./entry
+ /row
+ row
+   entryunion (anonymous)/entry
+   entry/entry
+   entry/entry
+   entry/entry
+ /row
+ row
+   entry/entry
+   entry__s32/entry
+   entrystructfieldvalue/structfield/entry
+   entryThe 32-bit value of the control for 32-bit control types.
+   This is 0 for string controls since the value of a string
+   cannot be passed using VIDIOC-DQEVENT;./entry
+ /row
+ row
+   entry/entry
+   entry__s64/entry
+   entrystructfieldvalue64/structfield/entry
+   entryThe 64-bit value of the control for 64-bit control 
types./entry
+ /row
+ row
+   entry__u32/entry
+   entrystructfieldflags/structfield/entry
+   entry/entry
+   entryThe control flags. See xref linkend=control-flags 
/./entry
+ /row
+ row
+   entry__s32/entry
+   entrystructfieldminimum/structfield/entry
+   entry/entry
+   entryThe minimum value of the control. See 
v4l2-queryctrl;./entry
+ /row
+ row
+   entry__s32/entry
+   entrystructfieldmaximum/structfield/entry
+   entry/entry
+   entryThe maximum value of the control. See 
v4l2-queryctrl;./entry
+ /row
+ row
+   entry__s32/entry
+   entrystructfieldstep/structfield/entry
+   entry/entry
+   entryThe step value of the control. See v4l2-queryctrl;./entry
+ /row
+ row
+   entry__s32/entry
+   entrystructfielddefault_value/structfield/entry
+   entry/entry
+   entryThe default value value of the control. See 
v4l2-queryctrl;./entry
+ /row
+   /tbody
+  /tgroup
+/table
+
+table pgwide=1 frame=none id=changes-flags
+  titleChanges/title
+  tgroup cols=3
+   cs-def;
+   tbody valign=top
+ row
+   entryconstantV4L2_EVENT_CTRL_CH_VALUE/constant/entry
+   entry0x0001/entry
+   entryThis control event was triggered because the value of the 
control
+   changed. Special case: if a button control is pressed, then this
+   event is sent as well, even though there is not explicit value
+   associated with a button control./entry
+ /row
+ row
+   entryconstantV4L2_EVENT_CTRL_CH_FLAGS/constant/entry
+   entry0x0002/entry
+   entryThis control event was triggered because the control flags
+   changed./entry
+ /row
+   /tbody
+  /tgroup
+/table
   /refsect1
   refsect1
 return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 69c0d8a..275be96 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -183,113 +183,6 @@
   /tgroup
 /table
 
-table frame=none pgwide=1 id=v4l2-event-vsync
-  titlestruct structnamev4l2_event_vsync/structname/title
-  tgroup cols=3
-   cs-str;
-   tbody valign=top
- row
-   entry__u8/entry
-   

[PATCH 2/3] v4l: events: Define frame start event

[Sakari Ailus]

Define a frame start event to tell user space when the reception of a frame
starts.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   23 
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   18 +++
 include/linux/videodev2.h  |   12 +++--
 3 files changed, 50 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 5200b68..1d03313 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -88,6 +88,12 @@
  /row
  row
entry/entry
+   entryv4l2-event-frame-sync;/entry
+entrystructfieldframe/structfield/entry
+   entryEvent data for event V4L2_EVENT_FRAME_SYNC./entry
+ /row
+ row
+   entry/entry
entry__u8/entry
 entrystructfielddata/structfield[64]/entry
entryEvent data. Defined by the event type. The union
@@ -220,6 +226,23 @@
   /tgroup
 /table
 
+table frame=none pgwide=1 id=v4l2-event-frame-sync
+  titlestruct structnamev4l2_event_frame_sync/structname/title
+  tgroup cols=3
+   cs-str;
+   tbody valign=top
+ row
+   entry__u32/entry
+   entrystructfieldbuffer_sequence/structfield/entry
+   entry
+ The sequence number of the buffer to be handled next or
+ currently handled by the driver.
+   /entry
+ /row
+   /tbody
+  /tgroup
+/table
+
 table pgwide=1 frame=none id=changes-flags
   titleChanges/title
   tgroup cols=3
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 275be96..812b63c 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -139,6 +139,24 @@
/entry
  /row
  row
+   entryconstantV4L2_EVENT_FRAME_SYNC/constant/entry
+   entry4/entry
+   entry
+ paraTriggered immediately when the reception of a
+ frame has begun. This event has a
+ v4l2-event-frame-sync; associated with it./para
+
+ paraA driver will only generate this event when the
+ hardware can generate it. This might not be the case
+ e.g. when the hardware has no DMA buffer to write the
+ image data to. In such cases the
+ structfieldbuffer_sequence/structfield field in
+ v4l2-event-frame-sync; will not be incremented either.
+ This causes two consecutive buffer sequence numbers to
+ have n times frame interval in between them./para
+   /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..056a49e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2006,6 +2006,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_VSYNC   1
 #define V4L2_EVENT_EOS 2
 #define V4L2_EVENT_CTRL3
+#define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
@@ -2032,12 +2033,17 @@ struct v4l2_event_ctrl {
__s32 default_value;
 };
 
+struct v4l2_event_frame_sync {
+   __u32 buffer_sequence;
+};
+
 struct v4l2_event {
__u32   type;
union {
-   struct v4l2_event_vsync vsync;
-   struct v4l2_event_ctrl  ctrl;
-   __u8data[64];
+   struct v4l2_event_vsync vsync;
+   struct v4l2_event_ctrl  ctrl;
+   struct v4l2_event_frame_syncframe_sync;
+   __u8data[64];
} u;
__u32   pending;
__u32   sequence;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] omap3isp: ccdc: Make frame start event generic

[Sakari Ailus]

The ccdc block in the omap3isp produces frame start events. These events
were previously specific to the omap3isp. Make them generic.

Also add sequence number to the frame. This is stored to the id field.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
 Documentation/video4linux/omap3isp.txt |9 +
 drivers/media/video/omap3isp/ispccdc.c |   11 +--
 include/linux/omap3isp.h   |2 --
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/video4linux/omap3isp.txt 
b/Documentation/video4linux/omap3isp.txt
index 69be2c7..5dd1439 100644
--- a/Documentation/video4linux/omap3isp.txt
+++ b/Documentation/video4linux/omap3isp.txt
@@ -70,10 +70,11 @@ Events
 The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
 statistics (AEWB, AF and histogram) subdevs.
 
-The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS
-interrupt which is used to signal frame start. The event is triggered exactly
-when the reception of the first line of the frame starts in the CCDC module.
-The event can be subscribed on the CCDC subdev.
+The CCDC subdev produces V4L2_EVENT_FRAME_SYNC type event on HS_VS
+interrupt which is used to signal frame start. Earlier version of this
+driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is
+triggered exactly when the reception of the first line of the frame starts
+in the CCDC module. The event can be subscribed on the CCDC subdev.
 
 (When using parallel interface one must pay account to correct configuration
 of the VS signal polarity. This is automatically correct when using the serial
diff --git a/drivers/media/video/omap3isp/ispccdc.c 
b/drivers/media/video/omap3isp/ispccdc.c
index 6766247..842a930 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1402,11 +1402,14 @@ static int __ccdc_handle_stopping(struct 
isp_ccdc_device *ccdc, u32 event)
 
 static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
 {
+   struct isp_pipeline *pipe =
+   to_isp_pipeline(ccdc-video_out.video.entity);
struct video_device *vdev = ccdc-subdev.devnode;
struct v4l2_event event;
 
memset(event, 0, sizeof(event));
-   event.type = V4L2_EVENT_OMAP3ISP_HS_VS;
+   event.type = V4L2_EVENT_FRAME_SYNC;
+   event.u.frame_sync.buffer_sequence = atomic_read(pipe-frame_number);
 
v4l2_event_queue(vdev, event);
 }
@@ -1688,7 +1691,11 @@ static long ccdc_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
 static int ccdc_subscribe_event(struct v4l2_subdev *sd, struct v4l2_fh *fh,
struct v4l2_event_subscription *sub)
 {
-   if (sub-type != V4L2_EVENT_OMAP3ISP_HS_VS)
+   if (sub-type != V4L2_EVENT_FRAME_SYNC)
+   return -EINVAL;
+
+   /* line number is zero at frame start */
+   if (sub-id != 0)
return -EINVAL;
 
return v4l2_event_subscribe(fh, sub, OMAP3ISP_CCDC_NEVENTS);
diff --git a/include/linux/omap3isp.h b/include/linux/omap3isp.h
index b6111f8..c73a34c 100644
--- a/include/linux/omap3isp.h
+++ b/include/linux/omap3isp.h
@@ -62,14 +62,12 @@
  * V4L2_EVENT_OMAP3ISP_AEWB: AEWB statistics data ready
  * V4L2_EVENT_OMAP3ISP_AF: AF statistics data ready
  * V4L2_EVENT_OMAP3ISP_HIST: Histogram statistics data ready
- * V4L2_EVENT_OMAP3ISP_HS_VS: Horizontal/vertical synchronization detected
  */
 
 #define V4L2_EVENT_OMAP3ISP_CLASS  (V4L2_EVENT_PRIVATE_START | 0x100)
 #define V4L2_EVENT_OMAP3ISP_AEWB   (V4L2_EVENT_OMAP3ISP_CLASS | 0x1)
 #define V4L2_EVENT_OMAP3ISP_AF (V4L2_EVENT_OMAP3ISP_CLASS | 0x2)
 #define V4L2_EVENT_OMAP3ISP_HIST   (V4L2_EVENT_OMAP3ISP_CLASS | 0x3)
-#define V4L2_EVENT_OMAP3ISP_HS_VS  (V4L2_EVENT_OMAP3ISP_CLASS | 0x4)
 
 struct omap3isp_stat_event_status {
__u32 frame_number;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/1] libv4l: Add plugin support to libv4l

[Sakari Ailus]

On Sun, Jul 24, 2011 at 07:36:38PM +0200, Hans de Goede wrote:
 Hi,
 
 On 07/22/2011 05:39 PM, Yordan Kamenov wrote:
 Hi Hans,
 
 Hans de Goede wrote:
 Hi,
 
 Sorry it took so long, but I've just merged the plugin
 support into v4l-utils git. I did make some minor mods /
 bugfixes before merging, see the commit message in git.
 
 Regards,
 
 Hans
 
 p.s.
 
 I think we should expand the plugin support with support
 for a output devices, iow add a write() dev_op. If you
 guys agree I can easily do so myself, we should do this
 asap before people start depending on the ABI
 (although there is no ABI stability promise until I
 release 0.10.x, see my message to the list wrt
 the start of the 0.9.x cycle).
 
 
 I think that it is a good point, you can add write() and
 reserved dev_ops.
 
 Ok, done, this is in v4l-utils git master now.

Wow! Thanks, Hans and Yordan! :-)

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Camera Support

[Sriram V]

Hi,
  OMAP3 ISP Supports 2 camera ports (csi and parallel) Does the
existing ISP drivers
  support both of them at the same time.


Regards,
sriram
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Parallel CMOS Image Sensor with UART Control Interface

[Sakari Ailus]

On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote:
 Dear all,
 
 Does anyone came across a v4l2 Linux Device Driver for an Image Sensor
 that uses Parallel CMOS H/V and can only be control by UART interface
 instead of the common I2C or SPI interface?
 
 A similar sensor is the STMicroelectronics VL5510 Image Sensor
 although it support all 3 types of control interface.
 (http://www.st.com/internet/automotive/product/178477.jsp)
 
 Most or all the drivers found I found under drivers/media/video uses
 the I2C or SPI interface instead
 
 I'm new to writing driver and need a reference v4l2 driver for this
 type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo
 board.
 
 I just need a very simple v4l2 driver that can extract the image from
 the sensor and control over it via the UART control interface.
 
 Any help is very much appreciated.

Hi James,

I think there has been a recent discussion on a similar topic under the
subject RE: FW: OMAP 3 ISP. The way to do this would be to implement
platform subdevs in V4L2 core, which I think we don't have quite yet.

Cc Laurent and Michael.

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Camera Support

[Sakari Ailus]

On Wed, Jul 27, 2011 at 12:53:44AM +0530, Sriram V wrote:
 Hi,
   OMAP3 ISP Supports 2 camera ports (csi and parallel) Does the
 existing ISP drivers
   support both of them at the same time.

As far as I can see, the answer is yes. However, the CCDC block implements
the parallel receiver, so the image processing functions of the ISP wouldn't
be available for the data received from the CSI(2) receiver when the
parallel interface is in use.

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Parallel CMOS Image Sensor with UART Control Interface

[James]

On Wed, Jul 27, 2011 at 3:40 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
 On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote:
 Dear all,

 Does anyone came across a v4l2 Linux Device Driver for an Image Sensor
 that uses Parallel CMOS H/V and can only be control by UART interface
 instead of the common I2C or SPI interface?

 A similar sensor is the STMicroelectronics VL5510 Image Sensor
 although it support all 3 types of control interface.
 (http://www.st.com/internet/automotive/product/178477.jsp)

 Most or all the drivers found I found under drivers/media/video uses
 the I2C or SPI interface instead

 I'm new to writing driver and need a reference v4l2 driver for this
 type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo
 board.

 I just need a very simple v4l2 driver that can extract the image from
 the sensor and control over it via the UART control interface.

 Any help is very much appreciated.

 Hi James,

 I think there has been a recent discussion on a similar topic under the
 subject RE: FW: OMAP 3 ISP. The way to do this would be to implement
 platform subdevs in V4L2 core, which I think we don't have quite yet.

 Cc Laurent and Michael.

 --
 Sakari Ailus
 sakari.ai...@iki.fi


Hi Sakari,

Thanks for pointing me to the discussion thread.

I found it from the archive at
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32700/focus=32721

I read through the threads and see that I'm indeed in similar
situation with Alex.

We both have sensor that output CMOS H/V image and only have
UART/RS232 for control of the sensor operations via sending/reading
packet of bytes. i.e. AGC, contrast, brightness etc..

Since the thread ended on 29-Jun, is there anymore update or information?

As I've a MT9V032 camera with Gusmtix Overo, I was hoping to rely on
the MT9V032 driver as a starting point and adapt it for the VL5510
sensor using only the UART interface.

Thanks in adv.

-- 
Regards,
James
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html