Re: Kconfig changes in /hg/v4l-dvb caused dvb_usb_cxusb to stop building

[VDR User]

On Sun, Mar 8, 2009 at 6:07 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 It won't mark they with M, if you keep enabling DVB_FE_CUSTOMISE, since this
 Kconfig var allows manual override over the frontend modules.

Ok, tried again and it's as you said.  I assumed the behavior of
DVB_FE_CUSTOMISE hadn't changed but it appears it has.  Although, I
think the previous behavior is still better having the required
modules as locked -M-.  At least then the user has some kind of
control over what modules are built without risk of disabling
something he needs.  What was the logic behind making this change?

That's one thing I don't understand... Why an os that prides itself on
user-customization seems to always be introducing ways to limit the
user.

Anyways, here's what I get:

$ grep ^CONFIG .config
CONFIG_INPUT=y
CONFIG_USB=y
CONFIG_SND=y
CONFIG_I2C_ALGOBIT=y
CONFIG_INET=y
CONFIG_CRC32=y
CONFIG_SYSFS=y
CONFIG_PCI=y
CONFIG_VIRT_TO_BUS=y
CONFIG_NET=y
CONFIG_I2C=y
CONFIG_STANDALONE=y
CONFIG_MODULES=y
CONFIG_HAS_IOMEM=y
CONFIG_PROC_FS=y
CONFIG_HAS_DMA=y
CONFIG_SND_PCM=y
CONFIG_EXPERIMENTAL=y
CONFIG_IEEE1394=y
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_DVB_CORE=m
CONFIG_VIDEO_MEDIA=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_DVB_DYNAMIC_MINORS=y
CONFIG_DVB_CAPTURE_DRIVERS=y
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_STV0299=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_SP8870=m
CONFIG_DVB_L64781=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_STV0297=m
CONFIG_DVB_LNBP21=m
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Hans Verkuil]

On Monday 09 March 2009 02:07:33 Trent Piepho wrote:
 On Sun, 8 Mar 2009, Hans Verkuil wrote:
  The last one fixes an ivtv regression caused by this change:
 
  changeset:   10811:0a0eba8e64d5
  user:Trent Piepho xy...@speakeasy.org
  date:Tue Mar 03 20:21:02 2009 -0800
  summary: videodev: only copy needed part of RW ioctl's parameter
 
  The fix is simple: switch on the full ioctl command instead of just the
  NR field.
 
  Thanks to Martin Dauskardt for doing the bisect and tracing the
  breakage to this change.

 Switching on the whole ioctl makes the switch statement a lot less
 efficient.  I'd rather just put a if (_IOC_TYPE(cmd) != 'V') return 0; in
 there.  That should fix the non-v4l2 ioctls, right?

That was my first thought as well, but I realized that this is one area 
where you really do not want to take any risk.

Personally I think this code is overoptimization. In my view the performance 
advantage is minimal while reducing the readability of the code.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)

[Hans Verkuil]

On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
 On Sat, 7 Mar 2009 09:49:30 +0100

 Hans Verkuil hverk...@xs4all.nl wrote:
  On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
   On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
On Friday 06 March 2009 04:39:34 Andy Walls wrote:
 Yes, they should be exported to userspace as well, so apps like
 MythTV don't have to keep their own copies as well.  I'm going to
 work on a V4L2 spec change to add structures and defines for the
 packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add
 it to some API header. Maybe in linux/include/linux/videodev2.h
 with all the other VBI data formats.

 Unless someone really disagrees.
   
These VBI defines should be moved to videodev2.h. In hindsight this
should never have been added to ivtv.h. Originally only ivtv used
this, but now cx18 does as well, and in theory any MPEG encoder
device can use it.
  
   Hans, Mauro, and whoever:
  
   Before I get too far down the road of writing the spec modifications
   and perhaps modifying drivers, in the diff below:
  
   1. Are the modifications to the headers acceptable?
  
   2. Are they correct?  (I *think* they are.)
 
  Acked-by: Hans Verkuil hverk...@xs4all.nl
 
  Very nice. I was also toying with the idea to rename 'IVTV' in these
  defines to something different, but that makes too much of a mess. I
  think it is sufficient to add a sentence to the spec along the lines
  of:
 
  This format was first introduced in the ivtv driver, hence the use of
  IVTV in these defines. It is however not limited to the ivtv driver,
  any MPEG encoder can use it.
 
  And I think that it also doesn't hurt if some of my explanations from
  my earlier email are added to the spec as well. The format looks really
  weird if you do not understand the PVR350 (cx23415) limitation.

 IMO, it is better to remove the IVTV from the name or to replace to
 something else, since it is meant to be used by other drivers.

  +#define V4L2_MPEG_VBI_IVTV_MAGIC0  itv0
  +#define V4L2_MPEG_VBI_IVTV_MAGIC1  ITV0

 Hmm... maybe we could just name it as format ITV0, as marked at the magic
 values above. What do you think?

I don't really see much of an improvement here. I think it is better to put 
a note in the spec (and perhaps in videodev2.h) that while it originated 
with ivtv it is not specific to that driver.

But I do not have a really strong opinion here.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-notify

[Hans Verkuil]

On Monday 09 March 2009 02:20:19 Trent Piepho wrote:
 On Sun, 8 Mar 2009, Hans Verkuil wrote:
  - zoran/bt819: use new notify functionality.

 You put compat.h in the wrong spot in this patch.  It goes before any
 header file that are in v4l-dvb, but you've moved it to after
 v4l2-common.

That's not what README.patches says:

   There are several compatibility procedures already defined
   in compat.h file. If needed, it is better to include it after all
   other kernel standard headers, and before any specific header
   for that file. Something like:

#include linux/kernel.h
#include linux/module.h
...
#include linux/videodev2.h
#include media/v4l2-common.h

#include compat.h

#include mydriver-header.h

   should be included at the files under v4l-dvb tree. This header also
   includes linux/version.h.

Mauro, who's right?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: lifeview NOT LV3H not working

[vic]

ciencio ha scritto:
[cut]
So I downloaded the v4l tree from HG, compiled and installed it, but 
this time was the firmware that was missing. I followed the instruction 
to get the firmware for the xc3028  from here



 http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip


and everything seemed to be perfect... but the tuner wasn't able to 
detect anything.


Some news from my LV3H

1) after rebuilding the v4l from the main tree the analog tuner seems to 
be working, What I mean is thata tvtime is able to scan channels and to 
find them.


2) unfortunately there's no audio, in any way. If I connect the audio 
out to the audio of my sblive! I only get noise. If I try to send the 
output of the connexant audio device to the sblive! I always get only noise.


3) no news for the zl10353 driver, which keeps on giving the same error


[ 4982.520836] zl10353: write to reg 6c failed (err = -6)!



I don't know if anyone is interested in this report and I don't even 
know if I'm writing to the right mailing list.


Please let me know what I shoul post to get help,  if it is possible to 
get help :-)


--
Vic
--
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 1/4] pxa_camera: Remove YUV planar formats hole

[Guennadi Liakhovetski]

On Thu, 5 Mar 2009, Robert Jarzmik wrote:

 All planes were PAGE aligned (ie. 4096 bytes aligned). This
 is not consistent with YUV422 format, which requires Y, U
 and V planes glued together.  The new implementation forces
 the alignement on 8 bytes (DMA requirement), which is almost
 always the case (granted by width x height being a multiple
 of 8).
 
 The test cases include tests in both YUV422 and RGB565 :
  - a picture of size 111 x 111 (cross RAM pages example)
  - a picture of size 1023 x 4 in (under 1 RAM page)
  - a picture of size 1024 x 4 in (exactly 1 RAM page)
  - a picture of size 1025 x 4 in (over 1 RAM page)
  - a picture of size 1280 x 1024 (many RAM pages)
 
 Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
 ---
  drivers/media/video/pxa_camera.c |  165 
 ++
  1 files changed, 114 insertions(+), 51 deletions(-)
 
 diff --git a/drivers/media/video/pxa_camera.c 
 b/drivers/media/video/pxa_camera.c
 index e3e6b29..54df071 100644
 --- a/drivers/media/video/pxa_camera.c
 +++ b/drivers/media/video/pxa_camera.c
 @@ -242,14 +242,13 @@ static int pxa_videobuf_setup(struct videobuf_queue 
 *vq, unsigned int *count,
   dev_dbg(icd-dev, count=%d, size=%d\n, *count, *size);
  
   /* planar capture requires Y, U and V buffers to be page aligned */
 - if (pcdev-channels == 3) {
 - *size = PAGE_ALIGN(icd-width * icd-height); /* Y pages */
 - *size += PAGE_ALIGN(icd-width * icd-height / 2); /* U pages */
 - *size += PAGE_ALIGN(icd-width * icd-height / 2); /* V pages */
 - } else {
 - *size = icd-width * icd-height *
 - ((icd-current_fmt-depth + 7)  3);
 - }
 + if (pcdev-channels == 3)
 + *size = roundup(icd-width * icd-height, 8) /* Y pages */
 + + roundup(icd-width * icd-height / 2, 8) /* U pages */
 + + roundup(icd-width * icd-height / 2, 8); /* V pages 
 */
 + else
 + *size = roundup(icd-width * icd-height *
 + ((icd-current_fmt-depth + 7)  3), 8);
  
   if (0 == *count)
   *count = 32;

Ok, this one will change I presume - new alignment calculations and 
line-breaking. In fact, if you adjust width and height earlier in set_fmt, 
maybe you'll just remove any rounding here completely.

 @@ -289,19 +288,63 @@ static void free_buffer(struct videobuf_queue *vq, 
 struct pxa_buffer *buf)
   buf-vb.state = VIDEOBUF_NEEDS_INIT;
  }
  
 +static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
 +int sg_first_ofs, int size)
 +{
 + int i, offset, dma_len, xfer_len;
 + struct scatterlist *sg;
 +
 + offset = sg_first_ofs;
 + for_each_sg(sglist, sg, sglen, i) {
 + dma_len = sg_dma_len(sg);
 +
 + /* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
 + xfer_len = roundup(min(dma_len - offset, size), 8);

Ok, let's see. dma_len is PAGE_SIZE. offset is for Y-plane 0, for further 
planes it will be aligned after we recalculate width and height. size will 
be aligned too, so, roundup will disappear, right? You might want to just 
just add a test for these. The calculation itself gives size = xfer_len

 +
 + size = max(0, size - xfer_len);

So, max is useless here, just size -= xfer_len.

 + offset = 0;
 + if (size == 0)
 + break;
 + }
 +
 + BUG_ON(size != 0);
 + return i + 1;
 +}
 +
 +/**
 + * pxa_init_dma_channel - init dma descriptors
 + * @pcdev: pxa camera device
 + * @buf: pxa buffer to find pxa dma channel
 + * @dma: dma video buffer
 + * @channel: dma channel (0 = 'Y', 1 = 'U', 2 = 'V')
 + * @cibr: camera read fifo
 + * @size: bytes to transfer
 + * @sg_first: index of first element of sg_list
 + * @sg_first_ofs: offset in first element of sg_list
 + *
 + * Prepares the pxa dma descriptors to transfer one camera channel.
 + * Beware sg_first and sg_first_ofs are both input and output parameters.
 + *
 + * Returns 0
 + */
  static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
   struct pxa_buffer *buf,
   struct videobuf_dmabuf *dma, int channel,
 - int sglen, int sg_start, int cibr,
 - unsigned int size)
 + int cibr, int size,
 + struct scatterlist **sg_first, int 
 *sg_first_ofs)
  {
   struct pxa_cam_dma *pxa_dma = buf-dmas[channel];
 - int i;
 + struct scatterlist *sg;
 + int i, offset, sglen;
 + int dma_len = 0, xfer_len = 0;
  
   if (pxa_dma-sg_cpu)
   dma_free_coherent(pcdev-dev, pxa_dma-sg_size,
 pxa_dma-sg_cpu, pxa_dma-sg_dma);
  
 + sglen = calculate_dma_sglen(*sg_first, dma-sglen,
 + *sg_first_ofs, size);
 +
   

Re: Kconfig changes in /hg/v4l-dvb caused dvb_usb_cxusb to stop building (fwd)

[Mauro Carvalho Chehab]

On Sun, 8 Mar 2009, VDR User wrote:


 On Sun, Mar 8, 2009 at 6:07 PM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
  It won't mark they with M, if you keep enabling DVB_FE_CUSTOMISE, since 
  this

  Kconfig var allows manual override over the frontend modules.

 Ok, tried again and it's as you said.  I assumed the behavior of
 DVB_FE_CUSTOMISE hadn't changed but it appears it has.


Yes, there were minor changes on its behaviour.


 Although, I
 think the previous behavior is still better having the required
 modules as locked -M-.  At least then the user has some kind of
 control over what modules are built without risk of disabling
 something he needs.  What was the logic behind making this change?

 That's one thing I don't understand... Why an os that prides itself on
 user-customization seems to always be introducing ways to limit the
 user.


If all select options are ok, the old way were completely useless to the 
developers. With DVB_FE_CUSTOMISE disabled, all control you have is to select 
modules that you don't need, since the drivers you selected are not prepared to 
use they. So, it makes no sense to open a menu there.


By enabling DVB_FE_CUSTOMISE, you can do two things (just like before):
	- Unselect frontends that is used by your driver, but eventually you 
don't need on your specific device (for example, you just need one DVB demod 
for your specific av7110 device);

 - Select frontends not used anywere.

The first usage is meant to allow an embedded user (or an advanced one)
to produce a kernel with a minimal set of drivers.

The second usage makes sense only during driver development, where you're 
playing with some frontends, or want to test your driver with the dummy 
frontend (that's why it is now enabled by default).


Btw, if you look at DVB_FE_CUSTOMISE help, it is recommended tho unselect it, 
if you're not sure what to do.


 

 Anyways, here's what I get:

 $ grep ^CONFIG .config
 CONFIG_INPUT=y
 CONFIG_USB=y
 CONFIG_SND=y
 CONFIG_I2C_ALGOBIT=y
 CONFIG_INET=y
 CONFIG_CRC32=y
 CONFIG_SYSFS=y
 CONFIG_PCI=y
 CONFIG_VIRT_TO_BUS=y
 CONFIG_NET=y
 CONFIG_I2C=y
 CONFIG_STANDALONE=y
 CONFIG_MODULES=y
 CONFIG_HAS_IOMEM=y
 CONFIG_PROC_FS=y
 CONFIG_HAS_DMA=y
 CONFIG_SND_PCM=y
 CONFIG_EXPERIMENTAL=y
 CONFIG_IEEE1394=y
 CONFIG_VIDEO_DEV=m
 CONFIG_VIDEO_V4L2_COMMON=m
 CONFIG_VIDEO_V4L1_COMPAT=y
 CONFIG_DVB_CORE=m
 CONFIG_VIDEO_MEDIA=m
 CONFIG_VIDEO_SAA7146=m
 CONFIG_VIDEO_SAA7146_VV=m
 CONFIG_MEDIA_ATTACH=y
 CONFIG_MEDIA_TUNER=m
 CONFIG_MEDIA_TUNER_SIMPLE=m
 CONFIG_MEDIA_TUNER_TDA8290=m
 CONFIG_MEDIA_TUNER_TDA9887=m
 CONFIG_MEDIA_TUNER_TEA5761=m
 CONFIG_MEDIA_TUNER_TEA5767=m
 CONFIG_MEDIA_TUNER_MT20XX=m
 CONFIG_MEDIA_TUNER_XC2028=m
 CONFIG_MEDIA_TUNER_XC5000=m
 CONFIG_MEDIA_TUNER_MC44S803=m
 CONFIG_VIDEO_V4L2=m
 CONFIG_VIDEOBUF_GEN=m
 CONFIG_VIDEOBUF_DMA_SG=m
 CONFIG_DVB_DYNAMIC_MINORS=y
 CONFIG_DVB_CAPTURE_DRIVERS=y
 CONFIG_TTPCI_EEPROM=m
 CONFIG_DVB_AV7110=m
 CONFIG_DVB_AV7110_OSD=y
 CONFIG_DVB_STV0299=m
 CONFIG_DVB_TDA8083=m
 CONFIG_DVB_VES1X93=m
 CONFIG_DVB_SP8870=m
 CONFIG_DVB_L64781=m
 CONFIG_DVB_VES1820=m
 CONFIG_DVB_STV0297=m
 CONFIG_DVB_LNBP21=m


Seems perfect to my eyes.

--
Cheers,
Mauro

--
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: OMAP3 ISP and camera drivers (update)

[Dongsoo, Nathaniel Kim]

Hello Arun,

I've tried again after receiving your mail.
It seems to be weired but it works this time. Difference between last
time is I cloned linux-omap repo again and tried pulled Sakari's repo
into that.
It could be my fault maybe ;(
Strange day. Sorry for making you confused.

Nate


On Mon, Mar 9, 2009 at 7:18 PM, Arun KS getaru...@gmail.com wrote:
 2009/3/9 DongSoo(Nathaniel) Kim dongsoo@gmail.com:
 Hi Sakari,

 I've been trying to pull your gitorious patchset into my linux-omap
 repository (which is completely clean and up-to-date), but I'm having
 some problem.
 Please find following messages. I captured my git repository messages.

 kd...@chromatix:/home/share/GIT/OMAP_REF/kernel_org/linux-omap-2.6$ git pull

 Already up-to-date.

 kd...@chromatix:/home/share/GIT/OMAP_REF/kernel_org/linux-omap-2.6$ git 
 status

 # On branch master

 nothing to commit (working directory clean)

 kd...@chromatix:/home/share/GIT/OMAP_REF/kernel_org/linux-omap-2.6$
 git pull http://git.gitorious.org/omap3camera/mainline.git v4l iommu
 omap3camera base

 error: Could not read 5b007183d51543624bc9f582966f245a64157b57

 error: Could not read fa8977215db5ab6139379e95efc193e45833afa3

 error: Could not read 7de046a6a8446358001c38ad1d0b2b829ca0c98c

 error: Could not read 5b007183d51543624bc9f582966f245a64157b57

 Unable to find common commit with dc05ee10583dca44e0f8d4109bd1397ee3c5ffae

 Automatic merge failed; fix conflicts and then commit the result.




 I guess other people should also have the same issue with it. or am I
 doing wrong way?
 Please let me know

 Hi Nate,

 I tried this git pull git://git.gitorious.org/omap3camera/mainline.git
 v4l iommu omap3camera base
 and it works for me.

 Thanks,
 Arun


 On Sat, Mar 7, 2009 at 12:32 AM, Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com wrote:
 Hi,

 I've updated the patchset in Gitorious.

 URL:http://www.gitorious.org/projects/omap3camera

 Changes include

 - Power management support. ISP suspend/resume should work now.

 - Reindented and cleaned up everything. There are still some warnings from
 checkpatch.pl from the CSI2 code.

 - Fix for crash in device registration, posted to list already. (Thanks,
 Vaibhav, Alexey!)

 - LSC errors should be handled properly now.

 I won't post the modified patches to the list this time since I guess it
 wouldn't be much of use, I guess. Or does someone want that? :)

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




 --
 
 DongSoo(Nathaniel), Kim
 Engineer
 Mobile S/W Platform Lab. S/W Team.
 DMC
 Samsung Electronics CO., LTD.
 e-mail : dongsoo@gmail.com
          dongsoo45@samsung.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





-- 

DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.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: V4L2 spec

[Mauro Carvalho Chehab]

On Fri, 6 Mar 2009, wk wrote:


Hans Verkuil wrote:

 Hi Mauro,

 I noticed that there is an ancient V4L2 spec in our tree in the v4l/API
 directory. Is that spec used in any way? I don't think so, so I suggest
 that it is removed.


OK.


 The V4L1 spec that is there should probably be moved to the v4l2-spec
 directory as that is where people would look for it. We can just keep it
 there for reference.


Nah. Let's just strip and point to some place where V4L1 doc is 
available, adding some warning that the API is outdated and will be 
removed from kernel soon.



 The documentation on www.linuxtv.org is also out of date. How are we going
 to update that?


Make a proposal. I'll then updade it acordingly.


 I think that a good schedule would be right after a kernel merge window
 closes. The spec at that moment is the spec for that new kernel and that's
 a good moment to update the website.

 The current spec is really old, though, and should be updated asap.

 Note that the specs from the daily build are always available from
 www.xs4all.nl/~hverkuil/spec. I've modified the build to upload the
 dvbapi.pdf as well.


Maybe we can add a script to daily update at linuxtv.org for the specs as
well.


Wouldn't it make sense to merge both apis, v4l2 and dvb together?

- dvb api is completely outdated, would be good to be rewritten anyway.
- v4l2 and dvb share the same hg
- v4l2 and dvb share the same wiki
- a lot of developers are active in both topics
- any person interested in video and tv could be directed to the same file

Just some thoughts to the topic..


I think so. The better would be to convert DVB api to docbook (as used by 
all other kernel documents), and add a developers document for the kernel 
API for both at the kernel documentation structure).


However, this is a huge task that someone should volunteer for doing, 
otherwise, it won't happen.


Cheers,
Mauro
--
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 2/4] pxa_camera: Redesign DMA handling

[Guennadi Liakhovetski]

On Thu, 5 Mar 2009, Robert Jarzmik wrote:

 The DMA transfers in pxa_camera showed some weaknesses in
 multiple queued buffers context :
  - poll/select problem
The order between list pcdev-capture and DMA chain was
not the same. This creates a discrepancy between video
buffers marked as done by the IRQ handler, and the
really finished video buffer.
 
The bug shows up with capture_example tool from v4l2 hg
tree. The process just stalls on a select timeout.
 
The key problem is in pxa_videobuf_queue(), where the
queued buffer is chained before the active buffer, while
it should have been the active buffer first, and queued
buffer tailed after.
 
  - multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
always started right away. This is not optimal, as a
special case appears when the first EOF was not yet
reached, and the DMA channels were prematurely started.
 
  - Maintainability
DMA code was a bit obfuscated. Rationalize the code to be
easily maintainable by anyone.
 
 This patch attemps to address these issues.
 
 Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
 ---
  drivers/media/video/pxa_camera.c |  264 
 --
  1 files changed, 139 insertions(+), 125 deletions(-)
 
 diff --git a/drivers/media/video/pxa_camera.c 
 b/drivers/media/video/pxa_camera.c
 index 54df071..2d79ded 100644
 --- a/drivers/media/video/pxa_camera.c
 +++ b/drivers/media/video/pxa_camera.c
 @@ -325,7 +325,7 @@ static int calculate_dma_sglen(struct scatterlist 
 *sglist, int sglen,
   * Prepares the pxa dma descriptors to transfer one camera channel.
   * Beware sg_first and sg_first_ofs are both input and output parameters.
   *
 - * Returns 0
 + * Returns 0 or -ENOMEM si no coherent memory is available

Let's stay with English for now:-) s/si/if/

   */
  static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
   struct pxa_buffer *buf,
 @@ -369,7 +369,8 @@ static int pxa_init_dma_channel(struct pxa_camera_dev 
 *pcdev,
   pxa_dma-sg_cpu[i].dsadr = pcdev-res-start + cibr;
   pxa_dma-sg_cpu[i].dtadr = sg_dma_address(sg) + offset;
   pxa_dma-sg_cpu[i].dcmd =
 - DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len;
 + DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len
 + | ((i == 0) ? DCMD_STARTIRQEN : 0);

If DCMD_STARTIRQEN is still for debugging only, maybe put it under

#ifdef DEBUG
if (!i)
pxa_dma-sg_cpu[i].dcmd |= DCMD_STARTIRQEN;
#endif

you anyway only see any effect of this interrupt with dev_dbg().

   pxa_dma-sg_cpu[i].ddadr =
   pxa_dma-sg_dma + (i + 1) * sizeof(struct pxa_dma_desc);
  
 @@ -516,6 +517,97 @@ out:
   return ret;
  }
  
 +/**
 + * pxa_dma_start_channels - start DMA channel for active buffer
 + * @pcdev: pxa camera device
 + *
 + * Initialize DMA channels to the beginning of the active video buffer, and
 + * start these channels.
 + */
 +static void pxa_dma_start_channels(struct pxa_camera_dev *pcdev)
 +{
 + int i;
 + struct pxa_buffer *active;
 +
 + active = pcdev-active;
 +
 + for (i = 0; i  pcdev-channels; i++) {
 + dev_dbg(pcdev-dev, %s (channel=%d) ddadr=%08x\n, __func__,
 + i, active-dmas[i].sg_dma);
 + DDADR(pcdev-dma_chans[i]) = active-dmas[i].sg_dma;
 + DCSR(pcdev-dma_chans[i]) = DCSR_RUN;
 + }
 +}
 +
 +static void pxa_dma_stop_channels(struct pxa_camera_dev *pcdev)
 +{
 + int i;
 +
 + for (i = 0; i  pcdev-channels; i++) {
 + dev_dbg(pcdev-dev, %s (channel=%d)\n, __func__, i);
 + DCSR(pcdev-dma_chans[i]) = 0;
 + }
 +}
 +
 +static void pxa_dma_update_sg_tail(struct pxa_camera_dev *pcdev,
 +struct pxa_buffer *buf)
 +{
 + int i;
 +
 + for (i = 0; i  pcdev-channels; i++) {
 + pcdev-sg_tail[i] = buf-dmas[i].sg_cpu + buf-dmas[i].sglen;
 + pcdev-sg_tail[i]-ddadr = DDADR_STOP;

Do I understand it right, assuming capture is running, i.e., active != 
NULL:

before your patch

sg_tail points to the last real DMA descriptor
the last real DMA descriptor has DDADR_STOP
on queuing of the next buffer we
 1. stop DMA
 2. link the last real descriptor to the new first descriptor
 3. allocate an additional dummy descriptor, fill it with DMA engine's 
current state and use it to
 4. re-start DMA

after your patch

sg_tail points to the additional DMA descriptor
the last valid DMA descriptor points to the additional descriptor
the additional descriptor has DDADR_STOP
on queuing of the next buffer
 1. stop DMA
 2. the additional dummy descriptor at the tail of the current chain is 
reconfigured to point to the new start
 3. pxa_dma_start_channels() is called, which drops the current 

Re: Problem with changeset 10837: causes make all not to build many modules

[Alain Kalker]

Op maandag 09-03-2009 om 01:30 uur [tijdzone -0300], schreef Mauro
Carvalho Chehab:
 I'm not sure if Kernel has a default language convention for this. Probably, 
 it
 has, but I can't find anything on Documentation/*. Otherwise, I would vote for
 using -ISE on both options.
 
 Hmm... maybe we can just grep for both and see what happens most on Kernel:
 
 $ git grep -i customise|wc
 2561451   19677
 
 $ git grep -i customize|wc
 115 7339986
 
 It seems that the Britain way is more popular.

I would vote to stick with -ise also, since it is used most in the
kernel, and also to hono(u)r the fact that Linus, who started it all, is
European. No offen{c,s}e to the many people from the Americas who
contribute great and valuable work to it! :-)

Kind regards,

Alain

--
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: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb

[Mauro Carvalho Chehab]

On Sat, 7 Mar 2009 23:22:59 -0300
Douglas Schilling Landgraf dougsl...@gmail.com wrote:

 Hello everyone,
 
 First of all, thanks for your comments guys.
 
 On Sat, 7 Mar 2009 18:26:05 -0500
 Devin Heitmueller devin.heitmuel...@gmail.com wrote:
 
  On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf
  dougsl...@gmail.com wrote:
   Hi Mauro,
  
      Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for
   the following:
  
      - v4l2-apps/util: Add rewrite_eeprom tool
                              Modules this script is known to work
   with: em28xx and saa7134
  
   Thanks,
   Douglas
   --
   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
  
  
  Wow, this script really scares the crap out of me.  Is this something
  we *really* need?  
 
 IMO yes. The first version of this script was created because an em28xx
 user sent an email to me and Mauro asking *help* since his
 eeprom was lost and he would like to recover it. 
 
 A few time later, his board was recovered by [this script] and now his
 device is working and supported by the upstream driver. 
 
  If so, it needs to have a HUGE WARNING explaining
  the few cases that it should actually be used, and it should also
  explicitly block usage against chipsets except for those that have
  been validated to work.  
 
 Well, I have read several good ideas from you and others 
 developers. For now, it's very easy to implement such warning message,
 no problem from my side. 
 
  Do you really want to be responsible for the
  first time some unknowing user runs this against cx88 or some other
  chipset you never tried it against and it bricks their board?
 
 As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell
 bad because a user replaced his eeprom. We are here because we
 want to help them. So, let's add such warning message. 
 
  Also, this won't work against newer em28xx chipsets like the em2874
  and em2884, which have 16-bit eeproms.  And if you corrupt the eeprom
  on the em2874, you actually *WILL* brick the device (which is why I
  removed the code that reads the eeprom in the first place).
 
 Ok, I will add a comment to the script for such chipsets since I don't
 have those here for test now. On the other hand, I have tested with
 several older em28xx devices replacing a *good* eeprom with
 *wrong* eeprom and then replaced it again with a good one.. no bad
 affects, device is working fine like new. 
 
 *Of course, neither me or Mauro we DO NOT recommend nobody to
 run this script if it's not really needed (like: erased/wrong eeprom
 cases).*

Maybe one option is to first dump the eeprom and save on some backup file. Of
course, we should add some warning messages, confirmation, etc, to avoid that
such tool to be blindly used.

Cheers,
Mauro
--
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

Improve DKMS build of v4l-dvb?

[Alain Kalker]

I'm interested in improving the very interesting work[1] by Martin
Pitt[2] on making the v4l-dvb tree build under DKMS[3], so the drivers
get automatically rebuilt when the user installs a new kernel package.

Martin also works on the Jockey driver manager[4] which is used in
Ubuntu to detect hardware for which there are no drivers in the kernel
and to inform the user about available driver packages which can then be
downloaded and installed automatically.

Enabling DKMS build of v4l-dvb will also enable users with no experience
in building kernel modules to easily install the latest development
drivers for their hardware. This will improve the exposure of v4l-dvb
drivers to a wider community of users who can help with testing the
drivers on the wide variety of hardware that is out there.

Martin has an older version of the drivers packaged for building with
DKMS on Ubuntu in his PPA[5], but it currently has some disadvantages:

A. It builds all available drivers, no matter which hardware is actually
installed in the system. This takes a lot of time, and may not be
practical at all on systems with limited resources (e.g. embedded, MIDs,
netbooks)
B. It currently has no support for Jockey to detect installed hardware,
so individual drivers can be selected.

To address these issues, I would like to propose the following:

A. Building individual drivers (i.e. sets of modules which constitute a
fully-functional driver), without having to manually configure them
using make menuconfig

I see two possibilities for realizing this:
Firstly: generating a .config with just one config variable for the
requested driver set to 'm' merged with the config for the kernel being
built for, and then doing a make silentoldconfig. Big disatvantage is
that full kernel source is required for the 'silentoldconfig' target to
be available. 
Secondly, the script v4l/scripts/analyze_build.pl generates a list of
modules that will get built for each Kconfig variable selected, but it
currently has no way of determing all the module dependencies that make
up a fully functional driver.
The script v4l/scripts/check_deps.pl tries to discover dependencies
between Kconfig variables, but it currently is somewhat slow, and hase a
few other problems.

B. To enable hardware autodetection before installing drivers, we need
to have a list of modaliases of all supported hardware. This may be the
hardest part, because many VendorIDs and ProductIDs are scattered
throughout the code. Also coldbooting/warmbooting hardware is a problem.

I am very interested in any comments on these ideas, and getting in
contact with anyone who would like to help me with this project.

Kind regards,

Alain

[1]
http://martinpitt.wordpress.com/2008/06/10/packaged-dvb-t-drivers-for-ubuntu-804/
[2] https://launchpad.net/~pitti
[3] http://linux.dell.com/projects.shtml#dkms
[4] https://launchpad.net/jockey
[5] https://launchpad.net/~pitti/+archive/ppa

--
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: saa7146_i2c_writeout [irq]: timed out waiting for end of xfer

[Henrik Beckman]

not,
saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
uname -a
Linux media 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux

Is this a regression or has it always almost worked.

/Henrik

On Mon, Mar 9, 2009 at 11:35 AM, Henrik Beckman henrik.l...@gmail.com wrote:
 Solved,
 Did an lspci -vvv and setting latency according to the cards needs (128).
 Seems like all vpeirq: used 2 times 80% of buffer  and i2c errors are
 gone now, the i2c errors might have disapperaed when I rearranged the
 PCI cards and pulled the PVR-150 board.

 /Henrik


 On Thu, Mar 5, 2009 at 9:38 PM, Henrik Beckman henrik.l...@gmail.com wrote:
 Hi list,
 I get errors on my DVB-C card,

 Mar  5 21:23:47 media kernel: [ 1489.968022] saa7146 (0)
 saa7146_i2c_writeout [irq]: timed out waiting for end of xfer

 Ubuntu 8.10, TT-1501-C with CI module.
 There is a PVR-150 in the adjacent PCI slot, if that matters I can try
 an switch them or remove the pvr board.

 any ideas

 /Henrik


--
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 1/5] MT9P012: Add driver

[Aguirre Rodriguez, Sergio Alberto]

Hi Felipe,

Sorry for the delay replying this...

Find my responses below.

 -Original Message-
 From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
 Sent: Wednesday, March 04, 2009 5:31 AM
 To: Aguirre Rodriguez, Sergio Alberto
 Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus;
 Toivonen Tuukka.O (Nokia-D/Oulu); Doyu Hiroshi (Nokia-D/Helsinki);
 DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav;
 Lakhani, Amish; Menon, Nishanth
 Subject: Re: [PATCH 1/5] MT9P012: Add driver

 Hi,

 not looking at v4l2 part since it's not my area...


 On Tue, Mar 03, 2009 at 09:44:14PM +0100, ext Aguirre Rodriguez, Sergio
 Alberto wrote:
  +#define SENSOR_DETECTED1
  +#define SENSOR_NOT_DETECTED0

 these two should be unneeded...

Agreed, got rid of them...


  +
  +/**
  + * struct mt9p012_reg - mt9p012 register format
  + * @length: length of the register
  + * @reg: 16-bit offset to register
  + * @val: 8/16/32-bit register value
  + *
  + * Define a structure for MT9P012 register initialization values
  + */
  +struct mt9p012_reg {
  +   u16 length;
  +   u16 reg;
  +   u32 val;
  +};
  +
  +enum image_size {
  +   BIN4XSCALE,
  +   BIN4X,
  +   BIN2X,
  +   THREE_MP,
  +   FIVE_MP

 you probably wanna prefix these with MT9P012_ to avoid namespace
 conflicts.

Done.


  +};
  +
  +enum pixel_format {
  +   RAWBAYER10
  +};
  +
  +#define NUM_IMAGE_SIZES5
  +#define NUM_PIXEL_FORMATS  1
  +#define NUM_FPS2   /* 2 ranges */
  +#define FPS_LOW_RANGE  0
  +#define FPS_HIGH_RANGE 1
  +
  +/**
  + * struct capture_size - image capture size information
  + * @width: image width in pixels
  + * @height: image height in pixels
  + */
  +struct capture_size {
  +   unsigned long width;
  +   unsigned long height;
  +};
  +
  +/**
  + * struct mt9p012_pll_settings - struct for storage of sensor pll
 values
  + * @vt_pix_clk_div: vertical pixel clock divider
  + * @vt_sys_clk_div: veritcal system clock divider
  + * @pre_pll_div: pre pll divider
  + * @fine_int_tm: fine resolution interval time
  + * @frame_lines: number of lines in frame
  + * @line_len: number of pixels in line
  + * @min_pll: minimum pll multiplier
  + * @max_pll: maximum pll multiplier
  + */
  +struct mt9p012_pll_settings {
  +   u16 vt_pix_clk_div;
  +   u16 vt_sys_clk_div;
  +   u16 pre_pll_div;
  +
  +   u16 fine_int_tm;
  +   u16 frame_lines;
  +   u16 line_len;
  +
  +   u16 min_pll;
  +   u16 max_pll;
  +};
  +
  +/*
  + * Array of image sizes supported by MT9P012.  These must be ordered
 from
  + * smallest image size to largest.
  + */
  +const static struct capture_size mt9p012_sizes[] = {
  +   {  216, 162 },  /* 4X BINNING+SCALING */
  +   {  648, 486 },  /* 4X BINNING */
  +   { 1296, 972 },  /* 2X BINNING */
  +   { 2048, 1536},  /* 3 MP */
  +   { 2592, 1944},  /* 5 MP */
  +};
  +
  +/* PLL settings for MT9P012 */
  +enum mt9p012_pll_type {
  +  PLL_5MP = 0,
  +  PLL_3MP,
  +  PLL_1296_15FPS,
  +  PLL_1296_30FPS,
  +  PLL_648_15FPS,
  +  PLL_648_30FPS,
  +  PLL_216_15FPS,
  +  PLL_216_30FPS
  +};

 missing tabs, fix identation.

Done.


  +
  +/* Debug functions */
  +static int debug;
  +module_param(debug, bool, 0644);
  +MODULE_PARM_DESC(debug, Debug level (0-1));

 if it's a bool it's not debug level, it's debug on/off switch :-p

  +static struct mt9p012_sensor mt9p012;
  +static struct i2c_driver mt9p012sensor_i2c_driver;

 unneeded.

You're right. Done.


  +static unsigned long xclk_current = MT9P012_XCLK_NOM_1;

 why ??

Hmm, well. This is the xclk default value we use.

The driver basically uses 2 XCLK values to cover all the supported 
framerates/framesizes.

Anyways, I've added a xclk_current field as part of struct mt9p012_sensor 
instead. Removed this static var.


  +static int
  +find_vctrl(int id)

 I guess it fits in one line...

Done. Fixed all similar cases.


  +static int
  +mt9p012_read_reg(struct i2c_client *client, u16 data_length, u16 reg,
 u32 *val)
  +{
  +   int err;
  +   struct i2c_msg msg[1];
  +   unsigned char data[4];
  +
  +   if (!client-adapter)
  +   return -ENODEV;
  +   if (data_length != MT9P012_8BIT  data_length != MT9P012_16BIT
  +data_length != MT9P012_32BIT)
  +   return -EINVAL;
  +
  +   msg-addr = client-addr;
  +   msg-flags = 0;
  +   msg-len = 2;
  +   msg-buf = data;
  +
  +   /* high byte goes out first */
  +   data[0] = (u8) (reg  8);;
  +   data[1] = (u8) (reg  0xff);
  +   err = i2c_transfer(client-adapter, msg, 1);
  +   if (err = 0) {
  +   msg-len = data_length;
  +   msg-flags = I2C_M_RD;
  +   err = i2c_transfer(client-adapter, msg, 1);
  +   }
  +   

[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-radio

[Hans Verkuil]

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-radio for the 
following:

- v4l/compat.h: add clamp_val
- radio-aimslab: convert to v4l2_device.
- radio-aztech: convert to v4l2_device.
- radio-cadet: convert to v4l2_device.
- radio-gemtek-pci: convert to v4l2_device.
- radio-gemtek: convert to v4l2_device.
- radio-maestro: convert to v4l2_device.
- radio-maxiradio: convert to v4l2_device.
- radio-rtrack2: convert to v4l2_device.
- radio-sf16fmi: convert to v4l2_device.
- radio-sf16fmr2: convert to v4l2_device.
- radio-terratec: convert to v4l2_device.
- radio-trust: convert to v4l2_device.
- radio-typhoon: convert to v4l2_device.
- radio-zoltrix: convert to v4l2_device.
- ISA radio drivers: improve kernel log message

Tested with radio-gemtek and radio-zoltrix.

Thanks,

Hans

diffstat:
 linux/drivers/media/radio/radio-aimslab.c|  358 +++
 linux/drivers/media/radio/radio-aztech.c |  397 
 linux/drivers/media/radio/radio-cadet.c  |  631 
+--
 linux/drivers/media/radio/radio-gemtek-pci.c |  342 +++---
 linux/drivers/media/radio/radio-gemtek.c |  407 -
 linux/drivers/media/radio/radio-maestro.c|  340 +++---
 linux/drivers/media/radio/radio-maxiradio.c  |  403 -
 linux/drivers/media/radio/radio-rtrack2.c|  286 +---
 linux/drivers/media/radio/radio-sf16fmi.c|  294 +---
 linux/drivers/media/radio/radio-sf16fmr2.c   |  376 +++-
 linux/drivers/media/radio/radio-terratec.c   |  320 ++---
 linux/drivers/media/radio/radio-trust.c  |  357 +++
 linux/drivers/media/radio/radio-typhoon.c|  362 ++-
 linux/drivers/media/radio/radio-zoltrix.c|  389 +++-
 v4l/compat.h |6
 15 files changed, 2519 insertions(+), 2749 deletions(-)

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio

[Trent Piepho]

On Mon, 9 Mar 2009, Mauro Carvalho Chehab wrote:
 in kernel. That means that we shouldn't add a changeset that we know that it
 will break a device, except if we are committing, in the same patch series,
 another patch fixing it.

I wouldn't even do that.  If you know the patch has a problem with it, fix
the patch.  Submitting a patch know you has problems is inconsiderate to
other developers.  They are going to waste their time looking at a broken
patch and finding the bugs, only to discover they've already been found and
all their effort is pointless.

It also makes it hard for those to work on older kernels, e.g. for embedded
devices, and need to backport features.  You find that patch that adds the
feature you need to backport, only to later discover problems that, after
much effort, are traced to the backported patch.  Turns out the problems
were known with the patch was committed and already fixed, but how were you
supposed to know 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: OMAP3 ISP and camera drivers (update)

[Aguirre Rodriguez, Sergio Alberto]

 -Original Message-
 From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com]
 Sent: Friday, March 06, 2009 9:32 AM
 To: linux-media@vger.kernel.org
 Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo Kim; Hiremath, Vaibhav;
 Toivonen Tuukka Olli Artturi; Koskipää Antti Jussi Petteri; Cohen David
 Abraham; Alexey Klimov
 Subject: OMAP3 ISP and camera drivers (update)
 
 Hi,
 
 I've updated the patchset in Gitorious.
 
 URL:http://www.gitorious.org/projects/omap3camera
 
 Changes include
 
 - Power management support. ISP suspend/resume should work now.
 
 - Reindented and cleaned up everything. There are still some warnings
 from checkpatch.pl from the CSI2 code.
 
 - Fix for crash in device registration, posted to list already. (Thanks,
 Vaibhav, Alexey!)
 
 - LSC errors should be handled properly now.

Hi Sakari,

Doing a pull like you suggested in past release:
 
$ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \
   iommu omap3camera base

Brings the same code than before...

I see that omap3isp branch is updated on gitorious, but trying to pull that 
branch gives merge errors.

Regards,
Sergio

--
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

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Mon Mar  9 19:00:10 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   10857:4552dc2948e0
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29-rc7-armv5: OK
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29-rc7-armv5-ixp: OK
linux-2.6.27-armv5-omap2: OK
linux-2.6.28-armv5-omap2: OK
linux-2.6.29-rc7-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29-rc7-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29-rc7-m32r: OK
linux-2.6.26-mips: OK
linux-2.6.27-mips: OK
linux-2.6.28-mips: OK
linux-2.6.29-rc7-mips: WARNINGS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29-rc7-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29-rc7-x86_64: WARNINGS
fw/apps: WARNINGS
sparse (linux-2.6.28): ERRORS
sparse (linux-2.6.29-rc7): ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
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 4/4] pxa_camera: Fix overrun condition on last buffer

[Robert Jarzmik]

Guennadi Liakhovetski g.liakhovet...@gmx.de writes:

 On Thu, 5 Mar 2009, Robert Jarzmik wrote:

 The last buffer queued will often overrun, as the DMA chain
 is finished, and the time the dma irq handler is activated,

 s/and the time/and during the time/ ?
If you wish, or might be simply and before the dma irq handler is
activated. As you see fit.

 +if (camera_status  overrun
 + !list_is_last(pcdev-capture.next, pcdev-capture)) {
  dev_dbg(pcdev-dev, FIFO overrun! CISR: %x\n,
  camera_status);
  pxa_camera_stop_capture(pcdev);
  pxa_camera_start_capture(pcdev);
  goto out;
  }
 -
  buf-active_dma = ~act_dma;

 This empty like removal doesn't belong to the fix, I'll remove it when 
 committing, and amend the commit message as above. Please, comment if you 
 disagree.
I totally agree with you, remove that removal :)

Cheers.

--
Robert
--
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 spec

[Hans Verkuil]

On Monday 09 March 2009 12:08:39 Mauro Carvalho Chehab wrote:
 On Fri, 6 Mar 2009, wk wrote:
  Hans Verkuil wrote:
   Hi Mauro,
 
   I noticed that there is an ancient V4L2 spec in our tree in the
  v4l/API directory. Is that spec used in any way? I don't think so, so
  I suggest that it is removed.

 OK.

   The V4L1 spec that is there should probably be moved to the v4l2-spec
   directory as that is where people would look for it. We can just keep
  it there for reference.

 Nah. Let's just strip and point to some place where V4L1 doc is
 available, adding some warning that the API is outdated and will be
 removed from kernel soon.

I don't think we should remove the doc from the repo until all drivers are 
converted to v4l2.

   The documentation on www.linuxtv.org is also out of date. How are we
  going to update that?

 Make a proposal. I'll then updade it acordingly.

Can you just update it with the latest version compiled from v4l-dvb?

   I think that a good schedule would be right after a kernel merge
  window closes. The spec at that moment is the spec for that new kernel
  and that's a good moment to update the website.

Updating it whenever a merge window closes seems to make sense to me, so I 
propose that we do that.

   The current spec is really old, though, and should be updated asap.
 
   Note that the specs from the daily build are always available from
   www.xs4all.nl/~hverkuil/spec. I've modified the build to upload the
   dvbapi.pdf as well.

 Maybe we can add a script to daily update at linuxtv.org for the specs as
 well.

That would be a good plan.

Regards,

Hans


  Wouldn't it make sense to merge both apis, v4l2 and dvb together?
 
  - dvb api is completely outdated, would be good to be rewritten anyway.
  - v4l2 and dvb share the same hg
  - v4l2 and dvb share the same wiki
  - a lot of developers are active in both topics
  - any person interested in video and tv could be directed to the same
  file
 
  Just some thoughts to the topic..

 I think so. The better would be to convert DVB api to docbook (as used by
 all other kernel documents), and add a developers document for the kernel
 API for both at the kernel documentation structure).

 However, this is a huge task that someone should volunteer for doing,
 otherwise, it won't happen.

 Cheers,
 Mauro



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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 5/5] LDP: Add support for built-in camera

[Aguirre Rodriguez, Sergio Alberto]

Hi,

 -Original Message-
 From: stanley.miao [mailto:stanley.m...@windriver.com]

snip

  +static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
  +#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
  +   {
  +   I2C_BOARD_INFO(ov3640, OV3640_I2C_ADDR),
  +   .platform_data = ldp_ov3640_platform_data,
  +   },
  +#endif
  +};
 
 This new added i2c_board_info was not registered.
 After I added this line,
 
 omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
 ARRAY_SIZE(ldp_i2c_boardinfo_2));
 
 the sensor was found. but the test still failed. A lot of error came out
 when I run my test program.
 
 3CSI2: ComplexIO Error IRQ 80
 CSI2: ComplexIO Error IRQ 80
 3CSI2: ComplexIO Error IRQ c2
 CSI2: ComplexIO Error IRQ c2
 3CSI2: ComplexIO Error IRQ c2
 CSI2: ComplexIO Error IRQ c2
 3CSI2: ComplexIO Error IRQ c6
 CSI2: ComplexIO Error IRQ c6
 3CSI2: ECC correction failed
 CSI2: ECC correction failed
 3CSI2: ComplexIO Error IRQ 6
 CSI2: ComplexIO Error IRQ 6
 3CSI2: ComplexIO Error IRQ 6
 CSI2: ComplexIO Error IRQ 6
 3CSI2: ComplexIO Error IRQ 6
 CSI2: ComplexIO Error IRQ 6
 3CSI2: ComplexIO Error IRQ 6
 CSI2: ComplexIO Error IRQ 6
 

Oops, my mistake. Missed to add that struct there... Fixed now.

About the CSI2 errors you're receiving... Which version of LDP are you using? 
Which Silicon revision has (ES2.1 or ES3.0)?

Regards,
Sergio
 
 Stanley.
--
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: Topro 6800 driver

[Anders Blomdell]

Thomas Kaiser wrote:
 Hello Anders
 
 Anders Blomdell wrote:
   When I set the RGB/YUV gains to zero, I get:
   5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57
ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 4d 2a 12 d1 00 a2 b4
  
   followed by a big number of repeated (0x152c bytes total):
  
 02 8a 00 a2 80 28 a0 0a 28
  
   and ending with:
  
 02 8a 00 a2 80 ff d9
  
   In binary the repeating sequence can be diveded in half:
  
  0010 1000 1010   1010 0010 1000
  0010 1000 1010   1010 0010 1000
 
 That is more less the same sequence I get when I do my saturation stuff 
 (white picture) :-) . As of coincidence, the same Bit pattern is found 
 in the PAC7311 when I do the saturation stuff. And I know the PAC7311 
 stream. That's the reason why I wrote I am 100% sure that this is JPEG 
 ;-) PAC7311 has a special marker between each MCU which has to be 
 removed. I don't see such thing in this stream. So it must be pure JPEG.
 
  
   Which approximately adds up to 1200 repetitions of this bitpattern 
 2*(0x152c -
   23)/9.
  
   And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
   subframes, so now the question is how much info about the Huffman 
 table this
   gives us?
 
 I think nothing :-( , but you found the MCUs :-) As it looks quite the 
 same as on the PAC7311, why not just try the Huffman table from the PAC7311?
Which seems to be encoded in the stream and not defined in the sourcecode (but
I'm tired, so I might well be wrong). Do you think you could extract it somehow?

 
 The frame header on the PAC7311 is ff ff 00 ff 96 62 + 1 Byte MCU Marker 
 44, then the JPEG data starts. Look at this:
 ff ff 00 ff 96 62 44 f7 ca 28 01 10 a2 80 11 0a 28 01 10 a2 80 11 0a 28
 Side note: the first 01 10 is the MCU marker 44 embedded in the Bit stream.
 
 TP8610, first few Bytes with frame header:
 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57 ab 0a 28 73 0a 28 
 02 8a 00 a2 80 28 a0 0a
 
 Therefor I think this is the start of the stream:
 ab 0a 28 73 0a 28 02 8a 00 a2 80 28 a0 0a
 
 Don't know why we have 73 in between :-(
 
 Hope this one helps
/Anders
-- 
Anders Blomdell  Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University  Phone:+46 46 222 4625
P.O. Box 118 Fax:  +46 46 138118
SE-221 00 Lund, Sweden
--
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

Mail list, Is WIKI up to date?

[Thomas Kaiser]

Anders Blomdell wrote:

Thomas Kaiser wrote:

Hello Anders

You should send your messages to linux-me...@vger.kernel.org. 
video4linux-l...@redhat.com is deprecated. The new mail list for V4L is 
  linux-me...@vger.kernel.org.


I just send my reply by mistake to video4linux-l...@redhat.com because I 
just hit replay all without checking the Email address.

And so did I, got the wrong adress first time since I followed:

  http://www.linuxtv.org/v4lwiki/index.php/Main_Page

guess I can't expect Google to find the right page always...

/Anders



Looks like the WIKI page you found is not up to date.

Thomas
--
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: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:

Thomas Kaiser wrote:

  And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
  subframes, so now the question is how much info about the Huffman 
table this

  gives us?

I think nothing :-( , but you found the MCUs :-) As it looks quite the 
same as on the PAC7311, why not just try the Huffman table from the PAC7311?

Which seems to be encoded in the stream and not defined in the sourcecode (but
I'm tired, so I might well be wrong). Do you think you could extract it somehow?


I think it should be in the gspca source or in the v4l_library? I didn't 
follow gspca code and v4l_library code lately. Anyway PAC7311 is working 
AFAIK.


I'll check and try.

Thomas
--
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 2/4] pxa_camera: Redesign DMA handling

[Robert Jarzmik]

Guennadi Liakhovetski g.liakhovet...@gmx.de writes:

 + * Returns 0 or -ENOMEM si no coherent memory is available

 Let's stay with English for now:-) s/si/if/
Oups ... sorry ... the froggish touch is back :)


   */
  static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
  struct pxa_buffer *buf,
 @@ -369,7 +369,8 @@ static int pxa_init_dma_channel(struct pxa_camera_dev 
 *pcdev,
  pxa_dma-sg_cpu[i].dsadr = pcdev-res-start + cibr;
  pxa_dma-sg_cpu[i].dtadr = sg_dma_address(sg) + offset;
  pxa_dma-sg_cpu[i].dcmd =
 -DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len;
 +DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len
 +| ((i == 0) ? DCMD_STARTIRQEN : 0);

 If DCMD_STARTIRQEN is still for debugging only, maybe put it under

 #ifdef DEBUG
   if (!i)
   pxa_dma-sg_cpu[i].dcmd |= DCMD_STARTIRQEN;
 #endif
OK. Will amend.
 +static void pxa_dma_update_sg_tail(struct pxa_camera_dev *pcdev,
 +   struct pxa_buffer *buf)
 +{
 +int i;
 +
 +for (i = 0; i  pcdev-channels; i++) {
 +pcdev-sg_tail[i] = buf-dmas[i].sg_cpu + buf-dmas[i].sglen;
 +pcdev-sg_tail[i]-ddadr = DDADR_STOP;

 Do I understand it right, assuming capture is running, i.e., active != 
 NULL:

 before your patch

 sg_tail points to the last real DMA descriptor
 the last real DMA descriptor has DDADR_STOP
 on queuing of the next buffer we
  1. stop DMA
  2. link the last real descriptor to the new first descriptor
  3. allocate an additional dummy descriptor, fill it with DMA engine's 
   current state and use it to
  4. re-start DMA
Yes, but you forget :
   5. link the last new buffer descriptor (the called dummy buffer) to the
   running chain.

I see it that way, after former pxa_video_queue() :

 +--+---++
 | First vb | Second vb | Third vb | |
 +^-+---+---|+
  | |  ++
  | + | New vb | dummy |
  |+|---+
  | |
  +-+

This is my understanding. The DMA is restarted at the dummy descriptor, which
re-reads the current DMA descriptor (is that correct, if 16 bytes were already
transfered ?), then comes back to the head of DMA chain.
Then first vb is finished, then second and third, and then new vb is re-filled.

Would you comment to see where I'm wrong please ?

 after your patch

 sg_tail points to the additional DMA descriptor
Which additional ? Do you mean the last DMA descriptor of the last video buffer
queued which never transfers any data ? (which is what I point it at, yes)

 the last valid DMA descriptor points to the additional descriptor
 the additional descriptor has DDADR_STOP
Yes.

 on queuing of the next buffer
  1. stop DMA
  2. the additional dummy descriptor at the tail of the current chain is 
   reconfigured to point to the new start
Yes.

  3. pxa_dma_start_channels() is called, which drops the current partial 
   transfer and re-starts the frame?...
Yes, that is wrong.
The trick is, if I restart the DMA channel where it was, I remember having my
select stalled message.

I see it that way, after new pxa_video_queue() :

 +--+---++
 | First vb | Second vb | Third vb | |
 +--+---+---|+
 ^  |  ++
 |  + | New vb | dummy |
  \restart ++

 If I am right, this doesn't seem right. If I am wrong, please, explain and 
 add explanatory comments, so, the next one (or the same one 2 months 
 later) does not have to spend time trying to figure out.
Well, you've got a point. There is something to dig here. By experiment, it is
working. But I will search why, as my patch does restart the frame :(

I will investigate :
 - if stopping the DMA chain and restarting in the middle of a DMA transfer
   (ie. in the middle of the 4096 bytes, on byte 2040 for example) does work.
 - how my DMA chain does work.

As a matter of fact, before this patch, I had a pxa_dma_restart_channels()
called in pxa_videobuf_queue(), which just restarted the DMA channel without
touching the DADR() register. I will search why this wasn't working.

 +static void pxa_camera_start_capture(struct pxa_camera_dev *pcdev)
 +{
 +unsigned long cicr0, cifr;
 +
 +dev_dbg(pcdev-dev, %s\n, __func__);

 I originally had a reset the FIFOs comment here, wouldn't hurt to add it 
 now too.
Sorry, I'll reput it there. Will amend.


 +cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
 +__raw_writel(cifr, pcdev-base + CIFR);
 +
 +cicr0 = __raw_readl(pcdev-base + 

Re: Kworld atsc 110 nxt2004 init

[Jonathan Isom]

On Sun, Feb 22, 2009 at 8:45 PM, Jonathan Isom jei...@gmail.com wrote:
 On Sun, Feb 22, 2009 at 2:43 PM, CityK ci...@rogers.com wrote:
 Jonathan Isom wrote:
 Hi
 I was looking over my logs and I'm wondering is
 nxt200x: Timeout waiting for nxt2004 to init
 common

HI all
  I am not sure if this is actually related to my lockups,  however I
think I may have
figured out something. If I boot my system with clocksource equal to
hpet it occurs
right after boot(~8secs in), but if I set it to jiffies I don't see
it(note early testing, may
still end up occuring).  In nxt2004_microcontroller_init there is a
msleep(10) and I'm
wondering if 200 msec(loop)  is long enough.

Any Thoughts?

Jonathan

 No its not common

 or is this womething I need to worry about.  I got one shortly before a
 lockup(No backtrace).  Nothing was doing other than dvbstreamer sitting 
 idle.
 I'll provide further logs if it should be needed.  I would think that
 It would need to
 only be initialize at module load.  Am I wrong in this thinking?

 in kernel  drivers 2.6.28.4
 Hi
 Looking at the logs I found that there was a backtrace. However I believe it
 is related to dvbstreamer and the kworld cards.  I cycle thru the channels to
 download epg info.  The previous crash I forgot that I was running the script
 to cycle them and export the xmltv data.
--
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 3/5] OV3640: Add driver

[Aguirre Rodriguez, Sergio Alberto]

Hi Alexey,

 -Original Message-
 From: Alexey Klimov [mailto:klimov.li...@gmail.com]

snip

  --- /dev/null
  +++ b/drivers/media/video/ov3640.c
  @@ -0,0 +1,2202 @@
  +/*
  + * drivers/media/video/ov3640.c
  + *
  + * ov3640 sensor driver
  + *
  + *
  + * Copyright (C) 2008 Texas Instruments.
 
 2009 ?

Fixed.

snip

  +static int ov3640_read_reg(struct i2c_client *client, u16 data_length,
 u16 reg,
  +   u32
 *val)
  +{
  +   int err = 0;
  +   struct i2c_msg msg[1];
  +   unsigned char data[4];
  +
  +   if (!client-adapter)
  +   return -ENODEV;
  +
  +   msg-addr = client-addr;
  +   msg-flags = I2C_M_WR;
  +   msg-len = 2;
  +   msg-buf = data;
  +
  +   /* High byte goes out first */
  +   data[0] = (u8) (reg  8);
  +   data[1] = (u8) (reg  0xff);
  +
  +   err = i2c_transfer(client-adapter, msg, 1);
 
 Please, let me understand.. You call i2c_transfer() and ask it to
 transfer one message(third parameter), right ?
 So, the returned value is negative errno or the number of messages
 executed. Logic says that you should check somethin like this:
   if (err = 1) {
   good;
   } else {
   i2c_transfer failed;
   we should deal with it(printk, try again, etc)
   }
 
 Or even:
   if (unlikely(err != 1)) {
   i2c_transfer failed;
   }
   Good code continue;
 
 Right or wrong ?

The idea of this piece of code is to:

- First do a write transfer with nothing else than the register address to read.
- Then do a I2C read transfer to receive the value from register selected in 
previous write with the size of data_length variable.

I do agree that perhaps a cleanup for this piece of code needs to be done... 
I'll clean it up, test, and repost the resulting patch for your review. :)

 
  +   if (err = 0) {
  +   mdelay(3);
  +   msg-flags = I2C_M_RD;
  +   msg-len = data_length;
  +   err = i2c_transfer(client-adapter, msg, 1);
  +   }
  +   if (err = 0) {
  +   *val = 0;
  +   /* High byte comes first */
  +   if (data_length == 1)
  +   *val = data[0];
  +   else if (data_length == 2)
  +   *val = data[1] + (data[0]  8);
  +   else
  +   *val = data[3] + (data[2]  8) +
  +   (data[1]  16) + (data[0]  24);
  +   return 0;
  +   }
  +   dev_err(client-dev, read from offset 0x%x error %d, reg,
 err);
 
 \n should be in dev_err.

Done

 
  +   return err;
  +}
  +
  +/* Write a value to a register in ov3640 sensor device.
  + * @client: i2c driver client structure.
  + * @reg: Address of the register to read value from.
  + * @val: Value to be written to a specific register.
  + * Returns zero if successful, or non-zero otherwise.
  + */
  +static int ov3640_write_reg(struct i2c_client *client, u16 reg, u8 val)
  +{
  +   int err = 0;
  +   struct i2c_msg msg[1];
  +   unsigned char data[3];
  +   int retries = 0;
  +
  +   if (!client-adapter)
  +   return -ENODEV;
  +retry:
  +   msg-addr = client-addr;
  +   msg-flags = I2C_M_WR;
  +   msg-len = 3;
  +   msg-buf = data;
  +
  +   /* high byte goes out first */
  +   data[0] = (u8) (reg  8);
  +   data[1] = (u8) (reg  0xff);
  +   data[2] = val;
  +
  +   err = i2c_transfer(client-adapter, msg, 1);
  +   udelay(50);
  +
  +   if (err = 0)
 
 Well, probably all checks of returned values after i2c_transfer should
 be reformatted in right way.

I'll redesign this...

 
 
  +   return 0;
  +
  +   if (retries = 5) {
  +   dev_dbg(client-dev, Retrying I2C... %d, retries);
 
 \n

Done.

snip

  +   /* FIXME: QXGA framerate setting forced to 15 FPS */
  +   if (isize == QXGA) {
  +   err = ov3640_write_reg(client, OV3640_PLL_1, 0x32);
  +   err = ov3640_write_reg(client, OV3640_PLL_2, 0x21);
  +   err = ov3640_write_reg(client, OV3640_PLL_3, 0x21);
  +   err = ov3640_write_reg(client, OV3640_CLK, 0x01);
  +   err = ov3640_write_reg(client, 0x304c, 0x81);
 
 I see no checking of returned values. For example, if first function
 failed, rest functions will keep going.

Agreed.. I think I'll definitely redesign this to avoid this kind of trouble.

snip

  +
  +   /* Common registers */
  +   err = ov3640_write_regs(client, ov3640_common[isize]);
  +
  +   /* Configure image size and pixel format */
  +   err = ov3640_write_regs(client, ov3640_reg_init[pfmt][isize]);
  +
  +   /* Setting of frame rate (OV suggested way) */
  +   err = ov3640_set_framerate(client, sensor-timeperframe,
 isize);
  +#ifdef CONFIG_VIDEO_OV3640_CSI2
  +   /* Set CSI2 common 

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Andy Walls]

On Mon, 2009-03-09 at 08:16 +0100, Hans Verkuil wrote:
 On Monday 09 March 2009 02:07:33 Trent Piepho wrote:
  On Sun, 8 Mar 2009, Hans Verkuil wrote:
   The last one fixes an ivtv regression caused by this change:
  
   changeset:   10811:0a0eba8e64d5
   user:Trent Piepho xy...@speakeasy.org
   date:Tue Mar 03 20:21:02 2009 -0800
   summary: videodev: only copy needed part of RW ioctl's parameter
  
   The fix is simple: switch on the full ioctl command instead of just the
   NR field.
  
   Thanks to Martin Dauskardt for doing the bisect and tracing the
   breakage to this change.
 
  Switching on the whole ioctl makes the switch statement a lot less
  efficient.  I'd rather just put a if (_IOC_TYPE(cmd) != 'V') return 0; in
  there.  That should fix the non-v4l2 ioctls, right?
 
 That was my first thought as well, but I realized that this is one area 
 where you really do not want to take any risk.
 
 Personally I think this code is overoptimization. In my view the performance 
 advantage is minimal while reducing the readability of the code.

On x86_64, I counted 3 bytes per switch case saved.  For the 22 switch
cases: a total of 66 bytes saved.  If compiled code size reduction is
the efficiency measure, I suspect there are probably lower hanging fruit
to be picked.

Assuming a 32 byte I-cache line, the aforementioned savings saves about
2 lines worth of loading from memory.  Maybe it matters for platforms
with small cache sizes (embedded platforms?).

Regards,
Andy


--
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 spec

[wk]

I think so. The better would be to convert DVB api to docbook (as used 
by all other kernel documents), and add a developers document for the 
kernel API for both at the kernel documentation structure).


However, this is a huge task that someone should volunteer for doing, 
otherwise, it won't happen.


Cheers,
Mauro


Sorry Mauro,

but i disagree with you.

Its a bad idea to expect someone else, the magic volunteer, doing work 
with *deep impact* on the dvb driver API structure or documentation.
Working on this topic determines complete usability of the driver, so 
MAIN DEVELOPERS have to REVIEW and CONTRIBUTE.
If they think, that they cannot do such work in parallel, they should to 
stop work on drivers for some time.


Status from application side of view at the moment: *not usable* without 
re-inventing the wheel.


The very same with the structures in frontend.h, a lot of things are not 
understandable. I give you some examples (i could give more...):


-  TRANSMISSION_MODE_4K is missing, but still mentioned in 300468 
v.1.9.1  6.2.13.4 Terrestrial delivery system descriptor
-  the same for BANDWIDTH_5_MHZ, also 300468 v.1.9.1  6.2.13.4 
Terrestrial delivery system descriptor
-  POLARIZATION for QPSK frontends  is nowhere defined in frontend.h at 
all, forcing applications to do its own definitions,
6.2.13.2 Satellite delivery system descriptor gives clear 
definitions - so why are they not defined in frontend.h?
-  ATSC frontends are mixed cable and terrestrian, whereas older DVB-C 
and DVB-T are *strictly* separated

-  struct dvb_qpsk_parameters is missing (at least!) to be usable again
   * fe_modulation_t
   * fe_pilot_t
   * fe_rolloff_t
   * fe_delivery_system_t
   * west_east_flag
   * scrambling_sequence_selector
   * multiple_input_stream_flag

- nearly the same for dvb_qam_parameters, dvb_ofdm_parameters, 
dvb_atsc_parameters..., at least delivery_system needs to be here


Working on documentation would fix *all* of this problems.

Regards,
Winfried
--
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 spec

[Devin Heitmueller]

On Mon, Mar 9, 2009 at 6:03 PM, wk handygewinnsp...@gmx.de wrote:
 Its a bad idea to expect someone else, the magic volunteer, doing work with
 *deep impact* on the dvb driver API structure or documentation.
 Working on this topic determines complete usability of the driver, so MAIN
 DEVELOPERS have to REVIEW and CONTRIBUTE.
 If they think, that they cannot do such work in parallel, they should to
 stop work on drivers for some time.

Cut me a $25,000 check and I'll happily do it.  Otherwise, don't tell
a bunch of volunteer developers how they should be spending their
time.  What you happen to think is the important is not necessarily
what developers feel is the most valuable use of their time.

The reality is that there is *some* value a developer can contribute
in reviewing the content and providing feedback and a *TON* of grunt
work involved that can be done by anybody who takes the time to learn
docbook.  If someone wants to volunteer to do the former, I'm sure
some developers would be willing to do the latter.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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] pwc : fix LED and power setup for first open

[Martin Fuzzey]

From: Martin Fuzzey mfuz...@gmail.com

Call pwc_construct before trying to talk to device to obtain vc interface so
that LED and power setup works the first time the video device is opened.

Signed-off-by: Martin Fuzzey mfuz...@gmail.com

---

diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index 0d81018..e11f422 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -1115,6 +1115,7 @@ static int pwc_video_open(struct file *file)
}

mutex_lock(pdev-modlock);
+   pwc_construct(pdev); /* set min/max sizes correct */
if (!pdev-usb_init) {
PWC_DEBUG_OPEN(Doing first time initialization.\n);
pdev-usb_init = 1;
@@ -1139,7 +1140,6 @@ static int pwc_video_open(struct file *file)
if (pwc_set_leds(pdev, led_on, led_off)  0)
PWC_DEBUG_OPEN(Failed to set LED on/off time.\n);

-   pwc_construct(pdev); /* set min/max sizes correct */

/* So far, so good. Allocate memory. */
i = pwc_allocate_buffers(pdev);


--
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 spec

[Andy Walls]

On Mon, 2009-03-09 at 23:44 +0100, Hans Verkuil wrote:
 On Monday 09 March 2009 23:10:56 Devin Heitmueller wrote:
  On Mon, Mar 9, 2009 at 6:03 PM, wk handygewinnsp...@gmx.de wrote:

  The reality is that there is *some* value a developer can contribute
  in reviewing the content and providing feedback and a *TON* of grunt
  work involved that can be done by anybody who takes the time to learn
  docbook.  If someone wants to volunteer to do the former, I'm sure
  some developers would be willing to do the latter.
 
 Indeed. If someone could do the 'grunt' work of converting the dvb doc into 
 DocBook 

The Google leads me to ask:

What about a LaTeX to HTML or OOo Writer convertor:

http://www.tug.org/utilities/texconv/textopc.html#TeX4ht

(maybe oolatex?)

Then OOo Writer saving to DocBook?

I suspect it won't be perfect, but since existing software does the
heavy lifting, it beats manual conversion.


I didn't quite understand why a conversion is necessary, but I do see a
lot of hard-coded structures in the LaTeX documents, which I suspect is
a pain to keep up to date.



 and integrating it into the existing v4l docbook,

I'm not sure of the value in that.

opinion
Implmenting something to multiple (or multi-volume) specifications is
indeed a pain, but it makes documentation maintenance easier as the task
is easily divided along areas of personnel expertise.  Assuming the rate
of documentation maintencance does not rapidly increase, keeping
documentation maintenace simple is paramount.

Also multiple specifcations (or volumes) clearly group requirements into
large chunks of I don't care about that volume and I do care about
this volume.  Combining the V4L2 and DVB spec into one volume would
probably be a strategic error for some tactical advantage in dealing
with hybrid devices.
/opinion

Regards,
Andy

--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Mauro Carvalho Chehab]

On Mon, 9 Mar 2009 08:16:53 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On Monday 09 March 2009 02:07:33 Trent Piepho wrote:
  On Sun, 8 Mar 2009, Hans Verkuil wrote:
   The last one fixes an ivtv regression caused by this change:
  
   changeset:   10811:0a0eba8e64d5
   user:Trent Piepho xy...@speakeasy.org
   date:Tue Mar 03 20:21:02 2009 -0800
   summary: videodev: only copy needed part of RW ioctl's parameter
  
   The fix is simple: switch on the full ioctl command instead of just the
   NR field.
  
   Thanks to Martin Dauskardt for doing the bisect and tracing the
   breakage to this change.
 
  Switching on the whole ioctl makes the switch statement a lot less
  efficient.  I'd rather just put a if (_IOC_TYPE(cmd) != 'V') return 0; in
  there.  That should fix the non-v4l2 ioctls, right?
 
 That was my first thought as well, but I realized that this is one area 
 where you really do not want to take any risk.

IMO, it is better to use Trent's way, and reduce the number of places that do
memset(0).

 Personally I think this code is overoptimization. In my view the performance 
 advantage is minimal while reducing the readability of the code.

In general, it is a good idea to avoid copying a data that won't be used from
userspace. I liked the optimizations done. Let's just fix what's broken and
test a lot to avoid causing a kernel regression.

Cheers,
Mauro
--
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 spec

[Andy Walls]

On Mon, 2009-03-09 at 19:46 -0400, Andy Walls wrote:
 On Mon, 2009-03-09 at 23:44 +0100, Hans Verkuil wrote:
  On Monday 09 March 2009 23:10:56 Devin Heitmueller wrote:
   On Mon, Mar 9, 2009 at 6:03 PM, wk handygewinnsp...@gmx.de wrote:

  Indeed. If someone could do the 'grunt' work of converting the dvb doc into 
  DocBook 
 
 The Google leads me to ask:
 
 What about a LaTeX to HTML or OOo Writer convertor:
 
 http://www.tug.org/utilities/texconv/textopc.html#TeX4ht
 
 (maybe oolatex?)
 
 Then OOo Writer saving to DocBook?

Following up: apparently TeX4ht's dmlatex or dblatex command can go
straight from LaTex to DocBook:

http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn-commands.html

 I suspect it won't be perfect, but since existing software does the
 heavy lifting, it beats manual conversion.

Regards,
Andy

--
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 spec

[Mauro Carvalho Chehab]

On Mon, 09 Mar 2009 19:46:34 -0400
Andy Walls awa...@radix.net wrote:

  and integrating it into the existing v4l docbook,  
 
 I'm not sure of the value in that.

The DVB conversion to docbook allows us to add it at the kernel docbook docs
(probably, not the entire doc, but the parts that describe the internal kernel
API).

 opinion
 Implmenting something to multiple (or multi-volume) specifications is
 indeed a pain, but it makes documentation maintenance easier as the task
 is easily divided along areas of personnel expertise.  Assuming the rate
 of documentation maintencance does not rapidly increase, keeping
 documentation maintenace simple is paramount.

If you take a look on V4L docbooks, it is divided into multiple volume files:

biblio.sgml  pixfmt-nv16.sgml vidioc-enumstd.sgml
common.sgml  pixfmt-packed-rgb.sgml   vidioc-g-audioout.sgml
compat.sgml  pixfmt-packed-yuv.sgml   vidioc-g-audio.sgml
controls.sgmlpixfmt-sbggr16.sgml  vidioc-g-crop.sgml
dev-capture.sgml pixfmt-sbggr8.sgml   vidioc-g-ctrl.sgml
dev-codec.sgml   pixfmt-sgbrg8.sgml   vidioc-g-enc-index.sgml
...

If we merge DVB there, for sure we should break it into some files, and maybe
even having they on separate directories.

 Also multiple specifcations (or volumes) clearly group requirements into
 large chunks of I don't care about that volume and I do care about
 this volume.  Combining the V4L2 and DVB spec into one volume would
 probably be a strategic error for some tactical advantage in dealing
 with hybrid devices.

This is a good point. 

On my opinion, it seems good to merge the docs. This is just my 2 cents.

If we merge both, IMO, we should break the doc into two parts, being one for
analog and another for digital, with an introductory text with the hybrid
devices glue.

If we decide not to merge, we can at least try to follow the same model on both
documents, and link a common sgml introductory text for hybrid devices to be
added on both documents.


 /opinion


Cheers,
Mauro
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-notify

[Mauro Carvalho Chehab]

On Mon, 9 Mar 2009 08:45:42 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On Monday 09 March 2009 02:20:19 Trent Piepho wrote:
  On Sun, 8 Mar 2009, Hans Verkuil wrote:
   - zoran/bt819: use new notify functionality.
 
  You put compat.h in the wrong spot in this patch.  It goes before any
  header file that are in v4l-dvb, but you've moved it to after
  v4l2-common.
 
 That's not what README.patches says:
 
There are several compatibility procedures already defined
in compat.h file. If needed, it is better to include it after all
other kernel standard headers, and before any specific header
for that file. Something like:
 
 #include linux/kernel.h
 #include linux/module.h
 ...
 #include linux/videodev2.h
 #include media/v4l2-common.h
 
 #include compat.h
 
 #include mydriver-header.h
 
should be included at the files under v4l-dvb tree. This header also
includes linux/version.h.
 
 Mauro, who's right?

It doesn't matter who is right. If we go ahead with the backport.pl script, we
should automatically add the compat.h header. So, maybe we'll need to do some
changes on the order of the include to avoid troubles.

Anyway, this is a minor question, that can be solved later. For now, I'll apply
the pull.

Cheers,
Mauro
--
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] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)

[Mauro Carvalho Chehab]

On Mon, 9 Mar 2009 22:53:44 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On Monday 09 March 2009 21:47:55 Andy Walls wrote:
  On Mon, 2009-03-09 at 08:25 +0100, Hans Verkuil wrote:
   On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
On Sat, 7 Mar 2009 09:49:30 +0100
   
Hans Verkuil hverk...@xs4all.nl wrote:
 On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
  On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
   On Friday 06 March 2009 04:39:34 Andy Walls wrote:
Yes, they should be exported to userspace as well, so apps
like MythTV don't have to keep their own copies as well.  I'm
going to work on a V4L2 spec change to add structures and
defines for the packets indicated by
V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it to some API
header. Maybe in linux/include/linux/videodev2.h with all the
other VBI data formats.
   
Unless someone really disagrees.
  
   These VBI defines should be moved to videodev2.h. In hindsight
   this should never have been added to ivtv.h. Originally only
   ivtv used this, but now cx18 does as well, and in theory any
   MPEG encoder device can use it.
 
  Hans, Mauro, and whoever:
 
  Before I get too far down the road of writing the spec
  modifications and perhaps modifying drivers, in the diff below:
 
  1. Are the modifications to the headers acceptable?
 
  2. Are they correct?  (I *think* they are.)

 Acked-by: Hans Verkuil hverk...@xs4all.nl

 Very nice. I was also toying with the idea to rename 'IVTV' in
 these defines to something different, but that makes too much of a
 mess. I think it is sufficient to add a sentence to the spec along
 the lines of:

 This format was first introduced in the ivtv driver, hence the use
 of IVTV in these defines. It is however not limited to the ivtv
 driver, any MPEG encoder can use it.

 And I think that it also doesn't hurt if some of my explanations
 from my earlier email are added to the spec as well. The format
 looks really weird if you do not understand the PVR350 (cx23415)
 limitation.
   
IMO, it is better to remove the IVTV from the name or to replace to
something else, since it is meant to be used by other drivers.
   
 +#define V4L2_MPEG_VBI_IVTV_MAGIC0itv0
 +#define V4L2_MPEG_VBI_IVTV_MAGIC1ITV0
   
Hmm... maybe we could just name it as format ITV0, as marked at the
magic values above. What do you think?
  
   I don't really see much of an improvement here. I think it is better to
   put a note in the spec (and perhaps in videodev2.h) that while it
   originated with ivtv it is not specific to that driver.
  
   But I do not have a really strong opinion here.
 
  I don't have a terribly strong opinion either.  I'm almost done the spec
  changes (see the diff inline below), but I can easily change things.
 
  I don't particularly want to purge IVTV from the
  V4L2_CID_MPEG_STREAM_VBI_FMT MPEG control enumeration:
 
  enum v4l2_mpeg_stream_vbi_fmt {
  [...]
  V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,
  };
 
  as that would be a specification change vs. an addition.  Also adding a
  new ...FMT_ITV0 symbol to the enumeration, that overlaps with a value of
  1, creates problems for the controls code. IMO, IVTV is there to stay in
  that enumeration.
 
 Right. Unless Mauro objects strongly I think we should just keep it as is. I 
 don't see any particular advantage in changing it.

Ok. Let's then keep the IVTV naming.

 
  I can change every other IVTV reference to ITV0 in a sensible way (I
  think).  Let me know, if you really want this.  I won't be finishing it
  and posting it for final draft review for a day or two.
 
 Nice documentation! I think that when this goes in, then README.vbi can be 
 removed.
 
 Regards,
 
   Hans
 




Cheers,
Mauro
--
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

Compro VideoMate U90

[scott]

Hi,
I recently bought a Compro VideoMate U90, described on the box as a
USB 2.0 DVB-T Stick with Remote.

When plugging it in, /var/log/messages simply says:

Mar 10 12:50:49 sonata kernel: [60359.936022] usb 4-5: new high speed
USB device using ehci_hcd and address 3
Mar 10 12:50:49 sonata kernel: [60360.070474] usb 4-5: configuration
#1 chosen from 1 choice

On my system (Kubuntu 8.10), it registers as a VideoMate U150, which
appears to be a similar (same?) device available in Taiwan. Does
anyone have any more information about this device, or advice on how
to get it working?

Regards,
Scott.

Some more info below:
U90 page: http://www.comprousa.com/en/product/u90/u90.html
U150 page (english translation):
http://translate.google.com/translate?prev=hphl=enu=http%3A%2F%2Fwww.comprousa.com%2Ftw%2Fproduct%2Fu150%2Fu150.htmlsl=autotl=en

$ uname -srvmo
Linux 2.6.27-13-generic #1 SMP Thu Feb 26 07:31:49 UTC 2009 x86_64 GNU/Linux

$ sudo lsusb -v
 Bus 004 Device 003: ID 185b:0150 Compro
 Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass0 (Defined at Interface level)
 bDeviceSubClass 0
 bDeviceProtocol 0
 bMaxPacketSize064
 idVendor   0x185b Compro
 idProduct  0x0150
 bcdDevice1.00
 iManufacturer   1 COMPRO
 iProduct2 VideoMate U150
 iSerial 3 0172
 bNumConfigurations  1
 Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   41
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  4 USB2.0-BulkIso
 bmAttributes 0xa0
 (Bus Powered)
 Remote Wakeup
 MaxPower  500mA
 Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   1
 bInterfaceClass   255 Vendor Specific Class
 bInterfaceSubClass255 Vendor Specific Subclass
 bInterfaceProtocol255 Vendor Specific Protocol
 iInterface  5 Bulk-In, Interface
 Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes2
 Transfer TypeBulk
 Synch Type   None
 Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
 Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   1
 bNumEndpoints   1
 bInterfaceClass   255 Vendor Specific Class
 bInterfaceSubClass255 Vendor Specific Subclass
 bInterfaceProtocol255 Vendor Specific Protocol
 iInterface  6 Iso-In, Interface
 Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes1
 Transfer TypeIsochronous
 Synch Type   None
 Usage Type   Data
 wMaxPacketSize 0x03ac  1x 940 bytes
 bInterval   1
 Device Qualifier (for other device speed):
 bLength10
 bDescriptorType 6
 bcdUSB   2.00
 bDeviceClass0 (Defined at Interface level)
 bDeviceSubClass 0
 bDeviceProtocol 0
 bMaxPacketSize064
 bNumConfigurations  2
 Device Status: 0x
 (Bus Powered)
--
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