[PATCH] pt1: Support FE_READ_SNR

2009-11-08 Thread hiranotaka
pt1: Support FE_READ_SNR

Signed-off-by: HIRANO Takahito hiranot...@zng.info

diff -r bb412b4e19a0 -r b386a38c7a1e linux/drivers/media/dvb/pt1/va1j5jf8007s.c
--- a/linux/drivers/media/dvb/pt1/va1j5jf8007s.cSun Nov 01 03:59:42 
2009 +0900
+++ b/linux/drivers/media/dvb/pt1/va1j5jf8007s.cSun Nov 08 17:37:13 
2009 +0900
@@ -48,6 +48,60 @@
enum va1j5jf8007s_tune_state tune_state;
 };
 
+static int va1j5jf8007s_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+   struct va1j5jf8007s_state *state;
+   u8 addr;
+   int i;
+   u8 write_buf[1], read_buf[1];
+   struct i2c_msg msgs[2];
+   s32 word, x1, x2, x3, x4, x5, y;
+
+   state = fe-demodulator_priv;
+   addr = state-config-demod_address;
+
+   word = 0;
+   for (i = 0; i  2; i++) {
+   write_buf[0] = 0xbc + i;
+
+   msgs[0].addr = addr;
+   msgs[0].flags = 0;
+   msgs[0].len = sizeof(write_buf);
+   msgs[0].buf = write_buf;
+
+   msgs[1].addr = addr;
+   msgs[1].flags = I2C_M_RD;
+   msgs[1].len = sizeof(read_buf);
+   msgs[1].buf = read_buf;
+
+   if (i2c_transfer(state-adap, msgs, 2) != 2)
+   return -EREMOTEIO;
+
+   word = 8;
+   word |= read_buf[0];
+   }
+
+   word -= 3000;
+   if (word  0)
+   word = 0;
+
+   x1 = int_sqrt(word  16) * ((15625ll  21) / 100);
+   x2 = (s64)x1 * x1  31;
+   x3 = (s64)x2 * x1  31;
+   x4 = (s64)x2 * x2  31;
+   x5 = (s64)x4 * x1  31;
+
+   y = (58857ll  23) / 1000;
+   y -= (s64)x1 * ((89565ll  24) / 1000)  30;
+   y += (s64)x2 * ((88977ll  24) / 1000)  28;
+   y -= (s64)x3 * ((50259ll  25) / 1000)  27;
+   y += (s64)x4 * ((14341ll  27) / 1000)  27;
+   y -= (s64)x5 * ((16346ll  30) / 1)  28;
+
+   *snr = y  0 ? 0 : y  15;
+   return 0;
+}
+
 static int va1j5jf8007s_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
@@ -536,6 +590,7 @@
FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
},
 
+   .read_snr = va1j5jf8007s_read_snr,
.get_frontend_algo = va1j5jf8007s_get_frontend_algo,
.read_status = va1j5jf8007s_read_status,
.tune = va1j5jf8007s_tune,
diff -r bb412b4e19a0 -r b386a38c7a1e linux/drivers/media/dvb/pt1/va1j5jf8007t.c
--- a/linux/drivers/media/dvb/pt1/va1j5jf8007t.cSun Nov 01 03:59:42 
2009 +0900
+++ b/linux/drivers/media/dvb/pt1/va1j5jf8007t.cSun Nov 08 17:37:13 
2009 +0900
@@ -46,6 +46,52 @@
enum va1j5jf8007t_tune_state tune_state;
 };
 
+static int va1j5jf8007t_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+   struct va1j5jf8007t_state *state;
+   u8 addr;
+   int i;
+   u8 write_buf[1], read_buf[1];
+   struct i2c_msg msgs[2];
+   s32 word, x, y;
+
+   state = fe-demodulator_priv;
+   addr = state-config-demod_address;
+
+   word = 0;
+   for (i = 0; i  3; i++) {
+   write_buf[0] = 0x8b + i;
+
+   msgs[0].addr = addr;
+   msgs[0].flags = 0;
+   msgs[0].len = sizeof(write_buf);
+   msgs[0].buf = write_buf;
+
+   msgs[1].addr = addr;
+   msgs[1].flags = I2C_M_RD;
+   msgs[1].len = sizeof(read_buf);
+   msgs[1].buf = read_buf;
+
+   if (i2c_transfer(state-adap, msgs, 2) != 2)
+   return -EREMOTEIO;
+
+   word = 8;
+   word |= read_buf[0];
+   }
+
+   if (!word)
+   return -EIO;
+
+   x = 10 * (intlog10(0x54 * 100 / word) - (2  24));
+   y = (24ll  46) / 100;
+   y = ((s64)y * x  30) - (16ll  40) / 1;
+   y = ((s64)y * x  29) + (398ll  35) / 1;
+   y = ((s64)y * x  30) + (5491ll  29) / 1;
+   y = ((s64)y * x  30) + (30965ll  23) / 1;
+   *snr = y  15;
+   return 0;
+}
+
 static int va1j5jf8007t_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
@@ -393,6 +439,7 @@
FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
},
 
+   .read_snr = va1j5jf8007t_read_snr,
.get_frontend_algo = va1j5jf8007t_get_frontend_algo,
.read_status = va1j5jf8007t_read_status,
.tune = va1j5jf8007t_tune,
--
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: pac7302: INFO: possible circular locking dependency detected

2009-11-08 Thread Hans de Goede

Hi,

I've taken a long time to analyse the below lock dep report, and what can I say,
it is nasty.

This could happen (task could be a thread too):
Task 1: Does a readdir on sysfs
Task 1: Takes sysfs Mutex
Task 2: Does an mmap on the video device
Task 2: Takes mmap semphore
Task 1: Is now stuck waiting for mmap semaphore
Task 3: Does a streamon ioctl on video device
Task 3: Takes queue lock
Task 2: Is now stuck waiting on queue lock
Task 3: Task usb lock
Task 3: Does a usb_set_interface
Task 3: Is now stuck as usb_set_interface wants sysfs mutex

And the is nothing we can do here, as we cannot serialize mmap / ioctl calls at 
the
level needed (before mmap taking the mmap semaphore).


There are 2 surprising things in here, which together cause the circular 
problem:

1) A simple readdir on a sysfs dir takes the mmap semaphore
2) A simple usb_set_interface (only changing the alt setting!) takes the sysfs 
mutex

1 of these 2 is new in 2.6.32 I think otherwise we would have seen this before. 
So first of
all we should take this discussion to the general kernel mailing list and try 
to get one
of these 2 fixed.

Alternatively we could move the usb bandwidth negotiation (which does the 
usb_set_interface)
to device probe time, by pre-allocating the usb bandwidth, but we really don't 
want to do that,
as that means that in multiple isoc devices configurations only the first cam 
*probed* will
work (now usually only the first cam started works, which means atleast 
multiple cams can
be used but not at the same time).

Regards,

Hans

p.s.

About the usb control msg errors, I don't think they are related to this issue 
at all, no real
world app ever does a streamon and an mmap at the same time. As said if we 
could serialize mmap and
ioctl at a high enough level, things would be fine too.

Are you seeing this issue on uhci using machines, or is it more general ? Also 
keep in mind
the pac7302 is a very buggy device. I think we've had this issue (the need to 
sometimes plug
it in a second time) for as long as we support it.






On 11/06/2009 10:05 PM, Németh Márton wrote:

Hi,

sometimes when I plug my Labtec Webcam 2200 and then try to start capturing I 
get
no picture but some error message in dmesg. I am using 13326:40705fec2fb2 from
http://linuxtv.org/hg/v4l-dvb/ on top of Linux 2.6.32-rc6.

[ 2282.076229] usb 3-2: new full speed USB device using uhci_hcd and address 2
[ 2282.314601] usb 3-2: New USB device found, idVendor=093a, idProduct=2626
[ 2282.314622] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2282.317636] usb 3-2: configuration #1 chosen from 1 choice
[ 2282.562231] Linux video capture interface: v2.00
[ 2282.599805] gspca: main v2.7.0 registered
[ 2282.628561] gspca: probing 093a:2626
[ 2282.629052] usbcore: registered new interface driver snd-usb-audio
[ 2282.634125] gspca: /dev/video0 created
[ 2282.634563] usbcore: registered new interface driver pac7302
[ 2282.634602] pac7302: registered
[ 2298.627711]
[ 2298.627715] ===
[ 2298.627725] [ INFO: possible circular locking dependency detected ]
[ 2298.627734] 2.6.32-rc6 #1
[ 2298.627738] ---
[ 2298.627745] svv/3820 is trying to acquire lock:
[ 2298.627751]  (sysfs_mutex){+.+.+.}, at: [c110778b] 
sysfs_get_dirent+0x15/0x4c
[ 2298.627773]
[ 2298.627775] but task is already holding lock:
[ 2298.627781]  (gspca_dev-usb_lock){+.+...}, at: [f81400c2] 
gspca_init_transfer+0x20/0x384 [gspca_main]
[ 2298.627801]
[ 2298.627803] which lock already depends on the new lock.
[ 2298.627806]
[ 2298.627811]
[ 2298.627813] the existing dependency chain (in reverse order) is:
[ 2298.627819]
[ 2298.627821] -  #3 (gspca_dev-usb_lock){+.+...}:
[ 2298.627833][c105da6b] __lock_acquire+0x10e9/0x13ea
[ 2298.627846][c105de1f] lock_acquire+0xb3/0xd0
[ 2298.627856][c128619c] mutex_lock_interruptible_nested+0x50/0x37b
[ 2298.627869][f81400c2] gspca_init_transfer+0x20/0x384 [gspca_main]
[ 2298.627883][f81404a3] vidioc_streamon+0x4a/0x95 [gspca_main]
[ 2298.627895][f80d1384] __video_do_ioctl+0x167d/0x3688 [videodev]
[ 2298.627910][f80d365e] video_ioctl2+0x2cf/0x371 [videodev]
[ 2298.627923][f80cf15b] v4l2_unlocked_ioctl+0x2e/0x32 [videodev]
[ 2298.627936][c10d20d3] vfs_ioctl+0x22/0x69
[ 2298.627947][c10d2642] do_vfs_ioctl+0x484/0x4be
[ 2298.627958][c10d26bc] sys_ioctl+0x40/0x5a
[ 2298.627969][c10032a4] sysenter_do_call+0x12/0x38
[ 2298.627981]
[ 2298.627983] -  #2 (gspca_dev-queue_lock){+.+.+.}:
[ 2298.627994][c105da6b] __lock_acquire+0x10e9/0x13ea
[ 2298.628005][c105de1f] lock_acquire+0xb3/0xd0
[ 2298.628015][c128619c] mutex_lock_interruptible_nested+0x50/0x37b
[ 2298.628027][f814149d] dev_mmap+0x5a/0x1c7 [gspca_main]
[ 2298.628039][f80cf191] v4l2_mmap+0x32/0x3d [videodev]
[ 2298.628052][c10b5207] 

Re: [PATCH] gspca pac7302: add edge detect control

2009-11-08 Thread Hans de Goede

Hi,

On 11/07/2009 09:45 PM, Németh Márton wrote:

From: Márton Némethnm...@freemail.hu

Add edge detect control to pac7302 driver. When this control is turned
on the camera image is switched to black and white and the edges are
visualized. Bit 2 on page 0, register 0x55 controls this mode on
Labtec Webcam 2200 (USB ID 093a:2626).

Signed-off-by: Márton Némethnm...@freemail.hu


Why would anyone want such a control ? When adding controls, please only add
controls which are potentially useful to the end user. For sensors where
we have datasheets we can easily add a 50 or so controls if we want too, but
we deliberately don't do that.

Controls really should only be added when there is no sane default which works
for 99% of all cases, in this case clearly just showing a normal picture is
a very sane default, and allowing to control this behaviour is pretty much
useless.

Regards,

Hans




---
diff -upr b/linux/drivers/media/video/gspca/pac7302.c 
c/linux/drivers/media/video/gspca/pac7302.c
--- b/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 21:25:15.0 
+0100
+++ c/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 22:38:32.0 
+0100
@@ -56,6 +56,7 @@
 -++---
  0   | 0x0f..0x20 | setcolors()
  0   | 0xa2..0xab | setbrightcont()
+0   | 0x55   | setedgedetect()
  0   | 0xc5   | setredbalance()
  0   | 0xc6   | setwhitebalance()
  0   | 0xc7   | setbluebalance()
@@ -89,6 +90,7 @@ struct sd {
unsigned char autogain;
__u8 hflip;
__u8 vflip;
+   unsigned char edge_detect;

u8 sof_read;
u8 autogain_ignore_frames;
@@ -119,6 +121,11 @@ static int sd_setgain(struct gspca_dev *
  static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
  static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
  static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val);
+
+#define V4L2_CID_PRIVATE_EDGE_DETECT (V4L2_CID_PRIVATE_BASE+0)
+

  static struct ctrl sd_ctrls[] = {
  /* This control is pac7302 only */
@@ -286,6 +293,21 @@ static struct ctrl sd_ctrls[] = {
.set = sd_setvflip,
.get = sd_getvflip,
},
+   {
+   {
+   .id  = V4L2_CID_PRIVATE_EDGE_DETECT,
+   .type= V4L2_CTRL_TYPE_BOOLEAN,
+   .name= Edge Detect,
+   .minimum = 0,
+   .maximum = 1,
+   .step= 1,
+#define EDGE_DETECT_DEF 0
+   .default_value = EDGE_DETECT_DEF,
+   },
+   .set = sd_setedgedetect,
+   .get = sd_getedgedetect,
+   },
+
  };

  static const struct v4l2_pix_format vga_mode[] = {
@@ -572,6 +594,7 @@ static int sd_config(struct gspca_dev *g
sd-autogain = AUTOGAIN_DEF;
sd-hflip = HFLIP_DEF;
sd-vflip = VFLIP_DEF;
+   sd-edge_detect = EDGE_DETECT_DEF;
return 0;
  }

@@ -740,6 +763,23 @@ static int sethvflip(struct gspca_dev *g
return ret;
  }

+static int setedgedetect(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   int ret;
+   __u8 data;
+
+   ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+   data = sd-edge_detect ? 0x04 : 0x00;
+   if (0= ret)
+   ret = reg_w(gspca_dev, 0x55, data);
+
+   if (0= ret)
+   ret = reg_w(gspca_dev, 0xdc, 0x01);
+
+   return ret;
+}
+
  /* this function is called at probe and resume time for pac7302 */
  static int sd_init(struct gspca_dev *gspca_dev)
  {
@@ -772,6 +812,8 @@ static int sd_start(struct gspca_dev *gs
setexposure(gspca_dev);
if (0= ret)
sethvflip(gspca_dev);
+   if (0= ret)
+   ret = setedgedetect(gspca_dev);

/* only resolution 640x480 is supported for pac7302 */

@@ -1164,6 +1206,24 @@ static int sd_getvflip(struct gspca_dev
return 0;
  }

+static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   sd-edge_detect = val;
+   if (gspca_dev-streaming)
+   setedgedetect(gspca_dev);
+   return 0;
+}
+
+static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   *val = sd-edge_detect;
+   return 0;
+}
+
  /* sub-driver description for pac7302 */
  static struct sd_desc sd_desc = {
.name = MODULE_NAME,
--
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 

Re: [PATCH] gspca pac7302: add test pattern/overlay control

2009-11-08 Thread Hans de Goede

Hi,

On 11/08/2009 12:05 AM, Németh Márton wrote:

From: Márton Némethnm...@freemail.hu

The Labtec Webcam 2200 (USB ID 093a:2626) device can produce some
diagnostic patterns instead of the sensor image. An overlay test
pattern also exsits which can be combined with the sensor image or
with any test patterns. Add controls to activate these test modes.



Same here again, this is completely useless to an end user, with something
like v4l2ucp we can show a nice control panel (like a soundcard mixer),
to the end user. We should only show sensible stuff there, showing this to
the end user is not sensible.

Jean-Francois Moine, can you please revert the changes adding these 2 controls.

Németh, I understand having things like this may be useful for development, 
what you
can do is add support for the standard v4l2 debugging interface, see:

linux/drivers/media/video/gspca/sn9c20x.c

Which allows one to export direct register control, and then use the existing
tools for this interface to modify these registers for testing purposes, or
even write a special userspace program to set things like this test mode.

(But this really does not belong to be visiable to the end user as a control
 at the same level as brightness and contrast).

Regards,

Hans




Signed-off-by: Márton Némethnm...@freemail.hu
Cc: Thomas Kaisertho...@kaiser-linux.li
---
diff -upr c/linux/drivers/media/video/gspca/pac7302.c 
d/linux/drivers/media/video/gspca/pac7302.c
--- c/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 22:38:32.0 
+0100
+++ d/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 00:55:38.0 
+0100
@@ -27,6 +27,29 @@
 addresses is a - sign that register description is not valid for the
 matching IC.

+   Register page 0:
+
+   Address Description
+   0x72/-  Different test patterns:
+ bit 0..3:  0 -  image, test pattern off
+1 -  white
+2 -  black
+3 -  red
+4 -  green
+5 -  blue
+6 -  cyan
+7 -  magenta
+8 -  yellow
+9 -  color bars
+   10 -  high resolution color pattern
+   11 -  black to white gradient from top to bottom
+   12 -  white to black gradient from left to right
+   13 -  white to black gradient repeats from left to 
right
+   14 -  dark gray (#11)
+   15 -  dark gray 2 (#11)
+ bit 4: overlay some diagnostic points over the image
+ bit 5..7: no effect
+
 Register page 1:

 AddressDescription
@@ -57,6 +80,7 @@
  0   | 0x0f..0x20 | setcolors()
  0   | 0xa2..0xab | setbrightcont()
  0   | 0x55   | setedgedetect()
+0   | 0x72   | settestpattern()
  0   | 0xc5   | setredbalance()
  0   | 0xc6   | setwhitebalance()
  0   | 0xc7   | setbluebalance()
@@ -91,6 +115,8 @@ struct sd {
__u8 hflip;
__u8 vflip;
unsigned char edge_detect;
+   unsigned char test_pattern;
+   unsigned char test_overlay;

u8 sof_read;
u8 autogain_ignore_frames;
@@ -123,9 +149,14 @@ static int sd_setexposure(struct gspca_d
  static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
  static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val);
  static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_settestpattern(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_gettestpattern(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_settestoverlay(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_gettestoverlay(struct gspca_dev *gspca_dev, __s32 *val);

  #define V4L2_CID_PRIVATE_EDGE_DETECT (V4L2_CID_PRIVATE_BASE+0)
-
+#define V4L2_CID_PRIVATE_TEST_PATTERN (V4L2_CID_PRIVATE_BASE+1)
+#define V4L2_CID_PRIVATE_TEST_OVERLAY (V4L2_CID_PRIVATE_BASE+2)

  static struct ctrl sd_ctrls[] = {
  /* This control is pac7302 only */
@@ -307,6 +338,34 @@ static struct ctrl sd_ctrls[] = {
.set = sd_setedgedetect,
.get = sd_getedgedetect,
},
+   {
+   {
+   .id  = V4L2_CID_PRIVATE_TEST_PATTERN,
+   .type= V4L2_CTRL_TYPE_MENU,
+   .name= Test Pattern,
+   .minimum = 0,
+   .maximum = 15,
+   .step= 1,
+#define TEST_PATTERN_DEF 0
+   .default_value = TEST_PATTERN_DEF,
+   },
+   .set = sd_settestpattern,
+   .get = sd_gettestpattern,
+   },
+   {
+   {
+   .id  = V4L2_CID_PRIVATE_TEST_OVERLAY,
+   .type= V4L2_CTRL_TYPE_BOOLEAN,
+   .name= Test Overlay,
+   .minimum = 0,
+

Re: pac7302: INFO: possible circular locking dependency detected

2009-11-08 Thread Németh Márton
Hi,

Hans de Goede wrote:
 [snip]
 
 About the usb control msg errors, I don't think they are related to this 
 issue at all, no real
 world app ever does a streamon and an mmap at the same time. As said if we 
 could serialize mmap and
 ioctl at a high enough level, things would be fine too.

I am using http://moinejf.free.fr/svv.c . In the start_capturing() function it 
calls the
VIDIOC_STREAMON ioctl in case of memory mapped mode. Is this wrong? Or do you 
mean under
at the same time that VIDIOC_STREAMON and mmap() is called from different 
tasks/threads?

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


[PATCH 1/2] gspca pac7302/pac7311: propagate error to higher level software

2009-11-08 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The usb_control_msg() can fail any time. Only continue writing
sequence if there was no error with the previous write. If there
was any problem stop sending URBs and propagate the error to the
gspca_main.

Only the pac7302 driver was tested with Labtec Webcam 2200
(USB ID 093a:2626) because of lack of hardware for pac7311.

Signed-off-by: Márton Németh nm...@freemail.hu
---
The patch is based on the 13327:19c0469c02c3 of http://linuxtv.org/hg/v4l-dvb/ .
This patch replaces http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/2dc5e25b76c1
and http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/43be85676a49 . In addition to
those patches this patch also updates sd_stopN() function in pac7311.
---
diff -r 19c0469c02c3 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Nov 07 15:51:01 2009 -0200
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 11:54:26 2009 +0100
@@ -331,7 +331,7 @@
0x00
 };

-static void reg_w_buf(struct gspca_dev *gspca_dev,
+static int reg_w_buf(struct gspca_dev *gspca_dev,
  __u8 index,
  const char *buffer, int len)
 {
@@ -349,6 +349,7 @@
PDEBUG(D_ERR, reg_w_buf(): 
Failed to write registers to index 0x%x, error %i,
index, ret);
+   return ret;
 }

 #if 0 /* not used */
@@ -373,7 +374,7 @@
 }
 #endif

-static void reg_w(struct gspca_dev *gspca_dev,
+static int reg_w(struct gspca_dev *gspca_dev,
  __u8 index,
  __u8 value)
 {
@@ -390,23 +391,27 @@
PDEBUG(D_ERR, reg_w(): 
Failed to write register to index 0x%x, value 0x%x, error %i,
index, value, ret);
+   return ret;
 }

-static void reg_w_seq(struct gspca_dev *gspca_dev,
+static int reg_w_seq(struct gspca_dev *gspca_dev,
const __u8 *seq, int len)
 {
+   int ret = 0;
while (--len = 0) {
-   reg_w(gspca_dev, seq[0], seq[1]);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, seq[0], seq[1]);
seq += 2;
}
+   return ret;
 }

 /* load the beginning of a page */
-static void reg_w_page(struct gspca_dev *gspca_dev,
+static int reg_w_page(struct gspca_dev *gspca_dev,
const __u8 *page, int len)
 {
int index;
-   int ret;
+   int ret = 0;

for (index = 0; index  len; index++) {
if (page[index] == SKIP)/* skip this index */
@@ -418,52 +423,61 @@
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, gspca_dev-usb_buf, 1,
500);
-   if (ret  0)
+   if (ret  0) {
PDEBUG(D_ERR, reg_w_page(): 
Failed to write register to index 0x%x, 
value 0x%x, error %i,
index, page[index], ret);
+   break;
+   }
}
+   return ret;
 }

 /* output a variable sequence */
-static void reg_w_var(struct gspca_dev *gspca_dev,
+static int reg_w_var(struct gspca_dev *gspca_dev,
const __u8 *seq,
const __u8 *page3, unsigned int page3_len,
const __u8 *page4, unsigned int page4_len)
 {
int index, len;
+   int ret = 0;

for (;;) {
index = *seq++;
len = *seq++;
switch (len) {
case END_OF_SEQUENCE:
-   return;
+   return ret;
case LOAD_PAGE4:
-   reg_w_page(gspca_dev, page4, page4_len);
+   ret = reg_w_page(gspca_dev, page4, page4_len);
break;
case LOAD_PAGE3:
-   reg_w_page(gspca_dev, page3, page3_len);
+   ret = reg_w_page(gspca_dev, page3, page3_len);
break;
default:
if (len  USB_BUF_SZ) {
PDEBUG(D_ERR|D_STREAM,
Incorrect variable sequence);
-   return;
+   return -EINVAL;
}
while (len  0) {
if (len  8) {
-   reg_w_buf(gspca_dev, index, seq, len);
+   ret = reg_w_buf(gspca_dev,
+   index, seq, len);
+   if (ret  0)
+   return ret;
seq += len;
break;
}
-   reg_w_buf(gspca_dev, index, seq, 

[PATCH 2/2] gspca pac7302: add debug register write interface

2009-11-08 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Add debug register write interface to pac7302 to be able to set
for example the edge detect mode (bit 2 register 0x55) or the
test pattern (bit 0..3, register 0x72) and test overlay (bit 4,
register 0x72) from the user space. Only write of register
page 0 is supported by this patch.

The patch was tested together with Labtec Webcam 2200 (USB ID
093a:2626).

Signed-off-by: Márton Németh nm...@freemail.hu
---
This patch replaces http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/da22d3ea5fc7 
and
http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/9b3580f8fee8 .
---
diff -upr b/linux/drivers/media/video/gspca/pac7302.c 
c/linux/drivers/media/video/gspca/pac7302.c
--- b/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 11:39:00.0 
+0100
+++ c/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 11:59:00.0 
+0100
@@ -53,6 +53,7 @@

 #define MODULE_NAME pac7302

+#include media/v4l2-chip-ident.h
 #include gspca.h

 MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li);
@@ -982,6 +983,55 @@ static int sd_getvflip(struct gspca_dev
return 0;
 }

+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int sd_dbg_s_register(struct gspca_dev *gspca_dev,
+   struct v4l2_dbg_register *reg)
+{
+   int ret = -EINVAL;
+   __u8 index;
+   __u8 value;
+
+   /* reg-reg: bit0..15: reserved for register index (wIndex is 16bit
+  long on the USB bus)
+   */
+   if (reg-match.type == V4L2_CHIP_MATCH_HOST 
+   reg-match.addr == 0 
+   (reg-reg  0x00ff) 
+   (reg-val = 0x00ff)
+   ) {
+   /* Currently writing to page 0 is only supported. */
+   /* reg_w() only supports 8bit index */
+   index = reg-reg  0x00ff;
+   value = reg-val  0x00ff;
+
+   /* Note that there shall be no access to other page
+  by any other function between the page swith and
+  the actual register write */
+   ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+   if (0 = ret)
+   ret = reg_w(gspca_dev, index, value);
+
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0xdc, 0x01);
+   }
+   return ret;
+}
+
+static int sd_chip_ident(struct gspca_dev *gspca_dev,
+   struct v4l2_dbg_chip_ident *chip)
+{
+   int ret = -EINVAL;
+
+   if (chip-match.type == V4L2_CHIP_MATCH_HOST 
+   chip-match.addr == 0) {
+   chip-revision = 0;
+   chip-ident = V4L2_IDENT_UNKNOWN;
+   ret = 0;
+   }
+   return ret;
+}
+#endif
+
 /* sub-driver description for pac7302 */
 static struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -994,6 +1044,10 @@ static struct sd_desc sd_desc = {
.stop0 = sd_stop0,
.pkt_scan = sd_pkt_scan,
.dq_callback = do_autogain,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+   .set_register = sd_dbg_s_register,
+   .get_chip_ident = sd_chip_ident,
+#endif
 };

 /* -- module initialisation -- */
--
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] v4l2-dbg: report fail reason to the user

2009-11-08 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Report the fail reason to the user when writing a register even if
the verbose mode is switched off.

Remove duplicated code ioctl() call which may cause different ioctl()
function call in case of verbose and non verbose if not handled carefully.

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 19c0469c02c3 v4l2-apps/util/v4l2-dbg.cpp
--- a/v4l2-apps/util/v4l2-dbg.cpp   Sat Nov 07 15:51:01 2009 -0200
+++ b/v4l2-apps/util/v4l2-dbg.cpp   Sun Nov 08 14:13:52 2009 +0100
@@ -354,13 +354,14 @@
 {
int retVal;

-   if (!options[OptVerbose]) return ioctl(fd, request, parm);
retVal = ioctl(fd, request, parm);
-   printf(%s: , name);
-   if (retVal  0)
-   printf(failed: %s\n, strerror(errno));
-   else
-   printf(ok\n);
+   if (options[OptVerbose]) {
+   printf(%s: , name);
+   if (retVal  0)
+   printf(failed: %s\n, strerror(errno));
+   else
+   printf(ok\n);
+   }

return retVal;
 }
@@ -586,8 +587,9 @@

printf( set to 0x%llx\n, set_reg.val);
} else {
-   printf(Failed to set register 0x%08llx value 
0x%llx\n,
-   set_reg.reg, set_reg.val);
+   printf(Failed to set register 0x%08llx value 
0x%llx: 
+   %s\n,
+   set_reg.reg, set_reg.val, 
strerror(errno));
}
set_reg.reg++;
}
--
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


libv4l problem decoding frames from pac7302

2009-11-08 Thread Németh Márton
Hi,

I have some problem that libv4l cannot decode all image coming from the
Labtec Webcam 2200. There are some cases when no image at all can be decoded.
This case can be reproduced always for example by setting the camera to test
mode to produce a color test bar. The raw data arrives from the driver (41472
bytes, see attached) and v4lconvert_convert() returns -1 and the errno is set
to EAGAIN. In this case the v4lconvert_get_error_message() reports the
following error message:

v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 
0xff

Steps to reproduce:
1. get 13327:19c0469c02c3 from http://linuxtv.org/hg/v4l-dvb/
2. apply the patch http://www.spinics.net/lists/linux-media/msg11841.html
3. apply the patch http://www.spinics.net/lists/linux-media/msg11842.html
4. compile and install the new driver
5. plug Labtec Webcam 2200
6. start capturing
7. execute v4l2-dbg --set-register=0x72 9, this will switch on the color
   test card of the webcam.

Current result: v4lconvert_convert() always return -1 and errno is EAGAIN until
the olor test card is not switched off with v4l2-dbg --set-register=0x72 0.

How would you start to fix this?

Regards,

Márton Németh

inline: image.raw

[PATCH] v4l: add more missing linux/sched.h includions

2009-11-08 Thread Guennadi Liakhovetski
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

Unless there are objections, I'll be asking Mauro to pull this and one 
more patch later today.

 drivers/media/video/mx1_camera.c   |1 +
 drivers/media/video/mx3_camera.c   |1 +
 drivers/media/video/sh_mobile_ceu_camera.c |1 +
 drivers/media/video/videobuf-dma-contig.c  |1 +
 4 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 5f37952..7280229 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -28,6 +28,7 @@
 #include linux/moduleparam.h
 #include linux/mutex.h
 #include linux/platform_device.h
+#include linux/sched.h
 #include linux/time.h
 #include linux/version.h
 #include linux/videodev2.h
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index dff2e5e..7db82bd 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -17,6 +17,7 @@
 #include linux/clk.h
 #include linux/vmalloc.h
 #include linux/interrupt.h
+#include linux/sched.h
 
 #include media/v4l2-common.h
 #include media/v4l2-dev.h
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index a2b5d39..56fc7ec 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -31,6 +31,7 @@
 #include linux/platform_device.h
 #include linux/videodev2.h
 #include linux/pm_runtime.h
+#include linux/sched.h
 
 #include media/v4l2-common.h
 #include media/v4l2-dev.h
diff --git a/drivers/media/video/videobuf-dma-contig.c 
b/drivers/media/video/videobuf-dma-contig.c
index 635ffc7..c3065c4 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -19,6 +19,7 @@
 #include linux/mm.h
 #include linux/pagemap.h
 #include linux/dma-mapping.h
+#include linux/sched.h
 #include media/videobuf-dma-contig.h
 
 struct videobuf_dma_contig_memory {
-- 
1.6.2.4

--
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] soc-camera: properly initialise the device object when reusing

2009-11-08 Thread Guennadi Liakhovetski
Commit ef373189f62413803b7b816c972fc154c488cdc0 fix use-after-free Oops,
resulting from a driver-core API change fixed the Oops, but didn't correct
missing device object initialisation. This patch makes unloading and reloading
of soc-camera host- and client-drivers possible again.

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

This is the second of the two patches, that I'm going to push upstream for 
2.6.32 inclusion.

 drivers/media/video/soc_camera.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 36e617b..95fdeb2 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1097,6 +1097,13 @@ static int default_s_crop(struct soc_camera_device *icd, 
struct v4l2_crop *a)
return v4l2_subdev_call(sd, video, s_crop, a);
 }
 
+static void soc_camera_device_init(struct device *dev, void *pdata)
+{
+   dev-platform_data  = pdata;
+   dev-bus= soc_camera_bus_type;
+   dev-release= dummy_release;
+}
+
 int soc_camera_host_register(struct soc_camera_host *ici)
 {
struct soc_camera_host *ix;
@@ -1158,6 +1165,7 @@ void soc_camera_host_unregister(struct soc_camera_host 
*ici)
 
list_for_each_entry(icd, devices, list) {
if (icd-iface == ici-nr) {
+   void *pdata = icd-dev.platform_data;
/* The bus-remove will be called */
device_unregister(icd-dev);
/*
@@ -1169,6 +1177,7 @@ void soc_camera_host_unregister(struct soc_camera_host 
*ici)
 * device private data.
 */
memset(icd-dev, 0, sizeof(icd-dev));
+   soc_camera_device_init(icd-dev, pdata);
}
}
 
@@ -1200,10 +1209,7 @@ static int soc_camera_device_register(struct 
soc_camera_device *icd)
 * man, stay reasonable... */
return -ENOMEM;
 
-   icd-devnum = num;
-   icd-dev.bus = soc_camera_bus_type;
-
-   icd-dev.release= dummy_release;
+   icd-devnum = num;
icd-use_count  = 0;
icd-host_priv  = NULL;
mutex_init(icd-video_lock);
@@ -1311,12 +1317,13 @@ static int __devinit soc_camera_pdrv_probe(struct 
platform_device *pdev)
icd-iface = icl-bus_id;
icd-pdev = pdev-dev;
platform_set_drvdata(pdev, icd);
-   icd-dev.platform_data = icl;
 
ret = soc_camera_device_register(icd);
if (ret  0)
goto escdevreg;
 
+   soc_camera_device_init(icd-dev, icl);
+
icd-user_width = DEFAULT_WIDTH;
icd-user_height= DEFAULT_HEIGHT;
 
-- 
1.6.2.4

--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sat, Nov 7, 2009 at 9:40 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Hello Vince,

 I think the next step at this point is for you to definitively find a
 use case that does not work with the latest v4l-dvb tip and Robert's
 patch, and include exactly what kernel you tested with and which board
 is having the problem (including the PCI or USB ID).

 At this point, your description seems a bit vague in terms of what is
 working and what is not.  If you do the additional testing to narrow
 down specifically the failure case you are experiencing, I will see
 what I can do.

 That said, I'm preparing a tree with Robert's patch since I am pretty
 confident at least his particular problem is now addressed.

 Thanks,

 Devin

Robert,

FYI:  this has been merged into my local tree (after fixing some
whitespace problems introduced by the inlining of the patch into the
email).  I'll issue a PULL request tonight.

Devin

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


Re: pac7302: INFO: possible circular locking dependency detected

2009-11-08 Thread Hans de Goede

Hi,

On 11/08/2009 10:56 AM, Németh Márton wrote:

Hi,

Hans de Goede wrote:

[snip]

About the usb control msg errors, I don't think they are related to this issue 
at all, no real
world app ever does a streamon and an mmap at the same time. As said if we 
could serialize mmap and
ioctl at a high enough level, things would be fine too.


I am using http://moinejf.free.fr/svv.c . In the start_capturing() function it 
calls the
VIDIOC_STREAMON ioctl in case of memory mapped mode. Is this wrong? Or do you 
mean under
at the same time that VIDIOC_STREAMON and mmap() is called from different 
tasks/threads?



Yes from 2 different threads, which are both the stream owner (so operating on 
the same FD).

Regards,

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


Re: bug in changeset 13239:54535665f94b ?

2009-11-08 Thread Johann Friedrichs

Mauro Carvalho Chehab schrieb:

Hi Hartmut,

Em Sun, 01 Nov 2009 16:59:26 +0100
e9hack e9h...@googlemail.com escreveu:


Hi,

something is wrong in changeset 13239:54535665f94b. After applying it, I get 
page faults
in various applications:
...

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



Em Mon, 2 Nov 2009 21:27:44 +0100
e9h...@googlemail.com escreveu:


the BUG is in vidioc_streamoff() for the saa7146. This function
releases all buffers first, and stops the capturing and dma tranfer of
the saa7146 as second. If the page table, which is currently used by
the saa7146, is modified by another thread, the saa7146 writes
anywhere to the physical RAM. IMHO vidioc_streamoff() must stop the
saa7146 first and may then release the buffers.


I agree. We need first to stop DMA activity, and then release the page tables.

Could you please test if the enclosed patch fixes the issue?

Cheers,
Mauro

saa7146: stop DMA before de-allocating DMA scatter/gather page buffers

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/linux/drivers/media/common/saa7146_video.c 
b/linux/drivers/media/common/saa7146_video.c
--- a/linux/drivers/media/common/saa7146_video.c
+++ b/linux/drivers/media/common/saa7146_video.c
@@ -1334,9 +1334,9 @@ static void buffer_release(struct videob
 
 	DEB_CAP((vbuf:%p\n,vb));
 
+	saa7146_dma_free(dev,q,buf);

+
release_all_pagetables(dev, buf);
-
-   saa7146_dma_free(dev,q,buf);
 }
 
 static struct videobuf_queue_ops video_qops = {



Hi Mauro,
I cannot easily catch any memory overwriting done by 
saa7146-capture-dma, but Hartmut is right that there is quite a chance.
I would prefer calling video_end() before videobuf_streamoff() in 
vidioc_streamoff(), because this physically shuts down the capture 
immediately at the hardware source. By the way, this is done in the same 
sequence in video_close, where videobuf_stop (which calls 
videobuf_streamoff) also gets called after video_end.
I have no negative impact with your patch and it might shutdown the dma 
as well, but as said before, I don't see any immediate errors even with 
the released version.

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


[PATCH 0/4] DVB: firedtv: port to new firewire driver stack

2009-11-08 Thread Stefan Richter
The following patch series adapts the firedtv driver for
FireWire-attached DVB boxes and cards to the newer firewire-core kernel
API.  The driver will continue to work with the older ieee1394 kernel
API as well.  Which of the two IEEE 1394 stacks will be used depends on
which one was configured at build time.  If both were built, firedtv
transparently uses the stack which is bound to the FireWire controller.

This patch series depends on changes to firewire-core which were merged
into Linux 2.6.31.

There is some non-essential functionality yet to implement:
  - Finish FCP support in firewire-core so that more than one AV/C
device can be used on the same FireWire bus at the same time.
  - Enhance firedtv to use firewire-core's channel and bandwidth
allocation function for proper cooperation with non-FireDTV AV/C
devices on the same bus.

Following as reply:
[PATCH 1/4] firedtv: move remote control workqueue handling into rc source file
[PATCH 2/4] firedtv: reform lock transaction backend call
[PATCH 3/4] firedtv: add missing include, rename a constant
[PATCH 4/4] firedtv: port to new firewire core

 drivers/media/dvb/firewire/Kconfig|7
 drivers/media/dvb/firewire/Makefile   |1
 drivers/media/dvb/firewire/firedtv-1394.c |   37 +-
 drivers/media/dvb/firewire/firedtv-avc.c  |   50 +-
 drivers/media/dvb/firewire/firedtv-dvb.c  |   15
 drivers/media/dvb/firewire/firedtv-fw.c   |  385 ++
 drivers/media/dvb/firewire/firedtv-rc.c   |2
 drivers/media/dvb/firewire/firedtv.h  |   17
 8 files changed, 471 insertions(+), 43 deletions(-)
-- 
Stefan Richter
-=-==--= =-== -=---
http://arcgraph.de/sr/

--
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/4] firedtv: move remote control workqueue handling into rc source file

2009-11-08 Thread Stefan Richter
Preparation for the port of firedtv to the firewire-core kernel API:
Canceling of the remote control workqueue job is factored into
firedtv-rc.c.  Plus trivial whitespace change.

Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---
 drivers/media/dvb/firewire/firedtv-1394.c |5 +++--
 drivers/media/dvb/firewire/firedtv-rc.c   |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -212,6 +212,7 @@ static int node_probe(struct device *dev
goto fail;
 
avc_register_remote_control(fdtv);
+
return 0;
 fail:
spin_lock_irq(node_list_lock);
@@ -220,6 +221,7 @@ fail:
fdtv_unregister_rc(fdtv);
 fail_free:
kfree(fdtv);
+
return err;
 }
 
@@ -233,10 +235,9 @@ static int node_remove(struct device *de
list_del(fdtv-list);
spin_unlock_irq(node_list_lock);
 
-   cancel_work_sync(fdtv-remote_ctrl_work);
fdtv_unregister_rc(fdtv);
-
kfree(fdtv);
+
return 0;
 }
 
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-rc.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-rc.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-rc.c
@@ -14,6 +14,7 @@
 #include linux/kernel.h
 #include linux/string.h
 #include linux/types.h
+#include linux/workqueue.h
 
 #include firedtv.h
 
@@ -163,6 +164,7 @@ fail:
 
 void fdtv_unregister_rc(struct firedtv *fdtv)
 {
+   cancel_work_sync(fdtv-remote_ctrl_work);
kfree(fdtv-remote_ctrl_dev-keycode);
input_unregister_device(fdtv-remote_ctrl_dev);
 }

-- 
Stefan Richter
-=-==--= =-== -=---
http://arcgraph.de/sr/

--
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] gspca pac7311: stop sending URBs on first error

2009-11-08 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

It is no use to continue sending URBs if one of them already
failed.

Signed-off-by: Márton Németh nm...@freemail.hu
---
The patch is based on 13335:3fd924da7091 from 
http://linuxtv.org/hg/~jfrancois/gspca/ .
---
diff -r 3fd924da7091 linux/drivers/media/video/gspca/pac7311.c
--- a/linux/drivers/media/video/gspca/pac7311.c Sun Nov 08 08:41:28 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7311.c Sun Nov 08 23:14:13 2009 +0100
@@ -590,16 +590,27 @@

 static void sd_stopN(struct gspca_dev *gspca_dev)
 {
-   reg_w(gspca_dev, 0xff, 0x04);
-   reg_w(gspca_dev, 0x27, 0x80);
-   reg_w(gspca_dev, 0x28, 0xca);
-   reg_w(gspca_dev, 0x29, 0x53);
-   reg_w(gspca_dev, 0x2a, 0x0e);
-   reg_w(gspca_dev, 0xff, 0x01);
-   reg_w(gspca_dev, 0x3e, 0x20);
-   reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
-   reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
-   reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
+   int ret;
+
+   ret = reg_w(gspca_dev, 0xff, 0x04);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x27, 0x80);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x28, 0xca);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x29, 0x53);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x2a, 0x0e);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0xff, 0x01);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x3e, 0x20);
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, 
Bit_6=LED */
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, 
Bit_6=LED */
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, 
Bit_6=LED */
 }

 /* called on streamoff with alt 0 and on disconnect for 7311 */
--
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 2/4] firedtv: reform lock transaction backend call

2009-11-08 Thread Stefan Richter
Preparation for the port of firedtv to the firewire-core kernel API:
The fdtv-backend-lock() hook and thus the CMP code is slightly changed
to better fit with the new API.

Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---
 drivers/media/dvb/firewire/firedtv-1394.c |   11 -
 drivers/media/dvb/firewire/firedtv-avc.c  |   50 --
 drivers/media/dvb/firewire/firedtv.h  |2 
 3 files changed, 37 insertions(+), 26 deletions(-)

Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -87,10 +87,15 @@ static inline struct node_entry *node_of
return container_of(fdtv-device, struct unit_directory, device)-ne;
 }
 
-static int node_lock(struct firedtv *fdtv, u64 addr, void *data, __be32 arg)
+static int node_lock(struct firedtv *fdtv, u64 addr, __be32 data[])
 {
-   return hpsb_node_lock(node_of(fdtv), addr, EXTCODE_COMPARE_SWAP, data,
- (__force quadlet_t)arg);
+   int ret;
+
+   ret = hpsb_node_lock(node_of(fdtv), addr, EXTCODE_COMPARE_SWAP,
+   (__force quadlet_t *)data[1], (__force quadlet_t)data[0]);
+   data[0] = data[1];
+
+   return ret;
 }
 
 static int node_read(struct firedtv *fdtv, u64 addr, void *data, size_t len)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-avc.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-avc.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-avc.c
@@ -1255,14 +1255,14 @@ static int cmp_read(struct firedtv *fdtv
return ret;
 }
 
-static int cmp_lock(struct firedtv *fdtv, void *data, u64 addr, __be32 arg)
+static int cmp_lock(struct firedtv *fdtv, u64 addr, __be32 data[])
 {
int ret;
 
if (mutex_lock_interruptible(fdtv-avc_mutex))
return -EINTR;
 
-   ret = fdtv-backend-lock(fdtv, addr, data, arg);
+   ret = fdtv-backend-lock(fdtv, addr, data);
if (ret  0)
dev_err(fdtv-device, CMP: lock I/O error\n);
 
@@ -1292,25 +1292,25 @@ static inline void set_opcr(__be32 *opcr
 
 int cmp_establish_pp_connection(struct firedtv *fdtv, int plug, int channel)
 {
-   __be32 old_opcr, opcr;
+   __be32 old_opcr, opcr[2];
u64 opcr_address = CMP_OUTPUT_PLUG_CONTROL_REG_0 + (plug  2);
int attempts = 0;
int ret;
 
-   ret = cmp_read(fdtv, opcr, opcr_address, 4);
+   ret = cmp_read(fdtv, opcr, opcr_address, 4);
if (ret  0)
return ret;
 
 repeat:
-   if (!get_opcr_online(opcr)) {
+   if (!get_opcr_online(*opcr)) {
dev_err(fdtv-device, CMP: output offline\n);
return -EBUSY;
}
 
-   old_opcr = opcr;
+   old_opcr = *opcr;
 
-   if (get_opcr_p2p_connections(opcr)) {
-   if (get_opcr_channel(opcr) != channel) {
+   if (get_opcr_p2p_connections(*opcr)) {
+   if (get_opcr_channel(*opcr) != channel) {
dev_err(fdtv-device, CMP: cannot change channel\n);
return -EBUSY;
}
@@ -1318,11 +1318,11 @@ repeat:
 
/* We don't allocate isochronous resources. */
} else {
-   set_opcr_channel(opcr, channel);
-   set_opcr_data_rate(opcr, 2); /* S400 */
+   set_opcr_channel(opcr, channel);
+   set_opcr_data_rate(opcr, 2); /* S400 */
 
/* FIXME: this is for the worst case - optimize */
-   set_opcr_overhead_id(opcr, 0);
+   set_opcr_overhead_id(opcr, 0);
 
/*
 * FIXME: allocate isochronous channel and bandwidth at IRM
@@ -1330,13 +1330,16 @@ repeat:
 */
}
 
-   set_opcr_p2p_connections(opcr, get_opcr_p2p_connections(opcr) + 1);
+   set_opcr_p2p_connections(opcr, get_opcr_p2p_connections(*opcr) + 1);
 
-   ret = cmp_lock(fdtv, opcr, opcr_address, old_opcr);
+   opcr[1] = *opcr;
+   opcr[0] = old_opcr;
+
+   ret = cmp_lock(fdtv, opcr_address, opcr);
if (ret  0)
return ret;
 
-   if (old_opcr != opcr) {
+   if (old_opcr != *opcr) {
/*
 * FIXME: if old_opcr.P2P_Connections  0,
 * deallocate isochronous channel and bandwidth at IRM
@@ -1354,27 +1357,30 @@ repeat:
 
 void cmp_break_pp_connection(struct firedtv *fdtv, int plug, int channel)
 {
-   __be32 old_opcr, opcr;
+   __be32 old_opcr, opcr[2];
u64 opcr_address = CMP_OUTPUT_PLUG_CONTROL_REG_0 + (plug  2);
int attempts = 0;
 
-   if (cmp_read(fdtv, opcr, opcr_address, 4)  0)
+   if (cmp_read(fdtv, opcr, opcr_address, 4)  0)
return;
 
 repeat:
-   if (!get_opcr_online(opcr) || 

Re: [PATCH 2/2] gspca pac7302: add debug register write interface

2009-11-08 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Add debug register write interface to pac7302 to be able to set
for example the edge detect mode (bit 2 register 0x55) or the
test pattern (bit 0..3, register 0x72) and test overlay (bit 4,
register 0x72) from the user space. Only write of register
page 0 is supported by this patch.

The patch was tested together with Labtec Webcam 2200 (USB ID
093a:2626).

Signed-off-by: Márton Németh nm...@freemail.hu
---
The patch is based on 13335:3fd924da7091 from 
http://linuxtv.org/hg/~jfrancois/gspca/ .
---
diff -r 3fd924da7091 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 08:41:28 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 23:21:51 2009 +0100
@@ -68,6 +68,7 @@

 #define MODULE_NAME pac7302

+#include media/v4l2-chip-ident.h
 #include gspca.h

 MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li);
@@ -1164,6 +1165,55 @@
return 0;
 }

+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int sd_dbg_s_register(struct gspca_dev *gspca_dev,
+   struct v4l2_dbg_register *reg)
+{
+   int ret = -EINVAL;
+   __u8 index;
+   __u8 value;
+
+   /* reg-reg: bit0..15: reserved for register index (wIndex is 16bit
+  long on the USB bus)
+   */
+   if (reg-match.type == V4L2_CHIP_MATCH_HOST 
+   reg-match.addr == 0 
+   (reg-reg  0x00ff) 
+   (reg-val = 0x00ff)
+   ) {
+   /* Currently writing to page 0 is only supported. */
+   /* reg_w() only supports 8bit index */
+   index = reg-reg  0x00ff;
+   value = reg-val  0x00ff;
+
+   /* Note that there shall be no access to other page
+  by any other function between the page swith and
+  the actual register write */
+   ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+   if (0 = ret)
+   ret = reg_w(gspca_dev, index, value);
+
+   if (0 = ret)
+   ret = reg_w(gspca_dev, 0xdc, 0x01);
+   }
+   return ret;
+}
+
+static int sd_chip_ident(struct gspca_dev *gspca_dev,
+   struct v4l2_dbg_chip_ident *chip)
+{
+   int ret = -EINVAL;
+
+   if (chip-match.type == V4L2_CHIP_MATCH_HOST 
+   chip-match.addr == 0) {
+   chip-revision = 0;
+   chip-ident = V4L2_IDENT_UNKNOWN;
+   ret = 0;
+   }
+   return ret;
+}
+#endif
+
 /* sub-driver description for pac7302 */
 static struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1176,6 +1226,10 @@
.stop0 = sd_stop0,
.pkt_scan = sd_pkt_scan,
.dq_callback = do_autogain,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+   .set_register = sd_dbg_s_register,
+   .get_chip_ident = sd_chip_ident,
+#endif
 };

 /* -- module initialisation -- */

--
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/4] firedtv: add missing include, rename a constant

2009-11-08 Thread Stefan Richter
Add #include dvb_demux.h for dvb_dmx_swfilter_packets().  This was
already indirectly included via firedtv.h, but don't rely on it.

The 4 bytes which were referred to as FIREWIRE_HEADER_SIZE are actually
the source packet header from IEC 61883-4 (MPEG2-TS data transmission
over 1394), not e.g. the IEEE 1394 isochronous packet header.  So choose
a more precise name.

Also, express the payload size as a preprocessor constant too.

Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---
 drivers/media/dvb/firewire/firedtv-1394.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -26,13 +26,16 @@
 #include iso.h
 #include nodemgr.h
 
+#include dvb_demux.h
+
 #include firedtv.h
 
 static LIST_HEAD(node_list);
 static DEFINE_SPINLOCK(node_list_lock);
 
-#define FIREWIRE_HEADER_SIZE   4
-#define CIP_HEADER_SIZE8
+#define CIP_HEADER_SIZE8
+#define MPEG2_TS_HEADER_SIZE   4
+#define MPEG2_TS_SOURCE_PACKET_SIZE(4 + 188)
 
 static void rawiso_activity_cb(struct hpsb_iso *iso)
 {
@@ -62,20 +65,20 @@ static void rawiso_activity_cb(struct hp
buf = dma_region_i(iso-data_buf, unsigned char,
iso-infos[packet].offset + CIP_HEADER_SIZE);
count = (iso-infos[packet].len - CIP_HEADER_SIZE) /
-   (188 + FIREWIRE_HEADER_SIZE);
+   MPEG2_TS_SOURCE_PACKET_SIZE;
 
/* ignore empty packet */
if (iso-infos[packet].len = CIP_HEADER_SIZE)
continue;
 
while (count--) {
-   if (buf[FIREWIRE_HEADER_SIZE] == 0x47)
+   if (buf[MPEG2_TS_HEADER_SIZE] == 0x47)
dvb_dmx_swfilter_packets(fdtv-demux,
-   buf[FIREWIRE_HEADER_SIZE], 1);
+   buf[MPEG2_TS_HEADER_SIZE], 1);
else
dev_err(fdtv-device,
skipping invalid packet\n);
-   buf += 188 + FIREWIRE_HEADER_SIZE;
+   buf += MPEG2_TS_SOURCE_PACKET_SIZE;
}
}
 out:

-- 
Stefan Richter
-=-==--= =-== -=---
http://arcgraph.de/sr/

--
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 4/4] firedtv: port to new firewire core

2009-11-08 Thread Stefan Richter
The firedtv DVB driver will now work not only on top of the old ieee1394
driver stack but also on the new firewire driver stack.

Alongside to the firedtv-1394.c backend for driver binding and I/O, the
firedtv-fw.c backend is added.  Depending on which of the two 1394
stacks is configured, one or the other or both backends will be built
into the firedtv driver.

This has been tested with a DVB-T and a DVB-C box on x86-64 and x86-32
together with a few different controllers (Agere FW323, a NEC chip, TI
TSB82AA2, TSB43AB22/A, VIA VT6306).

Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---
 drivers/media/dvb/firewire/Kconfig|7 +
 drivers/media/dvb/firewire/Makefile   |1 +
 drivers/media/dvb/firewire/firedtv-1394.c |6 
 drivers/media/dvb/firewire/firedtv-dvb.c  |   15 +
 drivers/media/dvb/firewire/firedtv-fw.c   |  385 ++
 drivers/media/dvb/firewire/firedtv.h  |   15 +
 6 files changed, 420 insertions(+), 9 deletions(-)

Index: linux-2.6.31.4/drivers/media/dvb/firewire/Kconfig
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/Kconfig
+++ linux-2.6.31.4/drivers/media/dvb/firewire/Kconfig
@@ -1,6 +1,6 @@
 config DVB_FIREDTV
tristate FireDTV and FloppyDTV
-   depends on DVB_CORE  IEEE1394
+   depends on DVB_CORE  (FIREWIRE || IEEE1394)
help
  Support for DVB receivers from Digital Everywhere
  which are connected via IEEE 1394 (FireWire).
@@ -13,8 +13,11 @@ config DVB_FIREDTV
 
 if DVB_FIREDTV
 
+config DVB_FIREDTV_FIREWIRE
+   def_bool FIREWIRE = y || (FIREWIRE = m  DVB_FIREDTV = m)
+
 config DVB_FIREDTV_IEEE1394
-   def_bool IEEE1394
+   def_bool IEEE1394 = y || (IEEE1394 = m  DVB_FIREDTV = m)
 
 config DVB_FIREDTV_INPUT
def_bool INPUT = y || (INPUT = m  DVB_FIREDTV = m)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/Makefile
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/Makefile
+++ linux-2.6.31.4/drivers/media/dvb/firewire/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_DVB_FIREDTV) += firedtv.o
 
 firedtv-y := firedtv-avc.o firedtv-ci.o firedtv-dvb.o firedtv-fe.o
+firedtv-$(CONFIG_DVB_FIREDTV_FIREWIRE) += firedtv-fw.o
 firedtv-$(CONFIG_DVB_FIREDTV_IEEE1394) += firedtv-1394.o
 firedtv-$(CONFIG_DVB_FIREDTV_INPUT)+= firedtv-rc.o
 
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -1,5 +1,5 @@
 /*
- * FireDTV driver (formerly known as FireSAT)
+ * FireDTV driver -- ieee1394 I/O backend
  *
  * Copyright (C) 2004 Andreas Monitzer a...@monitzer.com
  * Copyright (C) 2007-2008 Ben Backx b...@bbackx.com
@@ -261,6 +261,7 @@ static int node_update(struct unit_direc
 
 static struct hpsb_protocol_driver fdtv_driver = {
.name   = firedtv,
+   .id_table   = fdtv_id_table,
.update = node_update,
.driver = {
.probe  = node_probe,
@@ -273,12 +274,11 @@ static struct hpsb_highlevel fdtv_highle
.fcp_request= fcp_request,
 };
 
-int __init fdtv_1394_init(struct ieee1394_device_id id_table[])
+int __init fdtv_1394_init(void)
 {
int ret;
 
hpsb_register_highlevel(fdtv_highlevel);
-   fdtv_driver.id_table = id_table;
ret = hpsb_register_protocol(fdtv_driver);
if (ret) {
printk(KERN_ERR firedtv: failed to register protocol\n);
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-dvb.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-dvb.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -297,7 +297,7 @@ struct firedtv *fdtv_alloc(struct device
 #define AVC_UNIT_SPEC_ID_ENTRY 0x00a02d
 #define AVC_SW_VERSION_ENTRY   0x010001
 
-static struct ieee1394_device_id fdtv_id_table[] = {
+const struct ieee1394_device_id fdtv_id_table[] = {
{
/* FloppyDTV S/CI and FloppyDTV S2 */
.match_flags= MATCH_FLAGS,
@@ -346,12 +346,23 @@ MODULE_DEVICE_TABLE(ieee1394, fdtv_id_ta
 
 static int __init fdtv_init(void)
 {
-   return fdtv_1394_init(fdtv_id_table);
+   int ret;
+
+   ret = fdtv_fw_init();
+   if (ret  0)
+   return ret;
+
+   ret = fdtv_1394_init();
+   if (ret  0)
+   fdtv_fw_exit();
+
+   return ret;
 }
 
 static void __exit fdtv_exit(void)
 {
fdtv_1394_exit();
+   fdtv_fw_exit();
 }
 
 module_init(fdtv_init);
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-fw.c
===
--- /dev/null
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-fw.c
@@ -0,0 +1,385 @@
+/*
+ * FireDTV 

Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Vincent McIntyre
On 11/8/09, Devin Heitmueller dheitmuel...@kernellabs.com wrote:

 I think the next step at this point is for you to definitively find a
 use case that does not work with the latest v4l-dvb tip and Robert's
 patch, and include exactly what kernel you tested with and which board
 is having the problem (including the PCI or USB ID).

 At this point, your description seems a bit vague in terms of what is
 working and what is not.  If you do the additional testing to narrow
 down specifically the failure case you are experiencing, I will see
 what I can do.

I'm trying to be as clear as I can.

We can forget about setups 1 and 2, they no longer have the messages
from the cxusb module that I originally reported, I can tune and run
signal level tests like [1].

I'm now looking at setup 3.
 os: ubuntu karmic i386
 kernel: 2.6.31-14-generic
 v4l modules: hg identify returns 19c0469c02c3+ tip

 If I cold boot, I see no tuning issues at the kernel level. Details
of the test below.

 The failure I was attempting to report is that
 I am unable to tune with dvbscan or w_scan.
 I think it is due to changes in the V4L API with respect to the versions
 of these programs I have installed.

 However I am able to tune with 'tzap'. I'm not entirely sure why tzap works,
 but it does and it shows the v4l tip drivers are ok regarding the
issue originally
 reported.

 There are two further areas I am looking into.
 1. If I *warm* boot the same setup, I see dvb-usb: bulk message failed:
 in dmesg.
 I am working on this still to try to get a clear report for you of when
 and on which device it occurs. It will probably take me a week to get
 back to you.
 2. There may be differences in performance, in that:
 2.6.31-14-generic+v4l+Rob shows worse Bit Error Rates than
 2.6.31-14-generic+Rob
 Again I have some work to do to clarify this.
 It seems likely it is a separate issue from this thread.

 That said, I'm preparing a tree with Robert's patch since I am pretty
 confident at least his particular problem is now addressed.

I can see no obstacle to you going ahead with that. Thanks again.

Cheers
Vince

Test details:
 I tune like this:
   sudo strace -t -ff -F -o tzap.strace /usr/bin/tzap -a 0 -r -c
channels.conf 7 Digital(Seven Network)

 In dmesg I see the firmware being loaded but no other messages:
   [ 1232.684884] usb 3-1: firmware: requesting xc3028-v27.fw
   [ 1232.743698] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
   [ 1232.756391] xc2028 1-0061: Loading firmware for type=BASE F8MHZ
(3), id .
   [ 1237.332511] xc2028 1-0061: Loading firmware for type=D2633 DTV7
(90), id .
   [ 1237.416510] xc2028 1-0061: Loading SCODE for type=SCODE
HAS_IF_5260 (6000), id .

 I can successfully tune each of the 4 tuners in this way. Each time I
run tzap on
 a tuner I've not used before, dmesg shows the firmware loading ok.


[1] http://linuxtv.org/wiki/index.php/Testing_reception_quality
--
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 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

2009-11-08 Thread hermann pitton
Hi,

Am Sonntag, den 08.11.2009, 01:20 -0200 schrieb Mauro Carvalho Chehab:
 Hi Ben,
 
   It's not clear to me what this MODULE_FIRMWARE is going to be used
   for, but if it's for some sort of module dependency system, then it
   definitely should *not* be a dependency for em28xx.  There are lots of
   em28xx based devices that do not use the xc3028, and those users
   should not be expected to go out and find/extract the firmware for
   some tuner they don't have.
  
  This information is currently used by initramfs builders to find
  required firmware files.  I also use this information in the Debian
  kernel upgrade script to warn if a currently loaded driver may require
  firmware in the new kernel version and the firmware is not installed.
  This is important during the transition of various drivers from built-in
  to separate firmware.
  
  Neither of these uses applies to TV tuners, but the information may
  still be useful in installers.
 
   Also, how does this approach handle the situation where there are two
   different possible firmwares depending on the card using the firmware.
As in the example above, you the xc3028 can require either the xc3028
   or xc3028L firmware depending on the board they have.  Does this
   change now result in both firmware images being required?
  
  It really depends on how the information is used.  Given that there are
  many drivers that load different firmware files for different devices
  (or even support multiple different versions with different names), it
  would be rather stupid to treat these declaration as requirements.
 
 I agree. An interesting case happens with devices that uses tda10046 DVB 
 demods.
 They have the firmware stored internally on their eeprom. Those firmwares can 
 be
 replaced by a different version loaded in ram, but, in general, they work
 properly with the eeprom one. So, even having the firmware load code there,
 the firmware at /lib/firmware is optional.

Mauro, that could lead to some misunderstanding of the current use
conditions, at least on saa7134.

Minor annotations, the tda10046 does not store firmware internally, but
there are cards which have an extra eeprom to store such firmware.

If such a firmware eeprom is found and correctly configured, the driver
in all cases will load the firmware from that eeprom and all other
firmware in /lib/firmware is ignored.

If not, the firmware will be loaded from /lib/firmware.

For all what I know, firmware revisions 26 and 29 are both valid
enough, correspondents to what we can load either from TechnoTrend or
LifeView with the getfirmware script, and might be either stored in an
extra eeprom or loaded from host/file.

Prior revisions had issues with missing freqs, in what combination ever.

We also can't totally exclude, given the whole mass of such, that in
some cases firmware eeproms might exist on some boards, but are not
correctly configured and load from host only because of that.

The tendency seen overall is that competitors save the few cents for an
extra firmware eeprom these days ...

Cheers,
Hermann

 -
 
 I don't see any reason why we should add MODULE_FIRMWARE for v4l/dvb devices.
 As you said, its primary usage is focused on booting a machine, and none
 of those devices would affect booting. 
 
 As you pointed, the secondary usage doesn't seem to apply to those devices as
 well, and seems to be distro-specific, since different distros use different
 methods to check for firmware dependencies, generally relying at the package
 metadata. To make things worse, several of those firmwares still don't have 
 any
 redistribution rights license that would be required for its inclusion on a 
 distro
 package.
 
 Also, as this macro have no current usage that would make sense for those
 drivers, I'm afraid that, as time goes by, people will simply forget to
 keep it updated, since they'll need to add the same firmware name on two
 different places.
 
 That's said, for now, the better is to not add those macros for the devices
 under /drivers/media. They'll just waste some space at the object file, and
 require an additional maintenance care for no good reason.
 
 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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 6:46 PM, Barry Williams bazzaw...@gmail.com wrote:
 Where would I find your local tree as I can't seem to get the patch to
 apply and I would like to take advantage of this patch asap.
 Thanks
 Barry

I pushed out my tree with the fix:

http://kernellabs.com/hg/~dheitmueller/misc-fixes-4

I haven't issued a PULL yet to put it into the mainline since I have a
couple of other things pending.

Devin

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


Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

2009-11-08 Thread Mauro Carvalho Chehab
Em Mon, 09 Nov 2009 00:32:29 +0100
hermann pitton hermann-pit...@arcor.de escreveu:

  I agree. An interesting case happens with devices that uses tda10046 DVB 
  demods.
  They have the firmware stored internally on their eeprom. Those firmwares 
  can be
  replaced by a different version loaded in ram, but, in general, they work
  properly with the eeprom one. So, even having the firmware load code there,
  the firmware at /lib/firmware is optional.
 
 Mauro, that could lead to some misunderstanding of the current use
 conditions, at least on saa7134.
 
 Minor annotations, the tda10046 does not store firmware internally, but
 there are cards which have an extra eeprom to store such firmware.
 
 If such a firmware eeprom is found and correctly configured, the driver
 in all cases will load the firmware from that eeprom and all other
 firmware in /lib/firmware is ignored.
 
 If not, the firmware will be loaded from /lib/firmware.
 
 For all what I know, firmware revisions 26 and 29 are both valid
 enough, correspondents to what we can load either from TechnoTrend or
 LifeView with the getfirmware script, and might be either stored in an
 extra eeprom or loaded from host/file.
 
 Prior revisions had issues with missing freqs, in what combination ever.
 
 We also can't totally exclude, given the whole mass of such, that in
 some cases firmware eeproms might exist on some boards, but are not
 correctly configured and load from host only because of that.
 
 The tendency seen overall is that competitors save the few cents for an
 extra firmware eeprom these days ...

Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
revision 29 stored at the eeprom).

The point is that it is not mandatory for such devices to have a firmware
at the filesystem for the device to work. So, a static indication that
devices with tda10046 need firmware is wrong, since some devices don't need
it.

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


[PATCH] v4l/scripts: Fix make checkpatch operation with in tree checkpatch.pl

2009-11-08 Thread Andy Walls
Mauro,

make checkpatch wasn't working for me.

I found that the new version of checkpatch.pl that's in the v4l/dvb tree
doesn't emit a version number unless explicitly requested.

This patch gets 'make checkpatch' working (and complaining again) for
me.

Regards,
Andy

Signed-off-by: Andy Walls awa...@radix.net



diff -r d2aaff136907 v4l/scripts/check.pl
--- a/v4l/scripts/check.pl  Thu Nov 05 19:51:24 2009 -0500
+++ b/v4l/scripts/check.pl  Sun Nov 08 20:40:06 2009 -0500
@@ -56,11 +56,13 @@
 }
 close IN;
 
-my $intree_checkpatch = scripts/checkpatch.pl --no-tree --strict;
+my $intree_checkpatch = scripts/checkpatch.pl --version ;
 if (!open IN,$intree_checkpatch|) {
$intree_checkpatch = v4l/.$intree_checkpatch;
open IN,$intree_checkpatch|;
 }
+$intree_checkpatch =~ s/--version/--no-tree --strict/;
+
 while (IN) {
tr/A-Z/a-z/;
if (m/version\s*:\s*([\d\.]+)/) {


--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Barry Williams
Devin Heitmueller wrote:
 On Sun, Nov 8, 2009 at 6:46 PM, Barry Williams bazzaw...@gmail.com wrote:
 Where would I find your local tree as I can't seem to get the patch to
 apply and I would like to take advantage of this patch asap.
 Thanks
 Barry

 I pushed out my tree with the fix:

 http://kernellabs.com/hg/~dheitmueller/misc-fixes-4

 I haven't issued a PULL yet to put it into the mainline since I have a
 couple of other things pending.

 Devin


Hi Devin
I tried your tree and I seem to get the same problem on one box I get
the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
Scan shows: 'ATAL: failed to open '/dev/dvb/adapter0/frontend0': 2 No
such file or directory on adapter0' and fails to tune adapter1 with :
scanning /usr/share/dvb/dvb-t/au-Adelaide
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
initial transponder 22650 1 3 9 3 1 1 0
initial transponder 17750 1 3 9 3 1 1 0
initial transponder 191625000 1 3 9 3 1 1 0
initial transponder 21950 1 3 9 3 1 1 0
initial transponder 56450 1 2 9 3 1 2 0
 tune to: 
 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
  (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
  (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
  (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 21950:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 21950:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
  (tuning failed)
WARNING:  tuning failed!!!
 tune to: 
 56450:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
WARNING:  tuning failed!!!
 tune to: 
 56450:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
  (tuning failed)
WARNING:  tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.

On my second box with the same card I get a flood of :
[12341.364016] dvb-usb: bulk message failed: -2 (4/0)
[12341.364019] cxusb: i2c read failed
but similar results with scan.
Barry
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
snip

Can you please confirm the USB ID of the board you are having the
problem with (by running lsusb from a terminal window)?

Thanks,

Devin

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Barry Williams
On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


On the first box I have
Bus 003 Device 003: ID 0fe9:db98 DVICO
Bus 003 Device 002: ID 0fe9:db98 DVICO

on the second
Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
(ZL10353+xc2028/xc3028) (initialized)
--
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 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners

2009-11-08 Thread hermann pitton

Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab:
 Em Mon, 09 Nov 2009 00:32:29 +0100
 hermann pitton hermann-pit...@arcor.de escreveu:
 
   I agree. An interesting case happens with devices that uses tda10046 DVB 
   demods.
   They have the firmware stored internally on their eeprom. Those firmwares 
   can be
   replaced by a different version loaded in ram, but, in general, they work
   properly with the eeprom one. So, even having the firmware load code 
   there,
   the firmware at /lib/firmware is optional.
  
  Mauro, that could lead to some misunderstanding of the current use
  conditions, at least on saa7134.
  
  Minor annotations, the tda10046 does not store firmware internally, but
  there are cards which have an extra eeprom to store such firmware.
  
  If such a firmware eeprom is found and correctly configured, the driver
  in all cases will load the firmware from that eeprom and all other
  firmware in /lib/firmware is ignored.
  
  If not, the firmware will be loaded from /lib/firmware.
  
  For all what I know, firmware revisions 26 and 29 are both valid
  enough, correspondents to what we can load either from TechnoTrend or
  LifeView with the getfirmware script, and might be either stored in an
  extra eeprom or loaded from host/file.
  
  Prior revisions had issues with missing freqs, in what combination ever.
  
  We also can't totally exclude, given the whole mass of such, that in
  some cases firmware eeproms might exist on some boards, but are not
  correctly configured and load from host only because of that.
  
  The tendency seen overall is that competitors save the few cents for an
  extra firmware eeprom these days ...
 
 Yes, I know. I have myself a Cardbus device with such eeprom (I think it has
 revision 29 stored at the eeprom).
 
 The point is that it is not mandatory for such devices to have a firmware
 at the filesystem for the device to work. So, a static indication that
 devices with tda10046 need firmware is wrong, since some devices don't need
 it.

There are of course lots of devices needing the firmware mandatory at
the file system. I try to tell that it is not a mistake, in case the
device has no firmware on an extra eeprom, to store latest revision
in /lib/firmware. Or tell me better ...

But also, OEMs a little bit more motivated on new hardware will not
count the costs of an extra firmware eeprom, if being first in having
substantial amounts of chips and get a good deal for such. But that was
the past.

 Cheers,
 Mauro

Else I do totally agree.

I do just point to some ambiguous conditions we should stay aware of.

It is very unlikely that we can talk them away.

Do we have all firmware loaded from eeproms possibly existing on cards
is only one minor question.

Maybe we miss some.

Should we not even better avoid such, since still no official update for
firmware eeprom flashing?

To restore the bridge eeprom we seem to be not such bad now, but also
the reasons for a possible corruption are far from clearly identified in
case we should be involved in it.

Despite of legal issues, we should have the latest revision of the
tda10046 firmware at the host. As said, those having it at an extra
eeprom will load it anyway from there.

Cheers,
Hermann
 

--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Vincent McIntyre
Hi Barry,

did you try cold-booting either system?

how are you tuning? mythtv?

Cheers
Vince


On 11/9/09, Barry Williams bazzaw...@gmail.com wrote:
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 9:01 PM, Barry Williams bazzaw...@gmail.com wrote:
 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)

And on which of the two systems are you still having the tuning
problem with?  Also, did you reboot after you installed the patch?

Devin

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Robert Lowery
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 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

Barry,

I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78
card.  0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses
completely different hardware and it's behavior is unchanged by my patch
which only targets the rev1 card.

I suspect the problems you are still reporting are from the different
cards, completely unrelated to my fix.

Would you be able to retest after removing the rev2 cards from the machine?

-Rob


--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 9:54 PM, Robert Lowery rglow...@exemail.com.au wrote:
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 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

 Barry,

 I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78
 card.  0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses
 completely different hardware and it's behavior is unchanged by my patch
 which only targets the rev1 card.

 I suspect the problems you are still reporting are from the different
 cards, completely unrelated to my fix.

 Would you be able to retest after removing the rev2 cards from the machine?

 -Rob

Robert,

It's worth noting that the introduction of the i2c gate stuff in the
zl10353 broke essentially *all* cards that use that demod except for
the one that prompted the change.  I've been incrementally going
through the cards and fixing it as people report it.

Since both of his cards use the zl10353, it wouldn't surprise me that
his other board is broken for the same reason (which would require an
additional patch).

Devin

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Barry Williams
On Mon, Nov 9, 2009 at 1:04 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 9:01 PM, Barry Williams bazzaw...@gmail.com wrote:
 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)

 And on which of the two systems are you still having the tuning
 problem with?  Also, did you reboot after you installed the patch?

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


Hi Devin
I did not reboot after installing the patch somehow I thought simply
removing the module (as I had done to restore some stability to my
system) and reloading the module after the patch would be all I need.
Well I learned that is not the case my apologies for not trying that
first. So your tree fixed my second system with the rev 1 tuner.
However my first system with the rev 2 card while now stable with your
tree will not tune.
Barry
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 10:58 PM, Barry Williams bazzaw...@gmail.com wrote:
 Hi Devin
 I did not reboot after installing the patch somehow I thought simply
 removing the module (as I had done to restore some stability to my
 system) and reloading the module after the patch would be all I need.
 Well I learned that is not the case my apologies for not trying that
 first. So your tree fixed my second system with the rev 1 tuner.
 However my first system with the rev 2 card while now stable with your
 tree will not tune.
 Barry

Ok, good.  So now we just need to nail down why the 0fe9:db98 board
doesn't work.  Fortunately, I think I know what that bug is too.

Try this:

1.  Reboot the system.
2.  Perform a single tuning attempt.
3.  Send the full dmesg output starting at the time the box is booted.

If you're lucky, it's the issue I think it is, which will result in a
one-line patch.

Thanks,

Devin

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Devin Heitmueller
On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams bazzaw...@gmail.com wrote:
 Devin
 Attached is the output from dmesg, I hope you're right
 Thanks
 Barry

Ah, based on the dmesg I can see it wasn't what I thought it was (I
saw it was dib7000 and improperly assumed it had an xc3028 tuner like
the rev1 board does).

You should probably start a new thread on the mailing list regarding
the problems you are having with this tuner.  And you will probably
need to bisect the v4l-dvb tree and see when the breakage was
introduced.

Devin

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


Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Barry Williams
On Mon, Nov 9, 2009 at 3:17 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams bazzaw...@gmail.com wrote:
 Devin
 Attached is the output from dmesg, I hope you're right
 Thanks
 Barry

 Ah, based on the dmesg I can see it wasn't what I thought it was (I
 saw it was dib7000 and improperly assumed it had an xc3028 tuner like
 the rev1 board does).

 You should probably start a new thread on the mailing list regarding
 the problems you are having with this tuner.  And you will probably
 need to bisect the v4l-dvb tree and see when the breakage was
 introduced.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


I'd be happy to help with that however I am unfamiliar with the
concept of bisecting a tree if you could provide more info that would
be helpful and then I will start a new thread with the information I
can gather.
Thanks
Barry
--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Barry Williams
On Mon, Nov 9, 2009 at 3:47 PM, Barry Williams bazzaw...@gmail.com wrote:
 On Mon, Nov 9, 2009 at 3:17 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams bazzaw...@gmail.com wrote:
 Devin
 Attached is the output from dmesg, I hope you're right
 Thanks
 Barry

 Ah, based on the dmesg I can see it wasn't what I thought it was (I
 saw it was dib7000 and improperly assumed it had an xc3028 tuner like
 the rev1 board does).

 You should probably start a new thread on the mailing list regarding
 the problems you are having with this tuner.  And you will probably
 need to bisect the v4l-dvb tree and see when the breakage was
 introduced.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


 I'd be happy to help with that however I am unfamiliar with the
 concept of bisecting a tree if you could provide more info that would
 be helpful and then I will start a new thread with the information I
 can gather.
 Thanks
 Barry


I appear to be good at doing silly things I of course forgot I
unplugged the antenna cable from my first box to watch normal tv so
that is why it is not tuning. However now my rev 1 tuner appears to no
longer be working mythtv says it is asleep here is the output from
dmesg.

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.31-14-generic (bui...@rothera) (gcc
version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16
14:04:26 UTC 2009 (Ubuntu 2.6.31-14.48-generic)
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   NSC Geode by NSC
[0.00]   Cyrix CyrixInstead
[0.00]   Centaur CentaurHauls
[0.00]   Transmeta GenuineTMx86
[0.00]   Transmeta TransmetaCPU
[0.00]   UMC UMC UMC UMC
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009fc00 (usable)
[0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3fff (usable)
[0.00]  BIOS-e820: 3fff - 3fff8000 (ACPI data)
[0.00]  BIOS-e820: 3fff8000 - 4000 (ACPI NVS)
[0.00]  BIOS-e820: fec0 - fec01000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: fff8 - 0001 (reserved)
[0.00] DMI 2.3 present.
[0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[0.00] e820 update range:  - 0001
(usable) == (reserved)
[0.00] last_pfn = 0x3fff0 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-E uncachable
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask FC000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 base 0E000 mask FF800 write-combining
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] Scanning 0 areas for low memory corruption
[0.00] modified physical RAM map:
[0.00]  modified:  - 0001 (reserved)
[0.00]  modified: 0001 - 0009fc00 (usable)
[0.00]  modified: 0009fc00 - 000a (reserved)
[0.00]  modified: 000f - 0010 (reserved)
[0.00]  modified: 0010 - 3fff (usable)
[0.00]  modified: 3fff - 3fff8000 (ACPI data)
[0.00]  modified: 3fff8000 - 4000 (ACPI NVS)
[0.00]  modified: fec0 - fec01000 (reserved)
[0.00]  modified: fee0 - fee01000 (reserved)
[0.00]  modified: fff8 - 0001 (reserved)
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -377fe000
[0.00] Using x86 segment limits to approximate NX protection
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ 1-15000
[0.00] RAMDISK: 2f8e8000 - 3003314d
[0.00] ACPI: RSDP 000fa9e0 00014 (v00 AMI   )
[0.00] ACPI: RSDT 3fff 0002C (v01 AMIINT VIA_K7   0010
MSFT 0097)
[