[PATCH] add missing 'p' at card name 'Hauppauge HD PVR'

2010-02-14 Thread Lars Hanisch

I don't know if there are applications which rely on this name,
but after all it's a spelling mistake.

Signed-off-by: Lars Hanisch d...@cinnamon-sage.de
---
 drivers/media/video/hdpvr/hdpvr-video.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/hdpvr/hdpvr-video.c 
b/drivers/media/video/hdpvr/hdpvr-video.c
index 1c49c07..196f82d 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -573,7 +573,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
struct hdpvr_device *dev = video_drvdata(file);

strcpy(cap-driver, hdpvr);
-   strcpy(cap-card, Haupauge HD PVR);
+   strcpy(cap-card, Hauppauge HD PVR);
usb_make_path(dev-udev, cap-bus_info, sizeof(cap-bus_info));
cap-version = HDPVR_VERSION;
cap-capabilities = V4L2_CAP_VIDEO_CAPTURE |
--
1.6.3.3
--
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


videobuf and streaming I/O questions

2010-02-14 Thread Hans Verkuil
Hi all,

I've been investigating some problems with my qv4l2 utility and I encountered
some inconsistencies in the streaming I/O documentation and the videobuf
implementation.

I would like to know which is correct.

1) The VIDIOC_QBUF documentation should specify that the application has
to fill in the v4l2_buffer 'flags' field. The fact that this is not explicitly
stated tripped me up in qv4l2.

2) The VIDIOC_REQBUFS documentation states that it should be possible to use
a count of 0, in which case it should do an implicit STREAMOFF. This is
currently not implemented. I have included a patch for this below and if there
are no issues with it, then I'll make a pull request for this.

3) The VIDIOC_REQBUFS documentation states that the count field is only used
by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
videobuf certainly uses the count field.

4) The same is true for QBUF and DQBUF and the index field of struct 
v4l2_buffer:
the documentation states that it is only used for MMAP, but as far as I can tell
that is not true and it should be used for USERPTR as well.

5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
memory mapping flavor is supported by the driver. At least in the case of the
saa7146/mxb driver (which uses videobuf) this does not work. Even though it only
supports mmap, videobuf happily accepts userptr mode as well. Who is supposed
to test this? The driver before it calls videobuf_reqbufs?

6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no driver
that supports it as far as I can tell and the documentation does not explain
what it is supposed to do. What is the status of this?

When I know the correct answers to this I will fix these issues. The qv4l2 tool
is written based on the documentation instead of copy-and-paste, so this was a
good test case to discover these inconsistencies.

Regards,

Hans

---
[PATCH] V4L-DVB: Add support for count == 0 to videobuf's VIDIOC_REQBUFS 
implementation.

The spec says that VIDIOC_REQBUFS should support a count of 0, in which
case it should act like an implicit VIDIOC_STREAMOFF. The core videobuf
implementation did not support this, so we add this.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/videobuf-core.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index bb0a1c8..10cb0ec 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -40,6 +40,8 @@ MODULE_LICENSE(GPL);
if (debug = level) \
printk(KERN_DEBUG vbuf:  fmt , ## arg); } while (0)
 
+static int __videobuf_streamoff(struct videobuf_queue *q);
+
 /* - */
 
 #define CALL(q, f, arg...) \
@@ -395,11 +397,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
unsigned int size, count;
int retval;
 
-   if (req-count  1) {
-   dprintk(1, reqbufs: count invalid (%d)\n, req-count);
-   return -EINVAL;
-   }
-
if (req-memory != V4L2_MEMORY_MMAP 
req-memory != V4L2_MEMORY_USERPTR  
req-memory != V4L2_MEMORY_OVERLAY) {
@@ -414,6 +411,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
goto done;
}
 
+   if (req-count == 0) {
+   __videobuf_streamoff(q);
+   retval = 0;
+   goto done;
+   }
+
if (q-streaming) {
dprintk(1, reqbufs: streaming already exists\n);
retval = -EBUSY;
-- 
1.6.4.2



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


Re: videobuf and streaming I/O questions

2010-02-14 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hi all,
 
 I've been investigating some problems with my qv4l2 utility and I encountered
 some inconsistencies in the streaming I/O documentation and the videobuf
 implementation.
 
 I would like to know which is correct.
 
 1) The VIDIOC_QBUF documentation should specify that the application has
 to fill in the v4l2_buffer 'flags' field. The fact that this is not explicitly
 stated tripped me up in qv4l2.

I don't think you need to set the flags, but for sure you need to clear the data
on all ioctls. The capture-example.c is a reference code for implementation, 
and it
does:

CLEAR(buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = i;

if (-1 == xioctl(fd, VIDIOC_QBUF, buf))
errno_exit(VIDIOC_QBUF);

As far as I've tested, this app works on all drivers that support mmap.

 2) The VIDIOC_REQBUFS documentation states that it should be possible to use
 a count of 0, in which case it should do an implicit STREAMOFF. This is
 currently not implemented. I have included a patch for this below and if there
 are no issues with it, then I'll make a pull request for this.

This can eventually break some application. I think it is safer to fix the 
specs.

 3) The VIDIOC_REQBUFS documentation states that the count field is only used
 by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
 videobuf certainly uses the count field.

True. We need to fix the specs.
 
 4) The same is true for QBUF and DQBUF and the index field of struct 
 v4l2_buffer:
 the documentation states that it is only used for MMAP, but as far as I can 
 tell
 that is not true and it should be used for USERPTR as well.

True. We need to fix the specs.
 
 5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
 memory mapping flavor is supported by the driver. At least in the case of the
 saa7146/mxb driver (which uses videobuf) this does not work. Even though it 
 only
 supports mmap, videobuf happily accepts userptr mode as well. Who is supposed
 to test this? The driver before it calls videobuf_reqbufs?

videobuf-dma-sg supports all modes. if the driver has restrictions to one of 
the mode,
videobuf have no way to know. So, the driver must limit.

 6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no 
 driver
 that supports it as far as I can tell and the documentation does not explain
 what it is supposed to do. What is the status of this?

It is supported by videobuf and it is implemented by a few drivers. The best 
example
is bttv-driver. I think saa7134 also implements the overlay mode.

Some motherboard chipsets don't work fine on overlay mode, since, in general, 
it causes
a PCI2PCI data transfers. It is a known bug that, when PCI2PCI DMA transfers 
are happening,
and if a PCI2MEM or MEM2PCI DMA is called (for example, to write a data to disk 
or to get
swapped memory), that the two transfers got messed, causing memory and/or disk 
corruption.

There are some PCI quirks to disable this feature at the chipsets where this 
bug is known
(some chipsets manufactured by VIA and by SYS).

This is mostly why people don't get enough motivation for use it on other 
drivers.
 
 When I know the correct answers to this I will fix these issues. The qv4l2 
 tool
 is written based on the documentation instead of copy-and-paste, so this was a
 good test case to discover these inconsistencies.

Yes.
 
 Regards,
 
   Hans

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


Re: videobuf and streaming I/O questions

2010-02-14 Thread Hans Verkuil
On Sunday 14 February 2010 14:41:29 Mauro Carvalho Chehab wrote:
 Hans Verkuil wrote:
  Hi all,
  
  I've been investigating some problems with my qv4l2 utility and I 
  encountered
  some inconsistencies in the streaming I/O documentation and the videobuf
  implementation.
  
  I would like to know which is correct.
  
  1) The VIDIOC_QBUF documentation should specify that the application has
  to fill in the v4l2_buffer 'flags' field. The fact that this is not 
  explicitly
  stated tripped me up in qv4l2.
 
 I don't think you need to set the flags, but for sure you need to clear the 
 data
 on all ioctls. The capture-example.c is a reference code for implementation, 
 and it
 does:
 
 CLEAR(buf);
 buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 buf.memory = V4L2_MEMORY_MMAP;
 buf.index = i;
 
 if (-1 == xioctl(fd, VIDIOC_QBUF, buf))
 errno_exit(VIDIOC_QBUF);
 
 As far as I've tested, this app works on all drivers that support mmap.

I will fix the spec for this.

  2) The VIDIOC_REQBUFS documentation states that it should be possible to use
  a count of 0, in which case it should do an implicit STREAMOFF. This is
  currently not implemented. I have included a patch for this below and if 
  there
  are no issues with it, then I'll make a pull request for this.
 
 This can eventually break some application. I think it is safer to fix the 
 specs.

I don't really see how this would break an application and I think that some
drivers that do not use videobuf already support this. The reason why I think
this is a good idea to support it is that this makes it very easy to check
which streaming mode is supported without actually allocating anything.

I was actually using this in qv4l2 with uvc until I tried it with the mxb driver
and discovered that videobuf didn't support it. I am definitely in favor of
fixing the code instead of the spec in this case.

  3) The VIDIOC_REQBUFS documentation states that the count field is only used
  by MEMORY_MMAP, not by MEMORY_USERPTR. This seems to be a false statement.
  videobuf certainly uses the count field.
 
 True. We need to fix the specs.
  
  4) The same is true for QBUF and DQBUF and the index field of struct 
  v4l2_buffer:
  the documentation states that it is only used for MMAP, but as far as I can 
  tell
  that is not true and it should be used for USERPTR as well.
 
 True. We need to fix the specs.
  
  5) Section 3.2 states that one should use VIDIOC_REQBUFS to determine if the
  memory mapping flavor is supported by the driver. At least in the case of 
  the
  saa7146/mxb driver (which uses videobuf) this does not work. Even though it 
  only
  supports mmap, videobuf happily accepts userptr mode as well. Who is 
  supposed
  to test this? The driver before it calls videobuf_reqbufs?
 
 videobuf-dma-sg supports all modes. if the driver has restrictions to one of 
 the mode,
 videobuf have no way to know. So, the driver must limit.

OK.

 
  6) V4L2_MEMORY_OVERLAY seems to be supported in videobuf, yet there is no 
  driver
  that supports it as far as I can tell and the documentation does not explain
  what it is supposed to do. What is the status of this?
 
 It is supported by videobuf and it is implemented by a few drivers. The best 
 example
 is bttv-driver. I think saa7134 also implements the overlay mode.

Can you write a bit of documentation on how the m union of v4l2_buffer has to
be filled in for this mode? I will integrate that into the spec.

I found one mention here: 

http://archive.linuxcoding.com/video-4-linux/2002/msg03126.html

And one application that uses it here:

http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.3.tar.gz

Although it would be nice if it could actually be tested by someone whether
this is actually still working.

Regards,

Hans


 Some motherboard chipsets don't work fine on overlay mode, since, in general, 
 it causes
 a PCI2PCI data transfers. It is a known bug that, when PCI2PCI DMA transfers 
 are happening,
 and if a PCI2MEM or MEM2PCI DMA is called (for example, to write a data to 
 disk or to get
 swapped memory), that the two transfers got messed, causing memory and/or 
 disk corruption.
 
 There are some PCI quirks to disable this feature at the chipsets where this 
 bug is known
 (some chipsets manufactured by VIA and by SYS).
 
 This is mostly why people don't get enough motivation for use it on other 
 drivers.
  
  When I know the correct answers to this I will fix these issues. The qv4l2 
  tool
  is written based on the documentation instead of copy-and-paste, so this 
  was a
  good test case to discover these inconsistencies.
 
 Yes.
  
  Regards,
  
  Hans
 
 Cheers,
 Mauro
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a 

Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

2010-02-14 Thread Hans Verkuil
On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
 On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
  On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
  +#include media/v4l2-i2c-drv.h
 
 The v4l2-i2c-drv.h is to be used only for drivers that also need to 
 be compiled
 for kernels  2.6.26. If I am not mistaken that is the case for this 
 driver,
 right? I remember you mentioning that customers of yours use this on 
 such old
 kernels. Just making sure.

My company, Sensoray, doesn't have any products that use this tuner.
This driver was orignally written by Micronas to support their go7007
chip in the Plextor TV402U models.  I don't have the datasheet or know
much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems like
a good idea at the time.  What should I use instead?
   
   We way i2c devices are handled changed massively in kernel 2.6.26. In 
   order to
   stay backwards compatible with older kernels the v4l2-i2c-drv.h header was
   introduced. However, this is a bit of a hack and any i2c driver that does 
   not
   need it shouldn't use it.
   
   So only if an i2c driver is *never* used by parent drivers that have to 
   support
   kernels  2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such 
   an
   i2c driver is tvp514x.c.
   
   Eventually support for such old kernels will be dropped and the 
   v4l2-i2c-drv.h
   header will disappear altogether, but that's not going to happen anytime 
   soon.
   
   What this means for go7007 is that you have to decide whether you want 
   this
   go7007 driver to work only for kernels = 2.6.26, or whether it should 
   also
   work for older kernels. My understanding is that Sensoray wants to be 
   able to
   compile go7007 for older kernels. In that case the use of v4l2-i2c-drv.h 
   is
   correct. Note that this is not about whether any of *Sensoray's* products 
   use
   a particular i2c device, but whether the *go7007* driver uses it.
   
   I hope this clarifies this.
  
  Yes it does, thank you.  We do want to allow our customers to use the
  go7007 driver with our products on older kernels, so I would like to
  keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
  the revised patch:
 
 I've two small comments. See below.
 
 I also realized that this is really two drivers in one: one driver for the
 actual tuner device and one for the mpx device which seems similar in
 functionality to the vp27smpx.c driver.
 
 I will look at it again tomorrow, but I might decide that it is better to
 split it up into two drivers: one for the tuner and one for the mpx.

After thinking about this a bit more I decided that this tuner should be split
up into two drivers: one for the mpx device and one for the actual tuner. This
should be fairly easy to do.

One other thing that this accomplishes is that it is easier to see whether the
tuner code can actually be merged into tuner-types.c. From what I can see now
I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
PAL/SECAM model is harder since it needs to setup the tuner whenever the
standard changes. But it seems that that is also possible by adding code
to simple_std_setup() in tuner-simple.c.

I'm pretty sure that these tuners can just be folded into tuner-types.c
and tuner-simple.c. We probably only need an mpx driver.

Andy, can you also take a look?

Regards,

Hans

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


How to add DVB-S2 support to firedtv?

2010-02-14 Thread Stefan Richter
Hi all,

what steps need to be taken to get DVB-S2 support into the firedtv
driver?  (The status is, as far as I understood:  FireDTV S2 and Floppy
DTV S2 devices recognize HD channels during channel scan but cannot tune
to them.  FireDTV C/CI DVB-C boxes however tune and play back HD
channels just fine.)

I suppose the frontend needs to be extended for s2api.  Was there a
respective conversion in another DVB driver that can serve as a good
coding example?

Is documentation from Digital Everywhere required regarding the
vendor-specific AV/C requests (LNB_CONTROL? TUNE_QPSK2?) or is the
current driver code enough to connect the dots?

Is the transport stream different from DVB-C HD streams so that changes
to the isochronous I/O part would be required?
-- 
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


em28xx and Terratex Cinergy Hybrid T USB XS 0ccd,004c

2010-02-14 Thread Catimimi

Hello,

If it can help to validate this unit, you'll find below the result od 
dmesg whenit is plugged in :


[   86.977094] usb 2-1: new high speed USB device using ehci_hcd and 
address 3

[   87.129594] usb 2-1: New USB device found, idVendor=0ccd, idProduct=004c
[   87.129614] usb 2-1: New USB device strings: Mfr=2, Product=1, 
SerialNumber=0

[   87.129627] usb 2-1: Product: Cinergy Hybrid T USB XS FR
[   87.129637] usb 2-1: Manufacturer: TerraTec Electronic GmbH
[   87.129824] usb 2-1: configuration #1 chosen from 1 choice
[   87.313123] em28xx: New device TerraTec Electronic GmbH Cinergy 
Hybrid T USB XS FR @ 480 Mbps (0ccd:004c, interface 0, class 0)

[   87.326274] em28xx #0: chip ID is em2882/em2883
[   87.485970] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 4c 00 60 12 
5c 03 6a 38 a2 34
[   87.485993] em28xx #0: i2c eeprom 10: 00 00 06 57 46 07 00 00 00 00 
00 00 00 00 00 00
[   87.486011] em28xx #0: i2c eeprom 20: 4e 00 10 00 f0 10 31 88 b8 00 
14 00 5b 1e 00 00
[   87.486029] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 
00 00 00 00 00 00
[   87.486047] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486064] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486082] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 
38 03 43 00 69 00
[   87.486100] em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 
20 00 48 00 79 00
[   87.486118] em28xx #0: i2c eeprom 80: 62 00 72 00 69 00 64 00 20 00 
54 00 20 00 55 00
[   87.486135] em28xx #0: i2c eeprom 90: 53 00 42 00 20 00 58 00 53 00 
20 00 46 00 52 00
[   87.486153] em28xx #0: i2c eeprom a0: 00 00 34 03 54 00 65 00 72 00 
72 00 61 00 54 00
[   87.486170] em28xx #0: i2c eeprom b0: 65 00 63 00 20 00 45 00 6c 00 
65 00 63 00 74 00
[   87.486188] em28xx #0: i2c eeprom c0: 72 00 6f 00 6e 00 69 00 63 00 
20 00 47 00 6d 00
[   87.486206] em28xx #0: i2c eeprom d0: 62 00 48 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486223] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00
[   87.486241] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00

[   87.486260] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xfea8f21d
[   87.486266] em28xx #0: EEPROM info:
[   87.486271] em28xx #0:I2S audio, sample rate=32k
[   87.486276] em28xx #0:500mA max power
[   87.486281] em28xx #0:Table at 0x06, strings=0x386a, 0x34a2, 0x
[   87.486970] em28xx #0: Identified as Terratec Hybrid XS Secam (card=51)
[   87.486983] em28xx #0:
[   87.486984]
[   87.486990] em28xx #0: The support for this board weren't valid yet.
[   87.486996] em28xx #0: Please send a report of having this working
[   87.487002] em28xx #0: not to V4L mailing list (and/or to other 
addresses)

[   87.487004]
[   87.507721] msp3400 0-0044: MSP3415G-B8 found @ 0x88 (em28xx #0)
[   87.507737] msp3400 0-0044: msp3400 supports nicam and radio, mode is 
autodetect and autoselect

[   87.521848] tvp5150 0-005c: chip found @ 0xb8 (em28xx #0)
[   87.540508] tuner 0-0061: chip found @ 0xc2 (em28xx #0)
[   87.573389] xc2028 0-0061: creating new instance
[   87.573400] xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner
[   87.573413] usb 2-1: firmware: requesting xc3028-v27.fw
[   87.636660] xc2028 0-0061: Loading 80 firmware images from 
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[   87.685063] xc2028 0-0061: Loading firmware for type=BASE (1), id 
.
[   88.690351] xc2028 0-0061: Loading firmware for type=(0), id 
b700.

[   88.705224] SCODE (2000), id b700:
[   88.705235] xc2028 0-0061: Loading SCODE for type=MONO SCODE 
HAS_IF_4320 (60008000), id 8000.

[   88.888098] em28xx #0: Config register raw data: 0x60
[   88.888111] em28xx #0: I2S Audio (3 sample rates)
[   88.888116] em28xx #0: No AC97 audio processor
[   89.001959] tvp5150 0-005c: tvp5150am1 detected.
[   89.116049] em28xx #0: v4l2 driver version 0.1.2
[   89.132359] tvp5150 0-005c: i2c i/o error: rc == -19 (should be 1)
[   89.135958] msp3400 0-0044: I/O error #0 (read 0x10/0x30)
[   89.144720] msp3400 0-0044: I/O error #1 (read 0x10/0x30)
[   89.156582] msp3400 0-0044: I/O error #2 (read 0x10/0x30)
[   89.168058] msp3400 0-0044: resetting chip, sound will go off.
[   89.169227] msp3400 0-0044: chip reset failed
[   89.170704] msp3400 0-0044: chip reset failed
[   89.214685] em28xx #0: V4L2 device registered as /dev/video1 and 
/dev/vbi0

[   89.242829] usbcore: registered new interface driver snd-usb-audio
[   89.242843] usbcore: registered new interface driver em28xx
[   89.242854] em28xx driver loaded
[   89.353470] tvp5150 0-005c: tvp5150am1 detected.
[   89.673467] tvp5150 0-005c: tvp5150am1 detected.

There is an error with tvp5150 and with msp3400.
The following Modules are loaded :

em28xx
msp3400
tvp5150
tuner_xc3028
snd_rawmidi
snd_usb_lib
snd_usb_audio

I run openSUSE 11.2 with the very last kernel 2.6.31.12-0.1

Ready to make test.

Re: Info

2010-02-14 Thread Devin Heitmueller
On Sun, Feb 14, 2010 at 12:33 PM, Florent NOUVELLON
flonouvel...@gmail.com wrote:
 Hi Devin,

 Did you with Prahal advanced the 0072/terratec hybrid xs fm support in
 linux-dvb driver ?

 If you need any kind of help (testing, or whatever) feel free to ask me.

 Regards,
 Florent

Hi Florent,

Prahal was making good progress, and I was helping him over irc when I
had time.  But I have not invested any of my own time working on the
driver at this point (as I've been tied up working on other projects).

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


alevt-dvb now part of the dvb-apps - some critical remarks / enhancements

2010-02-14 Thread Chicken Shack
Hi everybody,
Hello Manu,

now that Francesco's proposal is reality I want to add some necessary
things as I do not want or appreciate an implementation of alevt-dvb
in a kind of half-way-down-the-line-style.

Either this is done correctly (100 %) or this should not be done at all.

I provide some patchset as outline attachment to improve:

1. alevt.patch: - Changes in Changelog, README and TODO
  a nasty superfluous error message in vbi.c is being
  wiped out

2. alevt.png:   wasn't part of the implemetation patch,
please apply manually in the main directory of alevt

3. apps_manpages.patch: in one of my creative moments I wrote a
whole bunch of manpages for the dvb-apps suite.
In case of Debianization of the package
the lintian tool requires 1 manpage per binary.
Mandatory!
4. apps_zapcycles.patch: one of my apps needs a shorter timeout for szap
to function correctly

5. dvb-apps.lintian-overrides: These are program errors that
lintian finds during testing
the validity of the package.


A. I'd appreciate to apply 1. - 3.
B. Applying 4. is not necessary, but would ease my personal hosting
C. 5. should be eliminated by an experienced software hacker

5. looks like this:

dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libucsi.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbapi.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvben50221.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbsec.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libdvbcfg.so
dvb-apps: sharedobject-in-library-directory-missing-soname
usr/lib/libesg.so


D. As I stated several times, the major problem of that program is NOT
where it is hosted, but furthermore the problem that it does not
know how to deal with a channel change in DVB mode when the transponder
is being changed by the external player application.
Just as reminder...

P. S.: Wouldn't it be a good idea to imply a dependency checker into the
dvb-apps package?
It's a bit unhandy to tell the people via readme to go to /utils/alevt
and type make, if the dependencies are fulfilled.

Guess that can be automatized?

Cheers

CS

--- a/util/alevt/ChangeLog
+++ b/util/alevt/ChangeLog
@@ -1,11 +1,11 @@
-Thu Feb 11 22:05:00 MET 2010	(1.7.0)
+Sat Feb 14 15:10:00 MET 2010	(1.7.0)
 
 - redesigned version:
 - outfile, new starting methods, libzvbi implementation
 - lots of bug fixes, all patches available in the Internet applied
-- extensive code cleanup
+- intensive code cleanup
 
-Mon Dec  3 03:11:07 MET 2007	(1.6.2)
+Mon Dec 3 03:11:07 MET 2007	(1.6.2)
 
 - compilation fixes for newer gcc
 - makefile tweaks (man vs share/man, /usr/X11R6 vs /usr, etc)
--- a/util/alevt/README
+++ b/util/alevt/README
@@ -13,7 +13,7 @@
 3. lots of cruft which is completely outdated or obsolete for other reasons
 
 To handle all that in one big effort I decided to redesign the program
-completely, enlarging its capabilities for DVB-S at the same time.
+completely, enlarging its DVB capabilities at the same time.
 
 So here are the changes:
 
@@ -22,8 +22,7 @@
 
 2. Erasure of old outdated integers, functions, parameters:
 
-- bell, big_buf, debug, display, editor, erc, fine_tune, newbttv,
-- oldbttv
+- bell, big_buf, debug, display, editor, erc, fine_tune, newbttv, oldbttv.
 
 3. Coding style cleanups (no superfluous comments, not more than
80 characters per column, no uncommented code.
@@ -52,20 +51,24 @@
make install there is an uninstaller now to revert the installation:
make uninstall.
 
-ENJOY IT!
+External dependencies to run that program:
 
-Uwe Bugla, February 11th, 2010.
+AleVT needs some some system libraries to be installed in your system.
+- libc6 (= 2.3.6)
+- libpng12 (= 1.2.13)
+- libx11 (= 1.3.3)
+- libzvbi0 (= 0.2.11)
+- zlib (= 1.1.4)
 
-External dependencies
+ENJOY IT!
 
-AleVT needs some system libraries to be installed in your system.
-They are zlib, libX11, libpng and libzvbi.
+Uwe Bugla, February 14th, 2010.
 
 Credits go to:
 - Andreas Rottmann from debian.org for compiler fixes and
   other kinds of investigation.
 - Francesco Lavra for supplying a kernel patch to avoid kernel demux
-  incompatibilities with kernels = 2.6.32
+  incompatibilities with kernels 2.6.32-rc1 - 2.6.33-rc7
 - Andy Walls for helpful investigation in kernelspace
 - Edgar Toernig for providing the source version 1.6.2 and doing all the
   development for the basic versions
--- a/util/alevt/TODO
+++ b/util/alevt/TODO
@@ -1,12 +1,18 @@
-Hi, these are issues that I unfortunately cannot resolve myself:
+These are issues that I unfortunately cannot resolve myself:
 
-1. graphical menu written in GKT2, to be used in general 

Re: [PATCH]Add support for SMT7020 to cx88

2010-02-14 Thread Helmut Auer
Am 11.02.2010 22:06, schrieb Helmut Auer:
 From: Helmut Auer hel...@helmutauer.de
 
 This patch (originally written by Dirk Herrendoerfer) adds support for the 
 built-in dvb device
 of a Samsung SMT7020s (x86 based STB) to the cx88 family.
 (see http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015208.html)
 
 Signed-off-by: Helmut Auer hel...@helmutauer.de
 
What's to do to get attention for this ?

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


[PATCH] mfd: Add timb-radio to the timberdale MFD

2010-02-14 Thread Richard Röjfors

This patch addes timb-radio to all configurations of the timberdale MFD.

Connected to the FPGA is a TEF6862 tuner and a SAA7706H DSP, the I2C
board info of these devices is passed via the timb-radio platform data.

Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 603cf06..1ed44d2 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -37,6 +37,8 @@
 #include linux/spi/max7301.h
 #include linux/spi/mc33880.h

+#include media/timb_radio.h
+
 #include timberdale.h

 #define DRIVER_NAME timberdale
@@ -213,6 +215,40 @@ const static __devinitconst struct resource 
timberdale_uartlite_resources[] = {
},
 };

+const static __devinitconst struct resource timberdale_radio_resources[] = {
+   {
+   .start  = RDSOFFSET,
+   .end= RDSEND,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = IRQ_TIMBERDALE_RDS,
+   .end= IRQ_TIMBERDALE_RDS,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static __devinitdata struct i2c_board_info timberdale_tef6868_i2c_board_info = 
{
+   I2C_BOARD_INFO(tef6862, 0x60)
+};
+
+static __devinitdata struct i2c_board_info timberdale_saa7706_i2c_board_info = 
{
+   I2C_BOARD_INFO(saa7706h, 0x1C)
+};
+
+static __devinitdata struct timb_radio_platform_data
+   timberdale_radio_platform_data = {
+   .i2c_adapter = 0,
+   .tuner = {
+   .module_name = tef6862,
+   .info = timberdale_tef6868_i2c_board_info
+   },
+   .dsp = {
+   .module_name = saa7706h,
+   .info = timberdale_saa7706_i2c_board_info
+   }
+};
+
 const static __devinitconst struct resource timberdale_dma_resources[] = {
{
.start  = DMAOFFSET,
@@ -240,6 +276,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg0[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = timb-radio,
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -282,6 +325,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg1[] = {
.resources = timberdale_mlogicore_resources,
},
{
+   .name = timb-radio,
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -314,6 +364,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg2[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = timb-radio,
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
@@ -348,6 +405,13 @@ static __devinitdata struct mfd_cell 
timberdale_cells_bar0_cfg3[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+   .name = timb-radio,
+   .num_resources = ARRAY_SIZE(timberdale_radio_resources),
+   .resources = timberdale_radio_resources,
+   .platform_data = timberdale_radio_platform_data,
+   .data_size = sizeof(timberdale_radio_platform_data),
+   },
+   {
.name = xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-02-14 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sun Feb 14 19:00:12 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14198:14021dfc00f3
gcc version: i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os: 2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-rc5-armv5: OK
linux-2.6.32.6-armv5-davinci: ERRORS
linux-2.6.33-rc5-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-dm365: ERRORS
linux-2.6.33-rc5-armv5-dm365: ERRORS
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-rc5-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-rc5-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.17-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.20-i686: OK
linux-2.6.26.8-i686: OK
linux-2.6.27.44-i686: OK
linux-2.6.28.10-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: OK
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-rc5-i686: OK
linux-2.6.32.6-m32r: OK
linux-2.6.33-rc5-m32r: OK
linux-2.6.32.6-mips: OK
linux-2.6.33-rc5-mips: OK
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-rc5-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.17-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.20-x86_64: OK
linux-2.6.26.8-x86_64: OK
linux-2.6.27.44-x86_64: OK
linux-2.6.28.10-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: OK
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-rc5-x86_64: OK
spec: OK
sparse (v4l-dvb-git): ERRORS
sparse (linux-2.6.33-rc5): ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: OK
linux-2.6.19.7-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: OK
linux-2.6.19.7-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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


[PATCH] V4L: dvb-usb, add extra sync to down-up input events

2010-02-14 Thread Jiri Slaby
Userspace is allowed to coalesce events between SYNCs. And since the code
emits UP right after DOWN for the same key, it may be missed
(up+down=nothing). Add an extra sync in between UP and DOWN events to disable
the coalesce.

Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Dmitry Torokhov d...@mail.ru
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
 drivers/media/dvb/dvb-usb/dib0700_core.c   |1 +
 drivers/media/dvb/dvb-usb/dvb-usb-remote.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c 
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 4450214..4f961d2 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -612,6 +612,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
case REMOTE_KEY_REPEAT:
deb_info(key repeated\n);
input_event(d-rc_input_dev, EV_KEY, event, 1);
+   input_sync(d-rc_input_dev);
input_event(d-rc_input_dev, EV_KEY, d-last_event, 0);
input_sync(d-rc_input_dev);
break;
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c 
b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
index 6b5ded9..a03ef7e 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
@@ -107,6 +107,7 @@ static void dvb_usb_read_remote_control(struct work_struct 
*work)
case REMOTE_KEY_REPEAT:
deb_rc(key repeated\n);
input_event(d-rc_input_dev, EV_KEY, event, 1);
+   input_sync(d-rc_input_dev);
input_event(d-rc_input_dev, EV_KEY, d-last_event, 0);
input_sync(d-rc_input_dev);
break;
-- 
1.6.6.1

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


Pull http://jusst.de/hg/v4l-dvb

2010-02-14 Thread Manu Abraham
Mauro,

Please pull from http://jusst.de/hg/v4l-dvb

for the following changes for the AZ6027 DVB USB DVB-S2 CI device

There has been a shortage of supported CI devices. The driver provides
support for the following:

- Azurewave VP-6027 or AD-SB301 or some other name by which it is called.

Additionally, it supports 2 other re branded USB devices as well, viz,

- Technisat DVB-S2 HD CI
- Terratec DVB-S2 CI


If any other STB0899/STB6100 based similar devices are known,
hopefully we can add in support in to the same driver.


changeset:   14169:fcd125343873
http://jusst.de/hg/v4l-dvb/rev/fcd125343873
AZ6027: Fix build warnings


changeset:   14168:f0304f694aca
http://jusst.de/hg/v4l-dvb/rev/f0304f694aca
AZ6027: Fix checkpatch violations


changeset:   14167:1af35f1537e7
http://jusst.de/hg/v4l-dvb/rev/1af35f1537e7
AZ6027: Add driver supported ID's


changeset:   14166:d40a2eb97f77
http://jusst.de/hg/v4l-dvb/re/d40a2eb97f77
AZ6027: Update Build


changeset:   14165:eefc5eae5449
http://jusst.de/hg/v4l-dvb/rev/eefc5eae5449
AZ6027: Add driver supported ID's


changeset:   14164:e961a33a85ac
http://jusst.de/hg/v4l-dvb/rev/e961a33a85ac
AZ6027: Initial import of the driver


It appears to function prima facie;


[  499.201809] TUPLE type:0x1b length:37
[  499.202184]   0x00: 0xcf .
[  499.202561]   0x01: 0x04 .
[  499.202934]   0x02: 0x09 .
[  499.203308]   0x03: 0x37 7
[  499.203682]   0x04: 0x55 U
[  499.204057]   0x05: 0x4d M
[  499.204432]   0x06: 0x5d ]
[  499.204807]   0x07: 0x1d .
[  499.205182]   0x08: 0x56 V
[  499.205557]   0x09: 0x22 
[  499.205931]   0x0a: 0xc0 .
[  499.206396]   0x0b: 0x09 .
[  499.206807]   0x0c: 0x44 D
[  499.207181]   0x0d: 0x56 V
[  499.207555]   0x0e: 0x42 B
[  499.207930]   0x0f: 0x5f _
[  499.208305]   0x10: 0x48 H
[  499.208679]   0x11: 0x4f O
[  499.209054]   0x12: 0x53 S
[  499.209428]   0x13: 0x54 T
[  499.209803]   0x14: 0x00 .
[  499.210178]   0x15: 0xc1 .
[  499.210552]   0x16: 0x0e .
[  499.210928]   0x17: 0x44 D
[  499.211303]   0x18: 0x56 V
[  499.211677]   0x19: 0x42 B
[  499.212052]   0x1a: 0x5f _
[  499.212427]   0x1b: 0x43 C
[  499.212801]   0x1c: 0x49 I
[  499.213176]   0x1d: 0x5f _
[  499.213551]   0x1e: 0x4d M
[  499.213926]   0x1f: 0x4f O
[  499.214388]   0x20: 0x44 D
[  499.214802]   0x21: 0x55 U
[  499.215175]   0x22: 0x4c L
[  499.215549]   0x23: 0x45 E
[  499.215924]   0x24: 0x00 .
[  499.216673] TUPLE type:0x14 length:0
[  499.217048] END OF CHAIN TUPLE type:0xff
[  499.217050] Valid DVB CAM detected MANID: DEVID:1
CONFIGBASE:0x1fe CONFIGOPTION:0xf
[  499.217053] dvb_ca_en50221_set_configoption
[  499.217672] Set configoption 0xf, read configoption 0xf
[  499.217922] DVB CAM validated successfully
[  499.518210] dvb_ca_en50221_link_init
[  499.518458] dvb_ca_en50221_wait_if_status
[  499.518709] dvb_ca_en50221_wait_if_status succeeded timeout:0
[  499.518711] dvb_ca_en50221_read_data
[  499.520206] Received CA packet for slot 0 connection id 0x0
last_frag:0 size:0x2
[  499.520455] Chosen link buffer size of 128
[  499.520706] dvb_ca_en50221_wait_if_status
[  499.520957] dvb_ca_en50221_wait_if_status succeeded timeout:0
[  499.520959] dvb_ca_en50221_write_data
[  499.523082] Wrote CA packet for slot 0, connection id 0x0
last_frag:0 size:0x2
[  499.523830] dvb_ca adapter 0: DVB CAM detected and initialised successfully


Regards,
Manu
--
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]Add support for SMT7020 to cx88

2010-02-14 Thread Mauro Carvalho Chehab
Helmut Auer wrote:
 Am 11.02.2010 22:06, schrieb Helmut Auer:
 From: Helmut Auer hel...@helmutauer.de

 This patch (originally written by Dirk Herrendoerfer) adds support for the 
 built-in dvb device
 of a Samsung SMT7020s (x86 based STB) to the cx88 family.
 (see http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015208.html)

 Signed-off-by: Helmut Auer hel...@helmutauer.de

 What's to do to get attention for this ?
 
Your patch will likely be catched by patchwork, so, it is on the queue. I should
be handle the pending patches after the holidays. Yet, as it adds a new driver,
we need the Signed-off-by from the driver author (Dirk).

-- 

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


Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

2010-02-14 Thread Andy Walls
On Sun, 2010-02-14 at 16:18 +0100, Hans Verkuil wrote:
 On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
  On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
   On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
   +#include media/v4l2-i2c-drv.h
  
  The v4l2-i2c-drv.h is to be used only for drivers that also need to 
  be compiled
  for kernels  2.6.26. If I am not mistaken that is the case for 
  this driver,
  right? I remember you mentioning that customers of yours use this 
  on such old
  kernels. Just making sure.
 
 My company, Sensoray, doesn't have any products that use this tuner.
 This driver was orignally written by Micronas to support their go7007
 chip in the Plextor TV402U models.  I don't have the datasheet or know
 much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems 
 like
 a good idea at the time.  What should I use instead?

We way i2c devices are handled changed massively in kernel 2.6.26. In 
order to
stay backwards compatible with older kernels the v4l2-i2c-drv.h header 
was
introduced. However, this is a bit of a hack and any i2c driver that 
does not
need it shouldn't use it.

So only if an i2c driver is *never* used by parent drivers that have to 
support
kernels  2.6.26, then can it drop the v4l2-i2c-drv.h. An example of 
such an
i2c driver is tvp514x.c.

Eventually support for such old kernels will be dropped and the 
v4l2-i2c-drv.h
header will disappear altogether, but that's not going to happen 
anytime soon.

What this means for go7007 is that you have to decide whether you want 
this
go7007 driver to work only for kernels = 2.6.26, or whether it should 
also
work for older kernels. My understanding is that Sensoray wants to be 
able to
compile go7007 for older kernels. In that case the use of 
v4l2-i2c-drv.h is
correct. Note that this is not about whether any of *Sensoray's* 
products use
a particular i2c device, but whether the *go7007* driver uses it.

I hope this clarifies this.
   
   Yes it does, thank you.  We do want to allow our customers to use the
   go7007 driver with our products on older kernels, so I would like to
   keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
   the revised patch:
  
  I've two small comments. See below.
  
  I also realized that this is really two drivers in one: one driver for the
  actual tuner device and one for the mpx device which seems similar in
  functionality to the vp27smpx.c driver.
  
  I will look at it again tomorrow, but I might decide that it is better to
  split it up into two drivers: one for the tuner and one for the mpx.
 
 After thinking about this a bit more I decided that this tuner should be split
 up into two drivers: one for the mpx device and one for the actual tuner. This
 should be fairly easy to do.
 
 One other thing that this accomplishes is that it is easier to see whether the
 tuner code can actually be merged into tuner-types.c. From what I can see now
 I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
 PAL/SECAM model is harder since it needs to setup the tuner whenever the
 standard changes. But it seems that that is also possible by adding code
 to simple_std_setup() in tuner-simple.c.
 
 I'm pretty sure that these tuners can just be folded into tuner-types.c
 and tuner-simple.c. We probably only need an mpx driver.
 
 Andy, can you also take a look?

Sure.  It looks like to me you actually have three chips:

- oscillator/mixer (at address 0x60 like a TUA6030)
- programmable IF PLL demodulator (at address 0x43 like a TDA9887)
- MPX demodulator/dematrix IC.


The mizer oscillator part programming *really looks like* a TUA6030 or
equivalent chip being programmed. The charge pump bit is left in a high
current state, BTW,  meaning fast tuning, but probably more phase noise
when tuned.

The IF part programming in this driver *really looks like* a TDA9887
being programmed.  I have not verified the bits being set against the
various TV system audio standards in the switch() statement though.


The MPX part has the same I2C address as some Sanyo TV Sound MPX
demodulators, but the register set is very different.  I can't figure
out what part is being used.  (NXP/Philips BTSC/SAP MPX demodulators use
address 0x5b I think).


Given this, I don't see why most of the driver could not be handled by
tuner-simple and tda9887.


The question becomes do you want to extend tuneer-simple to handle the
MPX chip in analog tuner assemblies with an included MPX chip - so the
bridge driver need not care about it - or not?


Datasheets on these tuners would be nice of course

Regards,
Andy


 
 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 

Re: Lost remote after kernel/v4l update cx23885 chipset

2010-02-14 Thread Mark Zimmerman
Greetings:

I found this http://www.spinics.net/lists/linux-media/msg15421.html
in the archives and I am having the exact same problem. Everything
worked in 2.6.31. Let me know if there is any testing I could do to
help solve this.

-- Mark

--
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: zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()

2010-02-14 Thread Antoine Jacquet

Hi,

Someone reported similar behavior recently, and was apparently able to 
fix the issue by adding more delay between open/close sequences.


No search tags to find it on the list, can You remember device model?


Yes, this was an off-list discussion, available here:
http://royale.zerezo.com/forum/viewtopic.php?t=355

Didn't work, same -110 errors, sorry, no v4l-dvb git here, vdr 
production machine on 2.6.32.7.


Just checked and the differences in the zr364xx driver are minor.
Would be better if you could work on LinuxTV hg/git tree so we have the 
same basis for patches.


1. Patch with optimized delay below, slow but works, 1st try was 
delaying subsequent msg at open sequence i=6, worked until the last 2 
open() before capture start.
From the windows snoopy log I sent yesterday I can see only 1-2 URBs 
with relevant delay of ~1s but 

cannot see the sequence point.


Ok this is a bit hardcore but nice if it works.
What do you mean by until the last 2 open()?
Also, you may want to try with simpler tools like dd to do only one 
clean open/close.
Ekiga/Cheese/Skype tend to do many open/close and this may not be the 
ideal tools for debugging, but great to trigger the bugs ;-)



What is error -22, can not find it in errno.h?


I think it's -EINVAL.

2. Picture with (640-320) lines alignment error with ekiga+cheese 
*attached*, wether cam is configured internally for 640x480 or 320x240, 
not affecting.
setting the driver to mode=2 fails with libv4l jpeg decoding errors. I 
try to correct this.


Do you know if the Windows driver support this mode?
If so, it would be helpful to have the snoop too.

3. Driver oops on modprobe -r or device firmware crash, I need to unplug 
first or null pointer fault occours (mutex locks), see below


Ok that's bad, let me know if you find the issue.

Regards,

Antoine


--
Antoine Royale Jacquet
http://royale.zerezo.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: videobuf and streaming I/O questions

2010-02-14 Thread Laurent Pinchart
Hi Hans,

On Sunday 14 February 2010 15:26:09 Hans Verkuil wrote:
 On Sunday 14 February 2010 14:41:29 Mauro Carvalho Chehab wrote:
  Hans Verkuil wrote:
   Hi all,
   
   I've been investigating some problems with my qv4l2 utility and I
   encountered some inconsistencies in the streaming I/O documentation
   and the videobuf implementation.
   
   I would like to know which is correct.

[snip]

   2) The VIDIOC_REQBUFS documentation states that it should be possible
   to use a count of 0, in which case it should do an implicit STREAMOFF.
   This is currently not implemented. I have included a patch for this
   below and if there are no issues with it, then I'll make a pull
   request for this.
  
  This can eventually break some application. I think it is safer to fix
  the specs.
 
 I don't really see how this would break an application and I think that
 some drivers that do not use videobuf already support this. The reason why
 I think this is a good idea to support it is that this makes it very easy
 to check which streaming mode is supported without actually allocating
 anything.
 
 I was actually using this in qv4l2 with uvc until I tried it with the mxb
 driver and discovered that videobuf didn't support it. I am definitely in
 favor of fixing the code instead of the spec in this case.

Using a count of 0 to free buffers definitely needs to be supported, so 
videobuf must be fixed. However, I don't think VIDIOC_REQBUFS should issue an 
implicit VIDIOC_STREAMOFF. It should instead return -EBUSY if streaming is in 
progress, or if buffers are still mapped in the userspace memory space.

Performing implicit actions make drivers more complex and error prone. I don't 
see any harm in requiring userspace to call VIDIOC_STREAMOFF before freeing 
buffers.

-- 
Regards,

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


Re: Proposal for a V4L2 Media Controller mini-summit

2010-02-14 Thread Laurent Pinchart
Hi Hans,

On Friday 12 February 2010 15:50:08 Hans Verkuil wrote:
 Hi all,
 
 During the Linux Plumbers Conference in September 2009 I organized a
 V4L-DVB mini-summit. The focus of that summit was on discussing a
 framework through which we could support all the functionality that the
 video hardware of modern embedded devices provides.
 
 It was a very successful summit and a lot of work has been done since that
 time. See this posting for to get an idea of what was discussed for those
 who were not present:
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg10136.html
 
 Since that time we have added a new API to support HDTV formats, a new
 event API is almost ready, a lot of work is being done on the media
 controller API with omap3 as guinea pig and Samsung has done work on the
 memory handling of V4L2.
 
 From April 12th to 14th the CELF Embedded Linux Conference is held in
 San Francisco, and it is co-located with the Linux Foundation Collaboration
 Summit (April 14th-16th). Links to these conferences are here:
 
 http://www.embeddedlinuxconference.com/elc_2010/index.html
 http://events.linuxfoundation.org/events/collaboration-summit
 
 I will be doing a presentation on the new framework during the ELC.
 
 Since this conference is about 6 months after the mini-summit I consider
 this a good time to organize a new V4L2 Media Controller mini-summit to
 discuss progress and future work in this area. I think that particular
 attention should be given to how we are going to do memory handling. The
 proposals from Samsung have received very little attention and we should
 discuss those in more detail.
 
 I do not know on which dates exactly such a summit can take place. There
 are three possibilities:
 
 April 10-11/12
 April 12-14
 April 14/15-16
 
 I think that registering for the ELC gives to free access to the
 Collaboration Summit, but I'm waiting for a confirmation on that.
 
 I'm not keen on the center option (12-14 April) since that often means that
 you don't see a lot of the conference itself. And the ELC is generally
 quite interesting.
 
 There is another alternative and that is that I organize a mini-summit in
 May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I
 think that it is more fun to do this during/before/after a conference. If
 only because there are a lot of linux kernel experts on hand during such a
 conference that you can ask for help if needed.
 
 Please let me know asap if you are interested in attending such a
 mini-summit and what dates are possible for you:
 
 a: April 10-11 (or 12)
 b: April 12-14
 c: April 14 (or 15)-16
 d: Somewhere in May (suggestions for dates are welcome)

I'm not keen on the B option either. C is definitely impossible for me, 
leaving only A and D. My preference currently goes for D as I'm not sure yet 
if I will be able to attend the ELC. I should have more information in the 
next few days.

-- 
Regards,

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


KWorld DVB-T 305U now working

2010-02-14 Thread Dean
My dmesg gave the following (excerpt) when I connected my KWorld 305U.

em28xx #0: Identified as KWorld DVB-T 305U (card=47)
em28xx #0: 

em28xx #0: The support for this board weren't valid yet.
em28xx #0: Please send a report of having this working
em28xx #0: not to V4L mailing list (and/or to other addresses)

So here I am, making this announcement.  Do I even have the correct mailing 
list?  What is the next step towards re-classifying the KWorld 305U as a 
supported device?

Regards.
--
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] dvb: fix sparse warnings

2010-02-14 Thread Randy Dunlap
From: Randy Dunlap randy.dun...@oracle.com

Fix sparse warnings in media/dvb/frontends:

drivers/media/dvb/frontends/dibx000_common.c:177:13: warning: non-ANSI function 
declaration of function 'systime'
drivers/media/dvb/frontends/dib0090.c:286:13: warning: function 
'dib0090_dcc_freq' with external linkage has definition
drivers/media/dvb/frontends/tda665x.c:136:55: warning: right shift by bigger 
than source value

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 drivers/media/dvb/frontends/dib0090.c|2 +-
 drivers/media/dvb/frontends/dibx000_common.c |2 +-
 drivers/media/dvb/frontends/tda665x.c|2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/dib0090.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/dib0090.c
@@ -283,7 +283,7 @@ static int dib0090_sleep(struct dvb_fron
return 0;
 }
 
-extern void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
+void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
 {
struct dib0090_state *state = fe-tuner_priv;
if (fast)
--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/dibx000_common.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/dibx000_common.c
@@ -174,7 +174,7 @@ void dibx000_exit_i2c_master(struct dibx
 EXPORT_SYMBOL(dibx000_exit_i2c_master);
 
 
-u32 systime()
+u32 systime(void)
 {
 struct timespec t;
 
--- linux-2.6.33-rc8.orig/drivers/media/dvb/frontends/tda665x.c
+++ linux-2.6.33-rc8/drivers/media/dvb/frontends/tda665x.c
@@ -133,7 +133,7 @@ static int tda665x_set_state(struct dvb_
frequency += config-ref_divider  1;
frequency /= config-ref_divider;
 
-   buf[0] = (u8) (frequency  0x7f00)  8;
+   buf[0] = (u8) ((frequency  0x7f00)  8);
buf[1] = (u8) (frequency  0x00ff)  0;
buf[2] = 0x80 | 0x40 | 0x02;
buf[3] = 0x00;
---
~Randy
--
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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

2010-02-14 Thread hermann pitton

Am Donnerstag, den 11.02.2010, 01:58 +0100 schrieb hermann pitton:
 Hi,
 
 Am Mittwoch, den 10.02.2010, 20:36 +0100 schrieb Jean Delvare:
  On Wed, 10 Feb 2010 16:40:03 -0200, Mauro Carvalho Chehab wrote:
   Jean Delvare wrote:
Under the assumption that saa7134_hwinit1() only touches GPIOs
connected to IR receivers (and it certainly looks like this to me) I
fail to see how these pins not being initialized could have any effect
on non-IR code.
   
   Now, i suspect that you're messing things again: are you referring to 
   saa7134_hwinit1() or
   to saa7134_input_init1()?
   
   I suspect that you're talking about moving saa7134_input_init1(), since 
   saa7134_hwinit1()
   has the muted and spinlock inits. It also has the setups for video, vbi 
   and mpeg. 
   So, moving it require more care.
  
  Err, you're right, I meant saa7134_input_init1() and not
  saa7134_hwinit1(), copy-and-paste error. Sorry for adding more
  confusion where it really wasn't needed...
  
 
 both attempts of Jean will work.
 
 If we are only talking about moving input_init, only that Jean did
 suggest initially, it should work, since only some GPIOs for enabling
 remote chips are affected.
 
 I can give the crappy tester, but don't have such a remote, but should
 not be a problem to trigger the GPIOs later.
 
 Cheers,
 Hermann
 

Hi Jean,

I did test your patch, only following Roman's initial patch already
known, on eight different cards for now, also with three slightly
different remotes and it does not have any negative impact.

Please consider, that it is only about that single card for now and a
per card solution is enough.

I strongly remind, that we should not rely on unknown eeprom bytes, as
told previously and should not expand such into any direction.

If we make progress there, we should change it for all cards, but again,
what had happened on the m$ drivers previously is not encouraging to do
it without any need.

To do it per card in need for now seems enough service to me.

If more such should come, unlikely on that driver, I would at first deny
auto detection support, since they are breaking rules.

The problem likely will time out very soon.

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: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner

2010-02-14 Thread Hans Verkuil
On Sunday 14 February 2010 23:10:48 Andy Walls wrote:
 On Sun, 2010-02-14 at 16:18 +0100, Hans Verkuil wrote:
  On Saturday 13 February 2010 00:17:44 Hans Verkuil wrote:
   On Friday 12 February 2010 23:36:20 Pete Eberlein wrote:
On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote:
+#include media/v4l2-i2c-drv.h
   
   The v4l2-i2c-drv.h is to be used only for drivers that also need 
   to be compiled
   for kernels  2.6.26. If I am not mistaken that is the case for 
   this driver,
   right? I remember you mentioning that customers of yours use this 
   on such old
   kernels. Just making sure.
  
  My company, Sensoray, doesn't have any products that use this tuner.
  This driver was orignally written by Micronas to support their 
  go7007
  chip in the Plextor TV402U models.  I don't have the datasheet or 
  know
  much about tuners anyway.  I used the v4l2-i2c-drv.h since it seems 
  like
  a good idea at the time.  What should I use instead?
 
 We way i2c devices are handled changed massively in kernel 2.6.26. In 
 order to
 stay backwards compatible with older kernels the v4l2-i2c-drv.h 
 header was
 introduced. However, this is a bit of a hack and any i2c driver that 
 does not
 need it shouldn't use it.
 
 So only if an i2c driver is *never* used by parent drivers that have 
 to support
 kernels  2.6.26, then can it drop the v4l2-i2c-drv.h. An example of 
 such an
 i2c driver is tvp514x.c.
 
 Eventually support for such old kernels will be dropped and the 
 v4l2-i2c-drv.h
 header will disappear altogether, but that's not going to happen 
 anytime soon.
 
 What this means for go7007 is that you have to decide whether you 
 want this
 go7007 driver to work only for kernels = 2.6.26, or whether it 
 should also
 work for older kernels. My understanding is that Sensoray wants to be 
 able to
 compile go7007 for older kernels. In that case the use of 
 v4l2-i2c-drv.h is
 correct. Note that this is not about whether any of *Sensoray's* 
 products use
 a particular i2c device, but whether the *go7007* driver uses it.
 
 I hope this clarifies this.

Yes it does, thank you.  We do want to allow our customers to use the
go7007 driver with our products on older kernels, so I would like to
keep the v4l2-i2c-drv.h for now.  I've addressed your other comments in
the revised patch:
   
   I've two small comments. See below.
   
   I also realized that this is really two drivers in one: one driver for the
   actual tuner device and one for the mpx device which seems similar in
   functionality to the vp27smpx.c driver.
   
   I will look at it again tomorrow, but I might decide that it is better to
   split it up into two drivers: one for the tuner and one for the mpx.
  
  After thinking about this a bit more I decided that this tuner should be 
  split
  up into two drivers: one for the mpx device and one for the actual tuner. 
  This
  should be fairly easy to do.
  
  One other thing that this accomplishes is that it is easier to see whether 
  the
  tuner code can actually be merged into tuner-types.c. From what I can see 
  now
  I would say that that is possible for the NTSC_M and NTSC_M_JP models. The
  PAL/SECAM model is harder since it needs to setup the tuner whenever the
  standard changes. But it seems that that is also possible by adding code
  to simple_std_setup() in tuner-simple.c.
  
  I'm pretty sure that these tuners can just be folded into tuner-types.c
  and tuner-simple.c. We probably only need an mpx driver.
  
  Andy, can you also take a look?
 
 Sure.  It looks like to me you actually have three chips:
 
 - oscillator/mixer (at address 0x60 like a TUA6030)
 - programmable IF PLL demodulator (at address 0x43 like a TDA9887)
 - MPX demodulator/dematrix IC.

I've been focusing so much on the IF_I2C_ADDR and MPX_I2C_ADDR defines that
I completely missed the fact that there is also the tuner at 0x60 :-(

You are completely correct: it looks very much like a standard simple
tuner + tda9887.

 
 
 The mizer oscillator part programming *really looks like* a TUA6030 or
 equivalent chip being programmed. The charge pump bit is left in a high
 current state, BTW,  meaning fast tuning, but probably more phase noise
 when tuned.
 
 The IF part programming in this driver *really looks like* a TDA9887
 being programmed.  I have not verified the bits being set against the
 various TV system audio standards in the switch() statement though.
 
 
 The MPX part has the same I2C address as some Sanyo TV Sound MPX
 demodulators, but the register set is very different.  I can't figure
 out what part is being used.  (NXP/Philips BTSC/SAP MPX demodulators use
 address 0x5b I think).
 
 
 Given this, I don't see why most of the driver could not be handled by
 tuner-simple and