Re: [PATCH 1/3] gspca pac7302/pac7311: simplify pac_find_sof

[Németh Márton]

Theodore Kilgore wrote:
> 
> On Sun, 1 Nov 2009, Németh Márton wrote:
>> Remove struct sd dependency from pac_find_sof() function implementation.
>> This step prepares separation of pac7302 and pac7311 specific parts of
>> struct sd.
> [...]
> But here is the point. The sn9c2028 cameras have a structure which seems 
> similar to the mr97310a cameras. They use a similar decompression 
> algorithm. They have a similar frame header. Specifically, the sn9c2028 
> frame header starts with the five bytes
> 
>  0xff, 0xff, 0x00, 0xc4, 0xc4
> 
> whereas the pac_common frame header starts with the five bytes
> 
>  0xff, 0xff, 0x00, 0xff, 0x96
> 
> Right now, for my own use, I have written a file sn9c2028.h which 
> essentially duplicates the functionality of pac_common.h and contains a 
> function which searches for the sn9c2028 SOF marker instead of searching 
> for the pac SOF marker. Is this necessarily the good, permanent solution? 
> I am not so sure about that.

I think the pac_find_sof() is a special case. To find a SOF sequence in
a bigger buffer in general needs to first analyze the SOF sequence for
repeated bytes. If there are repeated bytes the search have to be
continued in a different way, see the state machine currently in the
pac_common.h. To find the sn9c2028 frame header a different state machine
is needed. It might be possible to implement a search function which
can find any SOF sequence but I am afraid that this algorithm would be
too complicated because of the search string analysis.

> Perhaps when making changes it is a good time to think over the idea of 
> combining things which are in fact not very much different. After all, 
> another set of cameras might come along, too, which essentially requires 
> yet another minor variation on the same basic algorithm. Then we are 
> supposed to have three .h files with three functions which have the same 
> code and just search for slightly different strings?
> 
> I am well aware that you started out to do something different, but how 
> does this strike you?

I was also thinking about not just duplicate the code but find functions
which are similar. My thinking was that first I try to separate the
pac7302 and pac7311 subdrivers and get feedback. If this change was
accepted I would look for common functions not only in pac7302 and pac7311
but also in the gspca family of subdrivers.

My first candidate would be the low level reg_w*() and reg_r*() functions.
I haven't finished the analysis but it seems that most of the time the
usb_control_msg() parameters are the same except the request and
requesttype parameter. The request contains a number specific to the
device. The requesttype usually contains USB_RECIP_DEVICE or
USB_RECIP_INTERFACE. This means that these function can be extracted
to a common helper module or to gspca_main and introduce the request
and requesttype values somehow to struct sd_desc in gspca.h.

Regards,

Márton Németh

--
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/3] gspca pac7302/pac7311: simplify pac_find_sof

[Theodore Kilgore]

On Sun, 1 Nov 2009, Németh Márton wrote:


From: Márton Németh 

Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.

Signed-off-by: Márton Németh 
Cc: Thomas Kaiser 
Cc: Theodore Kilgore 
Cc: Kyle Guinn 




Szia Marton,

As long as these things work, I would not mind at all. But perhaps this is 
a good occasion to bring up an issue which seems to me very much related. 
It is the following:


Along with the (it seems to be never-ending) work on the mr97310a driver, 
I have been working on a driver for the sn9c2028 cameras. The driver at 
this point functions, and seems to function quite well. But it also seems 
to me that the code needs quite a bit of polishing before it is 
publicized. Since I have been very much preoccupied with finishing the 
mr97310a driver (why does the last 5% of a job sometimes take the most 
time?) this final polishing of the sn9c2028 driver has not yet occurred, 
sorry to say.


But here is the point. The sn9c2028 cameras have a structure which seems 
similar to the mr97310a cameras. They use a similar decompression 
algorithm. They have a similar frame header. Specifically, the sn9c2028 
frame header starts with the five bytes


0xff, 0xff, 0x00, 0xc4, 0xc4

whereas the pac_common frame header starts with the five bytes

0xff, 0xff, 0x00, 0xff, 0x96

Right now, for my own use, I have written a file sn9c2028.h which 
essentially duplicates the functionality of pac_common.h and contains a 
function which searches for the sn9c2028 SOF marker instead of searching 
for the pac SOF marker. Is this necessarily the good, permanent solution? 
I am not so sure about that.


Perhaps when making changes it is a good time to think over the idea of 
combining things which are in fact not very much different. After all, 
another set of cameras might come along, too, which essentially requires 
yet another minor variation on the same basic algorithm. Then we are 
supposed to have three .h files with three functions which have the same 
code and just search for slightly different strings?


I am well aware that you started out to do something different, but how 
does this strike you?



Theodore Kilgore

Hauppauge WinTV-HVR4000(Lite) Nova-HD-S2 LNB Voltage

[Jonas Kvinge]

Hi,

When measuring the voltage on the card it is between 12.8 and 13.0V,
while the set-top box measures 13.6V. I got a pretty long cable to the
LNB, approx 30 meters, could this be causing problems for me? Is there a
way to increase the voltage by 0.5V?

Jonas
--
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: cx18: YUV frame alignment improvements

[Andy Walls]

On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote:
> On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
> > Hi Andy,
> > 
> > The panic happens upon reboot and it is only 1 line of text oddly shifted.
> > 
> > Kernel panic - not syncing: DMA: Memory would be corrupted
> > 
> > If I switch back to the current v4l-dvb drivers no issue. To switch
> > back I have to boot from a USB drive.
> 
> Brandon,
> 
> Eww.  OK.  Nevermind performing any more data collection.  I'm going to
> use a new strategy (when I find the time).

I forgot to mention that the panic you are running into is in the
Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU
TLB) in

linux/lib/swiotlb.c

Your machine must not have a hardware IO MMU (and mine must).

The software IOMMU is trying to allocate a bounce buffer for DMA and it
can't get one of the needed size (i.e. 607.5 kB) and the fallback static
buffer isn't big enough either (it is only 32 kB).  That's why the panic
happens.

This certainly means that, in the general linux user case, very large
DMA buffers are bad.

So now I know


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: cx18: YUV frame alignment improvements

[Andy Walls]

On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
> On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls  wrote:
> > On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
> >> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls  wrote:
> >> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> >> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls  wrote:

> > Could you provide the panic to me?  Off-list is fine.
> >
> > If I can't get this large buffer scheme to work for the general case to
> > mainatin YUV frame alignment, I'll have to figure out what will likely
> > be a much more complex scheme to ensure alignment is maintained in for
> > YUV streams. :(
> >
> > Oh, well.
> >
> > Regards,
> > Andy
> >
> >
> >
> Hi Andy,
> 
> The panic happens upon reboot and it is only 1 line of text oddly shifted.
> 
> Kernel panic - not syncing: DMA: Memory would be corrupted
> 
> If I switch back to the current v4l-dvb drivers no issue. To switch
> back I have to boot from a USB drive.

Brandon,

Eww.  OK.  Nevermind performing any more data collection.  I'm going to
use a new strategy (when I find the time).

(Thinking out loud ...)
Working under the assumptions that:

1. The encoder always returns 720 pixels worth of data per line (no
matter what the scaling)

2. The software HM12 decoders can only deal with full, not partial,
16x8x2 UV macroblocks at 4:2:0, so scaled YUV height needs to be in
multiples of 32 lines

3. The CX23418 actually can handle Memory Descriptor Lists (MDLs) with
more than one buffer per list

I'm going to use the MDLs to actually hold buffer lists with multiple
buffers, where individual buffers are 720 * 32 * 3 / 2 = 33.75 kB each.
That way I can build up buffer lists to hold precisely one frame of YUV
data at a time, no matter what the scaling, and then know that if the
cx18 driver misses an incoming MDL notification, the YUV frames will
stay aligned.  The 33.75 kB buffers should be no problem from a DMA
perspective, compared to 607.5 kB buffers.

The pain is that the cx18 driver right now has the hard-coded assumption
that there is only one buffer per MDL.  It will take a bit of effort to
fix that assumption in the driver and generalize it to having 1 or more
buffers per MDL.


Anyway, thanks for the testing.

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

[PATCH 3/3] gspca pac7302/pac7311: separate the two subdrivers

[Németh Márton]

From: Márton Németh 

All PAC7311 specific functions remain in pac7311.c. All PAC7302 specific
functions are moved to pac7302.c. The USB device table is also divided into
two parts. This makes it possible to remove the sensor specific decisions
from different functions and also remove sensor infromation from the USB
device table.

The common functions are just copied to both subdrivers. These common
functions can be separated later to a common file or helper module.

Signed-off-by: Márton Németh 
Cc: Thomas Kaiser 
Cc: Theodore Kilgore 
Cc: Kyle Guinn 
---
diff -uprN c/drivers/media/video/gspca/Kconfig 
d/drivers/media/video/gspca/Kconfig
--- c/drivers/media/video/gspca/Kconfig 2009-10-30 16:12:05.0 +0100
+++ d/drivers/media/video/gspca/Kconfig 2009-11-01 06:58:14.0 +0100
@@ -104,6 +104,15 @@ config USB_GSPCA_PAC207
  To compile this driver as a module, choose M here: the
  module will be called gspca_pac207.

+config USB_GSPCA_PAC7302
+   tristate "Pixart PAC7302 USB Camera Driver"
+   depends on VIDEO_V4L2 && USB_GSPCA
+   help
+ Say Y here if you want support for cameras based on the PAC7302 chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_pac7302.
+
 config USB_GSPCA_PAC7311
tristate "Pixart PAC7311 USB Camera Driver"
depends on VIDEO_V4L2 && USB_GSPCA
diff -uprN c/drivers/media/video/gspca/Makefile 
d/drivers/media/video/gspca/Makefile
--- c/drivers/media/video/gspca/Makefile2009-11-01 18:24:03.0 
+0100
+++ d/drivers/media/video/gspca/Makefile2009-11-01 06:58:14.0 
+0100
@@ -8,6 +8,7 @@ obj-$(CONFIG_USB_GSPCA_MR97310A) += gspc
 obj-$(CONFIG_USB_GSPCA_OV519)+= gspca_ov519.o
 obj-$(CONFIG_USB_GSPCA_OV534)+= gspca_ov534.o
 obj-$(CONFIG_USB_GSPCA_PAC207)   += gspca_pac207.o
+obj-$(CONFIG_USB_GSPCA_PAC7302)  += gspca_pac7302.o
 obj-$(CONFIG_USB_GSPCA_PAC7311)  += gspca_pac7311.o
 obj-$(CONFIG_USB_GSPCA_SN9C20X)  += gspca_sn9c20x.o
 obj-$(CONFIG_USB_GSPCA_SONIXB)   += gspca_sonixb.o
@@ -38,6 +39,7 @@ gspca_mr97310a-objs := mr97310a.o
 gspca_ov519-objs:= ov519.o
 gspca_ov534-objs:= ov534.o
 gspca_pac207-objs   := pac207.o
+gspca_pac7302-objs  := pac7302.o
 gspca_pac7311-objs  := pac7311.o
 gspca_sn9c20x-objs  := sn9c20x.o
 gspca_sonixb-objs   := sonixb.o
diff -uprN c/drivers/media/video/gspca/pac7302.c 
d/drivers/media/video/gspca/pac7302.c
--- c/drivers/media/video/gspca/pac7302.c   1970-01-01 01:00:00.0 
+0100
+++ d/drivers/media/video/gspca/pac7302.c   2009-11-01 18:23:02.0 
+0100
@@ -0,0 +1,976 @@
+/*
+ * Pixart PAC7302 library
+ * Copyright (C) 2005 Thomas Kaiser tho...@kaiser-linux.li
+ *
+ * V4L2 by Jean-Francois Moine 
+ *
+ * Separated from Pixart PAC7311 library by Márton Németh 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/* Some documentation about various registers as determined by trial and error.
+   When the register addresses differ between the 7202 and the 7311 the 2
+   different addresses are written as 7302addr/7311addr, when one of the 2
+   addresses is a - sign that register description is not valid for the
+   matching IC.
+
+   Register page 1:
+
+   Address Description
+   -/0x08  Unknown compressor related, must always be 8 except when not
+   in 640x480 resolution and page 4 reg 2 <= 3 then set it to 9 !
+   -/0x1b  Auto white balance related, bit 0 is AWB enable (inverted)
+   bits 345 seem to toggle per color gains on/off (inverted)
+   0x78Global control, bit 6 controls the LED (inverted)
+   -/0x80  JPEG compression ratio ? Best not touched
+
+   Register page 3/4:
+
+   Address Description
+   0x02Clock divider 2-63, fps =~ 60 / val. Must be a multiple 
of 3 on
+   the 7302, so one of 3, 6, 9, ..., except when between 6 and 12?
+   -/0x0f  Master gain 1-245, low value = high gain
+   0x10/-  Master gain 0-31
+   -/0x10  Another gain 0-15, limited influence (1-2x gain I guess)
+   0x21Bitfield: 0-1 unused, 2-3 vflip/hflip, 4-5 unknown, 6-7 
unused
+   -/0x27  Seems to toggle various gains on / off, Setting bit 7 seems to
+   completely disa

[PATCH 2/3] gspca pac7302/pac7311: extract pac_start_frame

[Németh Márton]

From: Márton Németh 

Creating the start of the frame is done in the same way for pac7302
and for pac7311. Extract this common part to the pac_start_frame()
function.

Signed-off-by: Márton Németh 
Cc: Thomas Kaiser 
Cc: Theodore Kilgore 
Cc: Kyle Guinn 
---
diff -uprN b/drivers/media/video/gspca/pac7311.c 
c/drivers/media/video/gspca/pac7311.c
--- b/drivers/media/video/gspca/pac7311.c   2009-11-01 18:11:22.0 
+0100
+++ c/drivers/media/video/gspca/pac7311.c   2009-11-01 18:16:41.0 
+0100
@@ -816,7 +816,7 @@ static void do_autogain(struct gspca_dev
 }

 /* JPEG header, part 1 */
-static const unsigned char pac7311_jpeg_header1[] = {
+static const unsigned char pac_jpeg_header1[] = {
   0xff, 0xd8,  /* SOI: Start of Image */

   0xff, 0xc0,  /* SOF0: Start of Frame (Baseline DCT) */
@@ -827,7 +827,7 @@ static const unsigned char pac7311_jpeg_
 };

 /* JPEG header, continued */
-static const unsigned char pac7311_jpeg_header2[] = {
+static const unsigned char pac_jpeg_header2[] = {
   0x03,/* Number of image components: 3 */
   0x01, 0x21, 0x00,/* ID=1, Subsampling 1x1, Quantization table: 0 */
   0x02, 0x11, 0x01,/* ID=2, Subsampling 2x1, Quantization table: 1 */
@@ -843,6 +843,26 @@ static const unsigned char pac7311_jpeg_
   0x00 /* Successive approximation: 0 */
 };

+static void pac_start_frame(struct gspca_dev *gspca_dev,
+   struct gspca_frame *frame,
+   __u16 lines, __u16 samples_per_line)
+{
+   unsigned char tmpbuf[4];
+
+   gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+   pac_jpeg_header1, sizeof(pac_jpeg_header1));
+
+   tmpbuf[0] = lines >> 8;
+   tmpbuf[1] = lines & 0xff;
+   tmpbuf[2] = samples_per_line >> 8;
+   tmpbuf[3] = samples_per_line & 0xff;
+
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+   tmpbuf, sizeof(tmpbuf));
+   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
+   pac_jpeg_header2, sizeof(pac_jpeg_header2));
+}
+
 /* this function is run at interrupt level */
 static void sd_pkt_scan(struct gspca_dev *gspca_dev,
struct gspca_frame *frame,  /* target */
@@ -854,7 +874,6 @@ static void sd_pkt_scan(struct gspca_dev

sof = pac_find_sof(&sd->sof_read, data, len);
if (sof) {
-   unsigned char tmpbuf[4];
int n, lum_offset, footer_length;

if (sd->sensor == SENSOR_PAC7302) {
@@ -896,23 +915,14 @@ static void sd_pkt_scan(struct gspca_dev
atomic_set(&sd->avg_lum, -1);

/* Start the new frame with the jpeg header */
-   gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
-   pac7311_jpeg_header1, sizeof(pac7311_jpeg_header1));
if (sd->sensor == SENSOR_PAC7302) {
/* The PAC7302 has the image rotated 90 degrees */
-   tmpbuf[0] = gspca_dev->width >> 8;
-   tmpbuf[1] = gspca_dev->width & 0xff;
-   tmpbuf[2] = gspca_dev->height >> 8;
-   tmpbuf[3] = gspca_dev->height & 0xff;
+   pac_start_frame(gspca_dev, frame,
+   gspca_dev->width, gspca_dev->height);
} else {
-   tmpbuf[0] = gspca_dev->height >> 8;
-   tmpbuf[1] = gspca_dev->height & 0xff;
-   tmpbuf[2] = gspca_dev->width >> 8;
-   tmpbuf[3] = gspca_dev->width & 0xff;
+   pac_start_frame(gspca_dev, frame,
+   gspca_dev->height, gspca_dev->width);
}
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame, tmpbuf, 4);
-   gspca_frame_add(gspca_dev, INTER_PACKET, frame,
-   pac7311_jpeg_header2, sizeof(pac7311_jpeg_header2));
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
 }
--
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 00/21] gspca pac7302/pac7311: separate the two drivers

[Németh Márton]

Jean-Francois Moine wrote:
> On Sun, 01 Nov 2009 00:13:10 +0100
> Németh Márton  wrote:
> 
>> the following patchset refactores the Pixart PAC7311 subdriver. The
>> current situation is that the code contains a lot of decisions
>> like this:
>>
>> if (sd->sensor == SENSOR_PAC7302) {
>> ... do this ...
>> } else {
>> ... do something else ...
>> }
>>
>> The sensor type is determined using the USB Vendor ID and Product
>> ID which means that the decisions shown are not really necessary.
>>
>> The goal of the patchset is to have a PAC7302 and a PAC7311 subdriver
>> which have the benefit that there is no decision necessary on sensor
>> type at runtime. The common functions can be extracted later but this
>> would be a different patchset.
> 
> Splitting the pac7311 subdriver is a good idea, but I don't like your
> patchset: a lot of changes (function prefixes) are nullified by the
> last patch. I'd better like only one change for the pac7302 creation
> and a second one for the interface change of pac_find_sof() in
> pac_common.h (BTW, this file could now be compiled separately).

Hello Jef,

thank you for the feedback, I'll try to send a patch set wich contains
bigger steps. I hope the separation will be not a too big step and won't
make it too difficult to bisect any possible problem I might introduce
with this change. But hope for the best and imagine the easy way when
no regression was introduced.

I am also thinking about finding the common functions which can be
compiled separately either in a helper module or to gspca_main maybe.
But first I focus on the pac7302/pac7311 separation.

Márton Németh
--
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] gspca pac7302/pac7311: simplify pac_find_sof

[Németh Márton]

From: Márton Németh 

Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.

Signed-off-by: Márton Németh 
Cc: Thomas Kaiser 
Cc: Theodore Kilgore 
Cc: Kyle Guinn 
---
diff -uprN a/drivers/media/video/gspca/mr97310a.c 
b/drivers/media/video/gspca/mr97310a.c
--- a/drivers/media/video/gspca/mr97310a.c  2009-11-01 06:49:29.0 
+0100
+++ b/drivers/media/video/gspca/mr97310a.c  2009-11-01 18:11:22.0 
+0100
@@ -1034,9 +1034,10 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data,   /* isoc packet */
int len)  /* iso packet length */
 {
+   struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(&sd->sof_read, data, len);
if (sof) {
int n;

diff -uprN a/drivers/media/video/gspca/pac207.c 
b/drivers/media/video/gspca/pac207.c
--- a/drivers/media/video/gspca/pac207.c2009-10-30 16:12:05.0 
+0100
+++ b/drivers/media/video/gspca/pac207.c2009-11-01 18:11:22.0 
+0100
@@ -344,7 +344,7 @@ static void sd_pkt_scan(struct gspca_dev
struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(&sd->sof_read, data, len);
if (sof) {
int n;

diff -uprN a/drivers/media/video/gspca/pac7311.c 
b/drivers/media/video/gspca/pac7311.c
--- a/drivers/media/video/gspca/pac7311.c   2009-11-01 06:51:38.0 
+0100
+++ b/drivers/media/video/gspca/pac7311.c   2009-11-01 18:11:22.0 
+0100
@@ -852,7 +852,7 @@ static void sd_pkt_scan(struct gspca_dev
struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;

-   sof = pac_find_sof(gspca_dev, data, len);
+   sof = pac_find_sof(&sd->sof_read, data, len);
if (sof) {
unsigned char tmpbuf[4];
int n, lum_offset, footer_length;
diff -uprN a/drivers/media/video/gspca/pac_common.h 
b/drivers/media/video/gspca/pac_common.h
--- a/drivers/media/video/gspca/pac_common.h2009-10-30 16:12:05.0 
+0100
+++ b/drivers/media/video/gspca/pac_common.h2009-11-01 18:11:22.0 
+0100
@@ -72,42 +72,41 @@ static const unsigned char pac_sof_marke
   +--+
 */

-static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
+static unsigned char *pac_find_sof(u8 *sof_read,
unsigned char *m, int len)
 {
-   struct sd *sd = (struct sd *) gspca_dev;
int i;

/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i < len; i++) {
-   switch (sd->sof_read) {
+   switch (*sof_read) {
case 0:
if (m[i] == 0xff)
-   sd->sof_read = 1;
+   *sof_read = 1;
break;
case 1:
if (m[i] == 0xff)
-   sd->sof_read = 2;
+   *sof_read = 2;
else
-   sd->sof_read = 0;
+   *sof_read = 0;
break;
case 2:
switch (m[i]) {
case 0x00:
-   sd->sof_read = 3;
+   *sof_read = 3;
break;
case 0xff:
/* stay in this state */
break;
default:
-   sd->sof_read = 0;
+   *sof_read = 0;
}
break;
case 3:
if (m[i] == 0xff)
-   sd->sof_read = 4;
+   *sof_read = 4;
else
-   sd->sof_read = 0;
+   *sof_read = 0;
break;
case 4:
switch (m[i]) {
@@ -117,18 +116,18 @@ static unsigned char *pac_find_sof(struc
"SOF found, bytes to analyze: %u."
" Frame starts at byte #%u",
len, i + 1);
-   sd->sof_read = 0;
+   *sof_read = 0;
return m + i + 1;
break;
case 0xff:
-   sd->sof_read = 2;
+   *sof_read = 2;
break;
   

Re: [RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan

[aos...@netup.ru]

Hello Mauro,

Please pull fixed patch from:
http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02

I have fixed pointed issues. Strange that ./v4l/scripts/checkpatch.pl don't 
show me this errors before. Now checkpatch shows 0 errors/warnings.

P.S.
In some stripped environments running additiona user-level programs is 
difficult. In this case this debug possibility very useful.


On Saturday 31 October 2009 13:45:17 Mauro Carvalho Chehab wrote:
> Em Sun, 11 Oct 2009 21:09:24 +0400
>
> "aos...@netup.ru"  escreveu:
> > Hello Mauro,
> >
> > On Friday 09 October 2009 16:01:58 Mauro Carvalho Chehab wrote:
> > > Wouldn't be be better to just use dvbtraffic userspace apps for it?
> >
> > this feature very usable for debugging. Please add it.
> >
> > > Also,
> > > your patch has some coding style issues.
> >
> > please point to this issues. I will fix.
> >
> >
> >
> > # HG changeset patch
> > # User Abylay Ospan 
> > # Date 1253802277 -14400
> > # Node ID 711d9630876ffd81196c1032ce77825d5b433cc8
> > # Parent a798c751f06d60335fbbad9fdca8c41f1298d228
> > TS speed check. Logging transport stream speed in Kbits per second
> >
> > Signed-off-by: Abylay Ospan 
> >
> > --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.c  Wed Sep 23 10:21:53
> > 2009 +0200 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.c   Thu Sep 
> > 24
> > 18:24:37 2009 +0400 @@ -42,6 +42,11 @@
> >  module_param(dvb_demux_tscheck, int, 0644);
> >  MODULE_PARM_DESC(dvb_demux_tscheck,
> > "enable transport stream continuity and TEI check");
> > +
> > +static int dvb_demux_speedcheck;
> > +module_param(dvb_demux_speedcheck, int, 0644);
> > +MODULE_PARM_DESC(dvb_demux_speedcheck,
> > +   "enable transport stream speed check");
> >
> >  #define dprintk_tscheck(x...) do {  \
> > if (dvb_demux_tscheck && printk_ratelimit())\
> > @@ -385,6 +390,37 @@
> > struct dvb_demux_feed *feed;
> > u16 pid = ts_pid(buf);
> > int dvr_done = 0;
> > +   struct timespec cur_time, delta_time;
> > +   u64 speed_bytes, speed_timedelta;
> > +
> > +   if (dvb_demux_speedcheck) {
> > +   demux->speed_pkts_cnt++;
> > +
> > +   /* show speed every SPEED_PKTS_INTERVAL packets */
> > +   if (!(demux->speed_pkts_cnt%SPEED_PKTS_INTERVAL)) {
>
> You need to add spaces between each argument of the % operator
>
> > +   cur_time = current_kernel_time();
> > +
> > +   if (demux->speed_last_time.tv_sec != 0 &&
> > +   demux->speed_last_time.tv_nsec != 0) {
> > +   delta_time = timespec_sub(cur_time,
> > +   demux->speed_last_time);
> > +   speed_bytes = (u64)demux->speed_pkts_cnt*188*8;
>
> You need to add spaces between each argument of the * operator
>
> > +   /* convert to 1024 basis */
> > +   speed_bytes = 1000*div64_u64(speed_bytes,
> > +   1024);
>
> You need to add spaces between each argument of the * operator
>
> > +   speed_timedelta =
> > +   (u64)timespec_to_ns(&delta_time);
> > +   speed_timedelta = div64_u64(speed_timedelta,
> > +   100); /* nsec -> usec */
> > +   printk(KERN_INFO "TS speed %llu Kbits/sec \n",
> > +   div64_u64(speed_bytes,
> > +   speed_timedelta));
> > +   };
> > +
> > +   demux->speed_last_time = cur_time;
> > +   demux->speed_pkts_cnt = 0;
> > +   };
> > +   };
> >
> > if (dvb_demux_tscheck) {
> > if (!demux->cnt_storage)
> > --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.h  Wed Sep 23 10:21:53
> > 2009 +0200 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.h   Thu Sep 
> > 24
> > 18:24:37 2009 +0400 @@ -44,6 +44,7 @@
> >  #define DVB_DEMUX_MASK_MAX 18
> >
> >  #define MAX_PID 0x1fff
> > +#define SPEED_PKTS_INTERVAL 5
> >
> >  struct dvb_demux_filter {
> > struct dmx_section_filter filter;
> > @@ -132,6 +133,9 @@
> > spinlock_t lock;
> >
> > uint8_t *cnt_storage; /* for TS continuity check */
> > +
> > +   struct timespec speed_last_time; /* for TS speed check */
> > +   uint32_t speed_pkts_cnt; /* for TS speed check */
> >  };
> >
> >  int dvb_dmx_init(struct dvb_demux *dvbdemux);
>
> 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

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

Re: Soc camera:Is there anyone dealing with ov9650chip?Let's talk about soc camera driver.

[Guennadi Liakhovetski]

On Sun, 1 Nov 2009, Jonathan Cameron wrote:

> dean_go Zhang wrote:
> > I'm reading to documentation in linux-2.6.30,and ov7670 driver ,and I'm
> > trying to make a driver for ov9650.
> > 
> > struct soc_camera_ops provides .probe and .remove methods, which are
> > called by
> > the soc-camera core, when a camera is matched against or removed
> > from a camera
> > host bus, .init, .release, .suspend, and .resume are called from the
> > camera host
> > driver as discussed above. Other members of this struct provide
> > respective V4L2
> > functionality.
> > 
> >  
> > This is from the documentation,but I didn't find any thing about
> > soc_camera_host_device in ov7670's driver code.
> > Does anyone know how to make a v4l2 soc camera driver? 
> This isn't really an arm related question.  Should really be asked on
> linux-media. (now cc'd along with Guennadi)
> 
> Having said that...
> 
> The reason you aren't finding soc camera related stuff in the ov7670 driver
> is that it isn't currently a soc camera driver.  There is ongoing work to
> move the soc-camera framework fully over to using v4l2-subdevs thus allowing
> drivers like this one to work both with soc-camera interfaces and others.
> 
> There are still a few elements being cleaned up (primarily to do with
> negotiation of image formats) that make it tricky for a single driver to
> directly support use through soc camera and without it. 
> 
> I would suggest looking in the linux-media archive for
> Guennanadi Liakhovetski's latest imagebus patches for what still needs doing.
> 
> In meantime, the following patch against 2.6.32-rc5 adds soc camera support 
> to the
> ov7670 driver.  I've been posting updates tracking Guennadi's changes to soc 
> camera
> to linux-media (though I haven't had a chance to do the recent imagebus 
> changes yet).
> 
> Unfortunately omnivision aren't exactly free with datasheets (I can get the 
> ov9650 from
> google but not the ov9640), so I can't check, but based purely on numbering 
> how does
> this chip compare to the ov9640 which as a driver in kernel (probably in a 
> queue
> for next merge window?

Yes, we didn't manage to push it for 2.6.32, so, it should be merged for 
2.6.33.

> - it's certainly in the tree Guennadi is using and has been
> posted to linux-media)
> 
> Google did however give me this hit, which mentions an ov9650 driver
> http://marex-hnd.blogspot.com/2009/08/omnivision-ov9640-hacking-part-iv.html
> Perhaps Guennadi has more info on this?

Well, I think, the post describes the situation correctly - none of the 
drivers can currently handle both 9640 and 9650, and they do seem to be 
different enough to deserve separate drivers. As for 9655, the posting is 
not quite correct, saying that "For that model there's another driver 
scheduled for merge written by Stefan Herbrechtsmeier," the reak situation 
is, that there is already a gspca driver in the mainline kernel for that 
sensor, and it would be preferable to re-use that one instead of 
committing a new one. This is similar to the situation with the ov7670 
sensor.

As for ways to enable the use of sensor (video-client) with soc-camera and 
other frameworks, I'll try to prepare a proposal for that to standardise 
the use of the platform_data field of the underlying device, in the common 
i2c case it's the client->dev.platform_data link. Having done that we will 
be able to do checks for which framework we're currently using like in the 
patch below. Until then, unfortunately, such testing is not safe.

Thanks
Guennadi

> 
> 
> >From 408902c5584796924f8f9903f6c7338db4a0fd0f Mon Sep 17 00:00:00 2001
> From: Jonathan Cameron 
> Date: Sat, 4 Jul 2009 13:25:06 +
> Subject: [PATCH 02/10] ov7670: Temporary soc-camera support
> 
> Signed-off-by: Jonathan Cameron 
> ---
>  drivers/media/video/ov7670.c |   50 
> ++
>  1 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
> index 0e2184e..910a499 100644
> --- a/drivers/media/video/ov7670.c
> +++ b/drivers/media/video/ov7670.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
>  
>  MODULE_AUTHOR("Jonathan Corbet ");
>  MODULE_DESCRIPTION("A low-level driver for OmniVision ov7670 sensors");
> @@ -745,6 +747,10 @@ static int ov7670_s_fmt(struct v4l2_subdev *sd, struct 
> v4l2_format *fmt)
>   struct ov7670_info *info = to_state(sd);
>   unsigned char com7, clkrc = 0;
>  
> + ret = ov7670_init(sd, 0);
> + if (ret)
> + return ret;
> +
>   ret = ov7670_try_fmt_internal(sd, fmt, &ovfmt, &wsize);
>   if (ret)
>   return ret;
> @@ -1239,6 +1245,41 @@ static const struct v4l2_subdev_ops ov7670_ops = {
>  };
>  
>  /* --- */
> +static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device 
> *icd)
> +{
> + struct s

[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:Sun Nov  1 19:00:06 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13263:43878f8dbfb0
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: WARNINGS
linux-2.6.23.12-armv5: WARNINGS
linux-2.6.24.7-armv5: WARNINGS
linux-2.6.25.11-armv5: WARNINGS
linux-2.6.26-armv5: WARNINGS
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-rc3-armv5: ERRORS
linux-2.6.32-rc3-armv5-davinci: ERRORS
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29.1-armv5-ixp: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-rc3-armv5-ixp: ERRORS
linux-2.6.28-armv5-omap2: OK
linux-2.6.29.1-armv5-omap2: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: ERRORS
linux-2.6.32-rc3-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-rc3-i686: ERRORS
linux-2.6.23.12-m32r: WARNINGS
linux-2.6.24.7-m32r: WARNINGS
linux-2.6.25.11-m32r: WARNINGS
linux-2.6.26-m32r: WARNINGS
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-rc3-m32r: ERRORS
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-rc3-mips: ERRORS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-rc3-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-rc3-x86_64: ERRORS
sparse (linux-2.6.31): OK
sparse (linux-2.6.32-rc3): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L2 specification failed to build, but the last compiled spec is here:

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

The DVB API specification failed to build, but the last compiled spec 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: cx18: YUV frame alignment improvements

[Brandon Jenkins]

On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls  wrote:
> On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
>> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls  wrote:
>> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
>> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls  wrote:
>> >
>> >>
>> >> Hi Andy,
>> >>
>> >> How does this code work if the cx23418 scaler is used (resulting in
>> >> the size of the frames to be non-constant)?  Or is the scaler not
>> >> currently supported in the driver?
>> >
>> > I also forgot to mention, changing size while the encoder has an analog
>> > stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
>> > So this change works just fine as it computes the buffer size to use
>> > just as it sets up to start the capture.
>> >
>> > Regards,
>> > Andy
>
>> Hi Andy,
>
> Hi Brandon,
>
>> I tried to pull your changes and received an error on a missing .hg.
>
> Sorry, I can't help there.  The following should work:
>
> hg clone http://linuxtv.org/hg/~awalls/cx18-yuv
>
>
>> Subsequently, I downloaded the bz2 file and upon reboot I received a
>> kernel panic due to DMA issues.
>
> Did it fail on MPEG or Digital TS captures or on a YUV capture?
>
> Did you try setting enc_yuv_bufs=0, to inhibit YUV buffer allocation, to
> see if the panic went away?
>
> Could you provide the panic to me?  Off-list is fine.
>
> If I can't get this large buffer scheme to work for the general case to
> mainatin YUV frame alignment, I'll have to figure out what will likely
> be a much more complex scheme to ensure alignment is maintained in for
> YUV streams. :(
>
> Oh, well.
>
> Regards,
> Andy
>
>
>
Hi Andy,

The panic happens upon reboot and it is only 1 line of text oddly shifted.

Kernel panic - not syncing: DMA: Memory would be corrupted

If I switch back to the current v4l-dvb drivers no issue. To switch
back I have to boot from a USB drive.

Brandon
--
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: Soc camera:Is there anyone dealing with ov9650chip?Let's talk about soc camera driver.

[Jonathan Cameron]

dean_go Zhang wrote:
> I'm reading to documentation in linux-2.6.30,and ov7670 driver ,and I'm
> trying to make a driver for ov9650.
> 
> struct soc_camera_ops provides .probe and .remove methods, which are
> called by
> the soc-camera core, when a camera is matched against or removed
> from a camera
> host bus, .init, .release, .suspend, and .resume are called from the
> camera host
> driver as discussed above. Other members of this struct provide
> respective V4L2
> functionality.
> 
>  
> This is from the documentation,but I didn't find any thing about
> soc_camera_host_device in ov7670's driver code.
> Does anyone know how to make a v4l2 soc camera driver? 
This isn't really an arm related question.  Should really be asked on
linux-media. (now cc'd along with Guennadi)

Having said that...

The reason you aren't finding soc camera related stuff in the ov7670 driver
is that it isn't currently a soc camera driver.  There is ongoing work to
move the soc-camera framework fully over to using v4l2-subdevs thus allowing
drivers like this one to work both with soc-camera interfaces and others.

There are still a few elements being cleaned up (primarily to do with
negotiation of image formats) that make it tricky for a single driver to
directly support use through soc camera and without it. 

I would suggest looking in the linux-media archive for
Guennanadi Liakhovetski's latest imagebus patches for what still needs doing.

In meantime, the following patch against 2.6.32-rc5 adds soc camera support to 
the
ov7670 driver.  I've been posting updates tracking Guennadi's changes to soc 
camera
to linux-media (though I haven't had a chance to do the recent imagebus changes 
yet).

Unfortunately omnivision aren't exactly free with datasheets (I can get the 
ov9650 from
google but not the ov9640), so I can't check, but based purely on numbering how 
does
this chip compare to the ov9640 which as a driver in kernel (probably in a queue
for next merge window? - it's certainly in the tree Guennadi is using and has 
been
posted to linux-media)

Google did however give me this hit, which mentions an ov9650 driver
http://marex-hnd.blogspot.com/2009/08/omnivision-ov9640-hacking-part-iv.html
Perhaps Guennadi has more info on this?


>From 408902c5584796924f8f9903f6c7338db4a0fd0f Mon Sep 17 00:00:00 2001
From: Jonathan Cameron 
Date: Sat, 4 Jul 2009 13:25:06 +
Subject: [PATCH 02/10] ov7670: Temporary soc-camera support

Signed-off-by: Jonathan Cameron 
---
 drivers/media/video/ov7670.c |   50 ++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..910a499 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include 
+#include 
 
 MODULE_AUTHOR("Jonathan Corbet ");
 MODULE_DESCRIPTION("A low-level driver for OmniVision ov7670 sensors");
@@ -745,6 +747,10 @@ static int ov7670_s_fmt(struct v4l2_subdev *sd, struct 
v4l2_format *fmt)
struct ov7670_info *info = to_state(sd);
unsigned char com7, clkrc = 0;
 
+   ret = ov7670_init(sd, 0);
+   if (ret)
+   return ret;
+
ret = ov7670_try_fmt_internal(sd, fmt, &ovfmt, &wsize);
if (ret)
return ret;
@@ -1239,6 +1245,41 @@ static const struct v4l2_subdev_ops ov7670_ops = {
 };
 
 /* --- */
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device *icd)
+{
+   struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+   unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+   SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+   SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+   return soc_camera_apply_sensor_flags(icl, flags);
+}
+
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+   unsigned long flags)
+{
+   return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+   .set_bus_param = ov7670_soc_set_bus_param,
+   .query_bus_param = ov7670_soc_query_bus_param,
+};
+
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+   {
+   SETFOURCC(YUYV),
+   .depth = 16,
+   .colorspace = V4L2_COLORSPACE_JPEG,
+   }, {
+   SETFOURCC(RGB565),
+   .depth = 16,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   },
+};
 
 static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -1246,7 +1287,16 @@ static int ov7670_probe(struct i2c_client *client,
struct v4l2_subdev *sd;
struct ov7670_info *info;
int ret;
+   str

bug in changeset 13239:54535665f94b ?

[e9hack]

Hi,

something is wrong in changeset 13239:54535665f94b. After applying it, I get 
page faults
in various applications:
...
Oct 31 17:36:35 vdr dhcpcd[3280]: wlan1: adding default route via 192.168.23.1 
metric 0
Oct 31 17:36:35 vdr dhcpcd[3280]: wlan1: adding route to 169.254.0.0/16 metric 0
Oct 31 17:36:36 vdr kernel: [   25.759549] DEBI rx: 0(0)kB/s size=188/188/188 
cnt=0/s, tx:
0(0)kB/s size=0/0/0 cnt=0/s
Oct 31 17:36:36 vdr kernel: [   25.787398] video directory[3249]: segfault at 
7f8e8be1139d
ip 7f8e8be125ce sp 42312280 error 7 in 
libc-2.8.so[7f8e8bdbb000+14f000]
Oct 31 17:36:36 vdr modify_resolvconf: Service dhcpcd modified 
/etc/resolv.conf. See info
block in this file
Oct 31 17:36:36 vdr dhcpcd[3280]: wlan1: exiting
Oct 31 17:36:36 vdr kernel: [   25.858000] killproc[3380]: segfault at a18 ip
7f2441b1b0b7 sp 7fffbee296c0 error 6 in libc-2.8.so[7f2441ac4000+14f000]
Oct 31 17:36:36 vdr kernel: [   25.860567] killproc[3381]: segfault at a15 ip
7fc02b4ad0b7 sp 7fff554387e0 error 6 in libc-2.8.so[7fc02b456000+14f000]
Oct 31 17:36:36 vdr kernel: [   25.862552] killproc[3382]: segfault at a18 ip
7f2016d9f0b7 sp 7fff6e366b90 error 6 in libc-2.8.so[7f2016d48000+14f000]
Oct 31 17:36:36 vdr kernel: [   25.864523] killproc[3383]: segfault at a18 ip
7f91d85df0b7 sp 7fff8b13f2c0 error 6 in libc-2.8.so[7f91d8588000+14f000]
Oct 31 17:36:36 vdr ifdown: wlan1
Oct 31 17:36:36 vdr kernel: [   25.942528] killproc[3416]: segfault at 1 ip
7fdcdeccb0b7 sp 7fff33c2ff00 error 6 in libc-2.8.so[7fdcdec74000+14f000]
Oct 31 17:36:36 vdr kernel: [   25.965127] ip[3423]: segfault at 0 ip 
7fb0dc50b47e sp
7fffbf6d2790 error 6 in libc-2.8.so[7fb0dc4b4000+14f000]
Oct 31 17:36:36 vdr ifup: wlan1
Oct 31 17:36:36 vdr SuSEfirewall2: /var/lock/SuSEfirewall2.booting exists which 
means
system boot in progress, exit.
Oct 31 17:36:36 vdr ifup-dhcp: IP/Netmask: '192.168.23.6'
Oct 31 17:36:36 vdr ifup-dhcp:  / '255.255.255.0'
Oct 31 17:36:36 vdr ifup-dhcp:  ('vdr')
Oct 31 17:36:36 vdr ifup-dhcp:
Oct 31 17:36:36 vdr kernel: [   26.567896] ip[3551]: segfault at 0 ip 
7f8c9b00f47e sp
7fff71063240 error 6 in libc-2.8.so[7f8c9afb8000+14f000]
Oct 31 17:36:36 vdr kernel: [   26.664260] startproc[3587]: segfault at 99f ip
7fa6c35790b7 sp 7fffc6d713c0 error 6 in libc-2.8.so[7fa6c3522000+14f000]
...


If I remove the call to release_all_pagetables() in buffer_release(), I don't 
see this
page faults.

Regards,
Hartmut
--
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://kernellabs.com/hg/~mkrufky/dtv1000s

[Michael Krufky]

On Sun, Nov 1, 2009 at 5:13 AM, Mauro Carvalho Chehab
 wrote:
> Em Sat, 31 Oct 2009 13:10:16 -0400
> Michael Krufky  escreveu:
>
>> On Sat, Oct 31, 2009 at 12:51 PM, Michael Krufky  
>> wrote:
>> > Please pull from:
>> >
>> > http://kernellabs.com/hg/~mkrufky/dtv1000s
>> >
>> > for:
>> >
>> > - saa7134: fix badly merged DTV1000S patch
>> >
>> >  saa7134-cards.c |   32 
>> >  1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> I sent this pull request out too quickly -- I just added a patch for
>> Leadtek Winfast DTV-1000S remote control, thanks to Michael Obst.
>>
>> Please pull, for:
>>
>> - saa7134: fix badly merged DTV1000S patch
>> - saa7134: add support for Leadtek Winfast DTV-1000S remote control
>
> saa7134: add support for Leadtek Winfast DTV-1000S remote control
> ERROR: do not use C99 // comments
> #46: FILE: linux/drivers/media/video/saa7134/saa7134-input.c:664:
> +               polling      = 50; // ms
>
> total: 1 errors, 0 warnings, 26 lines checked

Mauro,

Thank you for merging so quickly -- I really appreciate that.  As you
pointed out above, there was a codingstyle cleanup needed in
saa7134-input.c --  I've taken care of that.

Please pull from:

http://kernellabs.com/hg/~mkrufky/cleanup

for:

- saa7134: codingstyle: use /* style comments */ instead of //

 saa7134-input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cheers,

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

EM2880 - leadtek winfast usb ii

[Gerry Ford]

Device is a Leadtek Winfast usb II box

usb 1-8: new high speed USB device using ehci_hcd and address 4
usb 1-8: configuration #1 chosen from 1 choice
em28xx: New device @ 480 Mbps (eb1a:2800, interface 0, class 0)
em28xx #0: Identified as Unknown EM2800 video grabber (card=0)
em28xx #0: em28xx chip ID = 2
em28xx #0: board has no eeprom
em28xx #0: found i2c device @ 0x30 [???]
em28xx #0: found i2c device @ 0x3e [???]
em28xx #0: found i2c device @ 0x4a [saa7113h]
em28xx #0: found i2c device @ 0x86 [tda9887]
em28xx #0: found i2c device @ 0xb0 [tda9874]
em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
em28xx #0: Your board has no unique USB ID and thus need a hint to be
detected.
em28xx #0: You may try to use card= insmod option to workaround that.
em28xx #0: Please send an email with this log to:
em28xx #0:  V4L Mailing List 
em28xx #0: Board eeprom hash is 0x
em28xx #0: Board i2c devicelist hash is 0x81bb00dc
em28xx #0: Here is a list of valid choices for the card= insmod
option:
em28xx #0: card=0 -> Unknown EM2800 video grabber
em28xx #0: card=1 -> Unknown EM2750/28xx video grabber
em28xx #0: card=2 -> Terratec Cinergy 250 USB
em28xx #0: card=3 -> Pinnacle PCTV USB 2
em28xx #0: card=4 -> Hauppauge WinTV USB 2
em28xx #0: card=5 -> MSI VOX USB 2.0
em28xx #0: card=6 -> Terratec Cinergy 200 USB
em28xx #0: card=7 -> Leadtek Winfast USB II
em28xx #0: card=8 -> Kworld USB2800
em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser
Baas Video to DVD maker
em28xx #0: card=10 -> Hauppauge WinTV HVR 900
em28xx #0: card=11 -> Terratec Hybrid XS
em28xx #0: card=12 -> Kworld PVR TV 2800 RF
em28xx #0: card=13 -> Terratec Prodigy XS
em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV
USB 2.0
em28xx #0: card=15 -> V-Gear PocketTV
em28xx #0: card=16 -> Hauppauge WinTV HVR 950
em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick
em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2)
em28xx #0: card=19 -> EM2860/SAA711X Reference Design
em28xx #0: card=20 -> AMD ATI TV Wonder HD 600
em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder
em28xx #0: card=22 -> Unknown EM2750/EM2751 webcam grabber
em28xx #0: card=23 -> Huaqi DLCW-130
em28xx #0: card=24 -> D-Link DUB-T210 TV Tuner
em28xx #0: card=25 -> Gadmei UTV310
em28xx #0: card=26 -> Hercules Smart TV USB 2.0
em28xx #0: card=27 -> Pinnacle PCTV USB 2 (Philips FM1216ME)
em28xx #0: card=28 -> Leadtek Winfast USB II Deluxe
em28xx #0: card=29 -> 
em28xx #0: card=30 -> Videology 20K14XUSB USB2.0
em28xx #0: card=31 -> Usbgear VD204v9
em28xx #0: card=32 -> Supercomp USB 2.0 TV
em28xx #0: card=33 -> 
em28xx #0: card=34 -> Terratec Cinergy A Hybrid XS
em28xx #0: card=35 -> Typhoon DVD Maker
em28xx #0: card=36 -> NetGMBH Cam
em28xx #0: card=37 -> Gadmei UTV330
em28xx #0: card=38 -> Yakumo MovieMixer
em28xx #0: card=39 -> KWorld PVRTV 300U
em28xx #0: card=40 -> Plextor ConvertX PX-TV100U
em28xx #0: card=41 -> Kworld 350 U DVB-T
em28xx #0: card=42 -> Kworld 355 U DVB-T
em28xx #0: card=43 -> Terratec Cinergy T XS
em28xx #0: card=44 -> Terratec Cinergy T XS (MT2060)
em28xx #0: card=45 -> Pinnacle PCTV DVB-T
em28xx #0: card=46 -> Compro, VideoMate U3
em28xx #0: card=47 -> KWorld DVB-T 305U
em28xx #0: card=48 -> KWorld DVB-T 310U
em28xx #0: card=49 -> MSI DigiVox A/D
em28xx #0: card=50 -> MSI DigiVox A/D II
em28xx #0: card=51 -> Terratec Hybrid XS Secam
em28xx #0: card=52 -> DNT DA2 Hybrid
em28xx #0: card=53 -> Pinnacle Hybrid Pro
em28xx #0: card=54 -> Kworld VS-DVB-T 323UR
em28xx #0: card=55 -> Terratec Hybrid XS (em2882)
em28xx #0: card=56 -> Pinnacle Hybrid Pro (2)
em28xx #0: card=57 -> Kworld PlusTV HD Hybrid 330
em28xx #0: card=58 -> Compro VideoMate ForYou/Stereo
em28xx #0: card=59 -> 
em28xx #0: card=60 -> Hauppauge WinTV HVR 850
em28xx #0: card=61 -> Pixelview PlayTV Box 4 USB 2.0
em28xx #0: card=62 -> Gadmei TVR200
em28xx #0: card=63 -> Kaiomy TVnPC U2
em28xx #0: card=64 -> Easy Cap Capture DC-60
em28xx #0: card=65 -> IO-DATA GV-MVP/SZ
em28xx #0: card=66 -> Empire dual TV
em28xx #0: card=67 -> Terratec Grabby
em28xx #0: card=68 -> Terratec AV350
em28xx #0: card=69 -> KWorld ATSC 315U HDTV TV Box
saa7115 1-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0)
em28xx #0: Config register raw data: 0x89
em28xx #0: v4l2 driver version 0.1.2
em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0
usb 1-8: New USB device found, idVendor=eb1a, idProduct=2800
usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0


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

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

[Douglas Schilling Landgraf]

Hello Mauro,

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

- dib0700_devices: EvolutePC TvWay+ USB ISDB-Tb remote control
supportdefault tip
- dib7000p: gcc 4.3.3 compilation problem
- libv4l - spca561: Have static decoding tables
- sms1xxx: load smsdvb also for the hauppauge tiger cards
- em28xx: memset region size error
- dvb-usb-friio: cleaning up unnecessary functions
- dvb-usb-friio: return the correct DTV_DELIVERY_SYSTEM
- pac_common: redesign function for finding Start Of Frame
- tvp514x: recognize the error case in tvp514x_read_reg()
- Fix adv7180 build failures with old kernels
- em28xx-dvb: Convert printks to em28xx_err and em28xx_info
- em28xx-audio: Convert printks to em28xx_err
- adding __init/__exit macros to various drivers
- ce6230 - saa7164-cmd: Fix wrong sizeof
- pxa-camera: Fix missing sched.h
- vpfe_capture: keep index within bound in vpfe_cropcap()

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

Re: cx18: YUV frame alignment improvements

[Andy Walls]

On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls  wrote:
> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls  wrote:
> >
> >>
> >> Hi Andy,
> >>
> >> How does this code work if the cx23418 scaler is used (resulting in
> >> the size of the frames to be non-constant)?  Or is the scaler not
> >> currently supported in the driver?
> >
> > I also forgot to mention, changing size while the encoder has an analog
> > stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
> > So this change works just fine as it computes the buffer size to use
> > just as it sets up to start the capture.
> >
> > Regards,
> > Andy

> Hi Andy,

Hi Brandon,

> I tried to pull your changes and received an error on a missing .hg.

Sorry, I can't help there.  The following should work:

hg clone http://linuxtv.org/hg/~awalls/cx18-yuv


> Subsequently, I downloaded the bz2 file and upon reboot I received a
> kernel panic due to DMA issues.

Did it fail on MPEG or Digital TS captures or on a YUV capture?

Did you try setting enc_yuv_bufs=0, to inhibit YUV buffer allocation, to
see if the panic went away?

Could you provide the panic to me?  Off-list is fine.

If I can't get this large buffer scheme to work for the general case to
mainatin YUV frame alignment, I'll have to figure out what will likely
be a much more complex scheme to ensure alignment is maintained in for
YUV streams. :(

Oh, well.

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: [linux-dvb] somebody messed something on xc2028 code?

[Damien Morrissey]

On Sun, Nov 1, 2009 at 3:23 AM, Devin Heitmueller
 wrote:
>
> On Sat, Oct 31, 2009 at 8:35 AM, Albert Comerma
>  wrote:
> > Hi all, I just updated my ubuntu to karmic and found with surprise that with
> > 2.6.31 kernel my device does not work... It seems to be related to the
> > xc2028 code part since the kernel explosion happens when you try to tune the
> > device, here it's my dmesg, any idea?
> >
> > Albert
>
> Oh, you're using the stock 2.6.31 which didn't get my fix yet.  Please
> try the latest v4l-dvb tree and see if it still happens.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> ___
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Might this have something to with problems that I am having with the
Dvico dual digital 4 with karmic?
--
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://bitbucket.org/davidtlwong/mygica_x850x_hybrid

[David T. L. Wong]

Mauro Carvalho Chehab wrote:

Hi David,

Em Wed, 21 Oct 2009 22:46:23 +0800
"David T. L. Wong"  escreveu:


Hi Mauro,

Please pull from,

http://bitbucket.org/davidtlwong/mygica_x850x_hybrid

for following changeset:
- cx25840: add component support
- cx23885: add component input type
- cx23885: fix uninitialized member bug
- cx23885: card mygica x8506 add analog video input support


There are lots of patches on your tree with the SOB missing. Please send your
SOB for me to fix them at my -git tree.



Cheers,
Mauro


Hi Mauro,

  Sorry for that, I just learn how to add SOB in HG from Douglas Landgraf.

  Here's my SOB:
David T. L. Wong 


David
--
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://bitbucket.org/davidtlwong/mygica_x850x_hybrid

[Mauro Carvalho Chehab]

Hi David,

Em Wed, 21 Oct 2009 22:46:23 +0800
"David T. L. Wong"  escreveu:

> Hi Mauro,
> 
> Please pull from,
> 
> http://bitbucket.org/davidtlwong/mygica_x850x_hybrid
> 
> for following changeset:
> - cx25840: add component support
> - cx23885: add component input type
> - cx23885: fix uninitialized member bug
> - cx23885: card mygica x8506 add analog video input support

There are lots of patches on your tree with the SOB missing. Please send your
SOB for me to fix them at my -git tree.



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

MSI StarCam Racer - No valid video chain found

[Martin Rod]

Hi,

I use MSI StarCam Racer  on Debian Linux Lenny 2.6.26-1-686 and video 
works without problem:


usb 4-4: New USB device found, idVendor=0c45, idProduct=62e0
usb 4-4: New USB device strings: Mfr=2, Product=1,SerialNumber=0
usb 4-4: Product: USB 2.0 Camera
usb 4-4: Manufacturer: Sonix Technology Co., Ltd.

I  plan use this camera on OpenWrt, (UBNT Router Station, kernel 
2.6.30.9) and kernel didn't open this device:


Linux video capture interface: v2.00
usbcore: registered new interface driver uvcvideo
USB Video Class driver (v0.1.0)
usb 1-1: new high speed USB device using ar71xx-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:62e0)
uvcvideo: No valid video chain found.

Do you have any idea?

Thanks and best regards,

Martin







--
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://kernellabs.com/hg/~mkrufky/dtv1000s

[Mauro Carvalho Chehab]

Em Sat, 31 Oct 2009 13:10:16 -0400
Michael Krufky  escreveu:

> On Sat, Oct 31, 2009 at 12:51 PM, Michael Krufky  
> wrote:
> > Please pull from:
> >
> > http://kernellabs.com/hg/~mkrufky/dtv1000s
> >
> > for:
> >
> > - saa7134: fix badly merged DTV1000S patch
> >
> >  saa7134-cards.c |   32 
> >  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> I sent this pull request out too quickly -- I just added a patch for
> Leadtek Winfast DTV-1000S remote control, thanks to Michael Obst.
> 
> Please pull, for:
> 
> - saa7134: fix badly merged DTV1000S patch
> - saa7134: add support for Leadtek Winfast DTV-1000S remote control

saa7134: add support for Leadtek Winfast DTV-1000S remote control
ERROR: do not use C99 // comments
#46: FILE: linux/drivers/media/video/saa7134/saa7134-input.c:664:
+   polling  = 50; // ms

total: 1 errors, 0 warnings, 26 lines checked





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 00/21] gspca pac7302/pac7311: separate the two drivers

[Jean-Francois Moine]

On Sun, 01 Nov 2009 00:13:10 +0100
Németh Márton  wrote:

> the following patchset refactores the Pixart PAC7311 subdriver. The
> current situation is that the code contains a lot of decisions
> like this:
> 
> if (sd->sensor == SENSOR_PAC7302) {
> ... do this ...
> } else {
> ... do something else ...
> }
> 
> The sensor type is determined using the USB Vendor ID and Product
> ID which means that the decisions shown are not really necessary.
> 
> The goal of the patchset is to have a PAC7302 and a PAC7311 subdriver
> which have the benefit that there is no decision necessary on sensor
> type at runtime. The common functions can be extracted later but this
> would be a different patchset.

Hello Márton,

Splitting the pac7311 subdriver is a good idea, but I don't like your
patchset: a lot of changes (function prefixes) are nullified by the
last patch. I'd better like only one change for the pac7302 creation
and a second one for the interface change of pac_find_sof() in
pac_common.h (BTW, this file could now be compiled separately).

Regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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