Re: [PATCH 3/5] OV3640: Add driver
On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote: Further, we have multiple sensors following CCI[1] - why not have a driver for the same, it will simplify the entire process - ov3640, mt9p012 both follow the spec at least.. dependency would be sensor - cci dev-i2c framework. Sakari has written smiaregs.c pretty much exactly for this purpose. You should check it out. - Tuukka -- 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: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: get rid of video_decoder.h
On Tuesday 10 March 2009 02:20:02 Patch from Mauro Carvalho Chehab wrote: The patch number 10870 was added via Mauro Carvalho Chehab mche...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org -- From: Mauro Carvalho Chehab mche...@redhat.com v4l2-ioctl: get rid of video_decoder.h The V4L1 obsoleted header video_decoder.h is not used anymore by any driver. Only a name decoding function at v4l2-ioctl still implements it. Hoorah! Note that video_encoder.h is now also unused, but since that header isn't in v4l-dvb it should be removed manually in the kernel during the 2.6.30 merge window. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
Hi Did you setup the /etc/rdsd.conf file correctly? Here is mine: $ cat /etc/rdsd.conf [global] unix-socket = /var/tmp/rdsd.sock tcpip-port = 4321 logfile = /var/tmp/rdsd.log pidfile = /var/tmp/rdsd.pid console-log = yes file-log = yes loglevel = 5 [source] name = Terratec PCI card path = /dev/radio0 type = radiodev I had tunerfreq = 102000 line. After removing this line rdsd started well. After setting up this file I run 'rdsd'. With rdsquery -f you can set the frequency in khz. When run rdsquery -f 102000 the programm was hold without any messages. I pressed Crt+C for exit. Try using v4l2-ctl -d /dev/radio0 -f 102 to set the frequency. That may have been what I was actually using rather than rdsquery. This command works right. Then run rdsquery -t \ rxfre,rxsig,rflags,picode,ptype,pname,locdt,utcdt,rtxt,lrtxt,tmc,aflist -c0 This command not work too, hold and sleep. If the frequency wasn't set, then that might explain it. Or perhaps you should combine the -f with the -t flag? Out from rdsquery rxfre:102000 rxsig:32768 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=1 picode:20480 ptype:5 rtxt:io T 020 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=1 picode:20480 ptype:5 rtxt:io T 0202004 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=1 picode:20480 ptype:5 rtxt:io T 0202004roni rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 pname:STN + rxfre:102000 rxsig:32768 rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 rtxt: Rad rflags:TP=0 TA=0 MUSIC=0 STEREO=0 AH=0 COMP=0 DPTY=0 AB=0 picode:20480 ptype:5 rtxt:TRDS Rad With my best regards, Dmitry. You can also attempt to debug in the saa6588 to see whether it picks up any packets. Regards, Hans With my best regards, Dmitry. and watch the rds data appear. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[patch review] radio-terratec: remove unused delay.h
Hello, all I don't know if this patch okay, so it should be tested/reviewed. Anyway, compilation process shows no warnings. --- Patch removes linux/delay.h which hadn't been used. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r 615fb8f01610 linux/drivers/media/radio/radio-terratec.c --- a/linux/drivers/media/radio/radio-terratec.cTue Mar 10 02:33:02 2009 -0300 +++ b/linux/drivers/media/radio/radio-terratec.cTue Mar 10 09:49:36 2009 +0300 @@ -27,7 +27,6 @@ #include linux/module.h /* Modules */ #include linux/init.h/* Initdata */ #include linux/ioport.h /* request_region */ -#include linux/delay.h /* udelay */ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/version.h /* for KERNEL_VERSION MACRO */ -- Best regards, Klimov Alexey -- 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] radio-rtrack2: fix double mutex_unlock
Patch fixes double mutex unlocking. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r 615fb8f01610 linux/drivers/media/radio/radio-rtrack2.c --- a/linux/drivers/media/radio/radio-rtrack2.c Tue Mar 10 02:33:02 2009 -0300 +++ b/linux/drivers/media/radio/radio-rtrack2.c Tue Mar 10 09:28:27 2009 +0300 @@ -60,7 +60,6 @@ return; mutex_lock(dev-lock); outb(1, dev-io); - mutex_unlock(dev-lock); mutex_unlock(dev-lock); dev-muted = 1; } -- Best regards, Klimov Alexey -- 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 review] radio-terratec: remove unused delay.h
Hello, all I don't know if this patch okay, so it should be tested/reviewed. Anyway, compilation process shows no warnings. --- Patch removes linux/delay.h which hadn't been used. Signed-off-by: Alexey Klimov klimov.li...@gmail.com Looks good. Signed-off-by: Hans Verkuil hverk...@xs4all.nl -- diff -r 615fb8f01610 linux/drivers/media/radio/radio-terratec.c --- a/linux/drivers/media/radio/radio-terratec.c Tue Mar 10 02:33:02 2009 -0300 +++ b/linux/drivers/media/radio/radio-terratec.c Tue Mar 10 09:49:36 2009 +0300 @@ -27,7 +27,6 @@ #include linux/module.h/* Modules */ #include linux/init.h /* Initdata */ #include linux/ioport.h/* request_region */ -#include linux/delay.h /* udelay */ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/version.h /* for KERNEL_VERSION MACRO */ -- Best regards, Klimov Alexey -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] radio-rtrack2: fix double mutex_unlock
Patch fixes double mutex unlocking. Signed-off-by: Alexey Klimov klimov.li...@gmail.com Ouch. Signed-off-by: Hans Verkuil hverk...@xs4all.nl Thanks! Hans -- diff -r 615fb8f01610 linux/drivers/media/radio/radio-rtrack2.c --- a/linux/drivers/media/radio/radio-rtrack2.c Tue Mar 10 02:33:02 2009 -0300 +++ b/linux/drivers/media/radio/radio-rtrack2.c Tue Mar 10 09:28:27 2009 +0300 @@ -60,7 +60,6 @@ return; mutex_lock(dev-lock); outb(1, dev-io); - mutex_unlock(dev-lock); mutex_unlock(dev-lock); dev-muted = 1; } -- Best regards, Klimov Alexey -- 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 -- 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: Compro VideoMate U90
After investigating the Windows driver CD, the chip appeared to be described as a RTL2831U. This led me to the rtl2831-r2 driver here: http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/ The product ID of my device doesn't seem to be defined in this driver, though many similar device based on the same chipset are. Is it possible to add the ID for this device? I would be happy to test! Regards, Scott. On Tue, Mar 10, 2009 at 2:43 PM, scott scottl...@gmail.com wrote: Hi, I recently bought a Compro VideoMate U90, described on the box as a USB 2.0 DVB-T Stick with Remote. When plugging it in, /var/log/messages simply says: Mar 10 12:50:49 sonata kernel: [60359.936022] usb 4-5: new high speed USB device using ehci_hcd and address 3 Mar 10 12:50:49 sonata kernel: [60360.070474] usb 4-5: configuration #1 chosen from 1 choice -- 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: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: get rid of video_decoder.h
On Tue, 10 Mar 2009 08:31:32 +0100 Hans Verkuil hverk...@xs4all.nl wrote: The V4L1 obsoleted header video_decoder.h is not used anymore by any driver. Only a name decoding function at v4l2-ioctl still implements it. Hoorah! Yes! We're finally getting rid of some of those V4L1 headers. The only remaining one is videodev.h. Note that video_encoder.h is now also unused, but since that header isn't in v4l-dvb it should be removed manually in the kernel during the 2.6.30 merge window. I've already got rid of video_encoder.h on my -git tree. I just wrote a patch removing the rest of video_decoder.h references on -git. Yet, there are a few drivers that still requires V4L1 videodev.h header: A minimal set of V4L1 stuff, just for VIDIOCMBUF: linux/include/media/videobuf-core.h linux/include/media/v4l2-ioctl.h Core modules, to preserve V4L1 compatibility: linux/drivers/media/video/v4l2-ioctl.c linux/drivers/media/video/v4l1-compat.c linux/drivers/media/video/v4l2-compat-ioctl32.c V4L1 legacy webcam drivers: linux/include/media/ovcamchip.h linux/drivers/media/video/stv680.c linux/drivers/media/video/ov511.h linux/drivers/media/video/w9966.c linux/drivers/media/video/meye.c linux/drivers/media/video/bw-qcam.c linux/drivers/media/video/cpia.h linux/drivers/media/video/cpia2/cpia2_v4l.c linux/drivers/media/video/cpia2/cpia2.h linux/drivers/media/video/cpia2/cpia2dev.h linux/drivers/media/video/se401.h linux/drivers/media/video/c-qcam.c linux/drivers/media/video/usbvideo/usbvideo.h linux/drivers/media/video/usbvideo/vicam.c linux/drivers/media/video/w9968cf.c linux/drivers/media/video/arv.c linux/drivers/media/video/pwc/pwc.h A few capture drivers: linux/drivers/media/video/zoran/zoran_driver.c linux/drivers/media/video/stradis.c linux/drivers/media/video/pms.c And two i2c helper drivers: linux/drivers/media/video/msp3400-driver.c linux/drivers/media/video/tuner-core.c Most of the above are the legacy V4L1 webcam drivers. It would be really nice if someone could volunteer to port those Webcam drivers to gspca. I suspect that it shouldn't hard to remove the few V4L1 bits from zoran_driver, after all the conversions made. Yet, there are some Zoran specific ioctls that use this. We should probably discontinue those zoran-specific ioctls. It seems also safe to remove V4L1 code from msp3400, since, AFAIK, all drivers that supports it are already converted to V4L2. After converting stradis, it will be probably safe also to remove V4L1 code from tuner-core. I doubt that there are still some pms hardware around, but it would be interesting to keep this module, since this is the first V4L driver wrote. -- 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 5/5] LDP: Add support for built-in camera
On Mon, 2009-03-09 at 15:24 -0500, Aguirre Rodriguez, Sergio Alberto
wrote:
Hi,
-Original Message-
From: stanley.miao [mailto:stanley.m...@windriver.com]
snip
+static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
+#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
+ {
+ I2C_BOARD_INFO(ov3640, OV3640_I2C_ADDR),
+ .platform_data = ldp_ov3640_platform_data,
+ },
+#endif
+};
This new added i2c_board_info was not registered.
After I added this line,
omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
ARRAY_SIZE(ldp_i2c_boardinfo_2));
the sensor was found. but the test still failed. A lot of error came out
when I run my test program.
3CSI2: ComplexIO Error IRQ 80
CSI2: ComplexIO Error IRQ 80
3CSI2: ComplexIO Error IRQ c2
CSI2: ComplexIO Error IRQ c2
3CSI2: ComplexIO Error IRQ c2
CSI2: ComplexIO Error IRQ c2
3CSI2: ComplexIO Error IRQ c6
CSI2: ComplexIO Error IRQ c6
3CSI2: ECC correction failed
CSI2: ECC correction failed
3CSI2: ComplexIO Error IRQ 6
CSI2: ComplexIO Error IRQ 6
3CSI2: ComplexIO Error IRQ 6
CSI2: ComplexIO Error IRQ 6
3CSI2: ComplexIO Error IRQ 6
CSI2: ComplexIO Error IRQ 6
3CSI2: ComplexIO Error IRQ 6
CSI2: ComplexIO Error IRQ 6
Oops, my mistake. Missed to add that struct there... Fixed now.
About the CSI2 errors you're receiving... Which version of LDP are you using?
Which Silicon revision has (ES2.1 or ES3.0)?
ZOOM1 board(LDP3430-VG1.0.0-1), omap3430 ES2.1.
When I use your old version patch, sometimes the test succeed, sometimes
failed(no data was generated and no error). This version, always failed.
Thanks.
Stanley.
Regards,
Sergio
Stanley.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and camera drivers (update)
Aguirre Rodriguez, Sergio Alberto wrote: Hi Sakari, Hello, Sergio! Doing a pull like you suggested in past release: $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ iommu omap3camera base Brings the same code than before... Oops. Could you try again now? I see that omap3isp branch is updated on gitorious, but trying to pull that branch gives merge errors. Are you pulling it on top of linux-omap? I've replaced the whole patchset so git tries to apply the new patches on top of the old ones. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 2/4] pxa_camera: Redesign DMA handling
On Tue, 10 Mar 2009, robert.jarz...@free.fr wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Now, this is the trick: we use a dummy descriptor (actually, the one from the new video buffer, but it doesn't matter) to set up a descriptor to \ - that doesn't seem right to me Have a look at the schema I drew. The DMA restarts at the dummy descriptor, which finishes the partial page transfer interrupted, and resumes at first vb. OK, let's assume this works perfectly. Then the buffer first vb, second vb, third vb are processed. But the DMA chain doesn't stop, it continues to the dummy descritor, then jumps back in the middle of first vb, and corrupts it, doesn't it ? Now consider the first vb was unqueued _and_ requeued in the meantime, while the new buffer was under DMA active filling. Won't we finish with something like : +---+ +--+ | Former New vb | dummy | | First vb | dummy | +---^---|---+ +^-+---|---+ | | | | | +---+ | |former link | | | | | +-+ new restarter link No. remember, the last _valid_ descriptor contains the DDADR_STOP as the next descriptor address, so, it'll stop there. Now we restart DMA at our dummy descriptor. Actually, it is not dummy any more, it is linking, partial, or whatever you call it. OK. That's good, now I understand it. I will try to reproduce your DMA link architecture, because as it is, I don't yet understand why capture_example fails ... Would you mind if I changed the pxa descriptors chain for _one_ video buffer into : +---+++-+---+-+ | restarter | desc-sg[0] | desc-sg[1] | ... | desc-sg[last] | finisher/linker | +---+++-+---+-+ where : - desc-sg[n] are descriptors to fill in the image - finisher/linker is either the DMA STOP, or just a 0 bytes transfer with next descriptor set up to the desc-sg[0] of the next captured frame - restarter is never used (ie. DMA chains start always at desc-sg[0]), excepting when restarting a running chain I know I ask for 1 additionnal descriptor, but I find that easier to maintain. Would you agree for such a change ? 1 Additional descriptor is not a big problem per se, they are only a few bytes big, the question is only if this really improves anything. I have taken over the current solution as the only working from original sources, probably, going back to Intel. As you understand, this is quite critical code, and we shouldn't break it. So, unless there are real good reasons to change it, I would try to leave it as is. If we found a way to improve the procedure, e.g., to avoid having to stop DMA when queuing a new buffer, that would be great! But so far I do not see a way to do this in a race-free way. Maybe we could do something like 1. prepare the new descriptor-chain. 2. with one instruction append it to the current tail by just rewriting the tail's next descriptor pointer, which was equal to DDADR_STOP 3. verify if it worked, i.e., if DMA is still before the merge-point or already after it. 4. fast path - in most cases we would succeed, so, we are done, just update all our software states. If we failed, and DMA stopped before we have overwritten the pointer, re-start DMA from the beginning of our new buffer, which should be fast and race-free. I think, actually, this might work. We only have to think carefully about 3 - how do we reliably verify the DMA status? What do you think? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pxa_camera: Redesign DMA handling
Now consider the first vb was unqueued _and_ requeued in the meantime, while the new buffer was under DMA active filling. Won't we finish with something like : +---+ +--+ | Former New vb | dummy | | First vb | dummy | +---^---|---+ +^-+---|---+ | | | | | +---+ | |former link | | | | | +-+ new restarter link No. remember, the last _valid_ descriptor contains the DDADR_STOP as the next descriptor address, so, it'll stop there. OK, I see. I'll check this evening. Would you mind if I changed the pxa descriptors chain for _one_ video buffer into : +---+++-+---+-+ | restarter | desc-sg[0] | desc-sg[1] | ... | desc-sg[last] | finisher/linker | +---+++-+---+-+ where : - desc-sg[n] are descriptors to fill in the image - finisher/linker is either the DMA STOP, or just a 0 bytes transfer with next descriptor set up to the desc-sg[0] of the next captured frame - restarter is never used (ie. DMA chains start always at desc-sg[0]), excepting when restarting a running chain I know I ask for 1 additionnal descriptor, but I find that easier to maintain. Would you agree for such a change ? 1 Additional descriptor is not a big problem per se, they are only a few bytes big, the question is only if this really improves anything. I have taken over the current solution as the only working from original \- I'm not really convinced, as capture_example _doesn't_ work and remains unkillable. You have my test bed at your disposition (previous mail), you can try. sources, probably, going back to Intel. As you understand, this is quite critical code, and we shouldn't break it. So, unless there are real good \- true, we sould improve it. in a race-free way. Maybe we could do something like 1. prepare the new descriptor-chain. 2. with one instruction append it to the current tail by just rewriting the tail's next descriptor pointer, which was equal to DDADR_STOP 3. verify if it worked, i.e., if DMA is still before the merge-point or already after it. 4. fast path - in most cases we would succeed, so, we are done, just update all our software states. If we failed, and DMA stopped before we have overwritten the pointer, re-start DMA from the beginning of our new buffer, which should be fast and race-free. I think, actually, this might work. We only have to think carefully about 3 - how do we reliably verify the DMA status? I don't think there is a way with this approach. The trouble is if we don't stop the DMA, we'll read DDADR() and act upon its value. But the time we act, DDADR() could have changed to DDADR_STOP for example. OTOH, what could be done is to check in the pxa_cam_wakeup(), when we dequeue a video buffer, if DDADR() == DDADR_STOP. If the DMA is stopped and a buffer remains on the capture list, we fell into the case where our chaining didn't work = we call pxa_cam_start_capture(), and the videobuffer will be handled. If DDADR() was not DDADR_STOP, that means _another_ buffer was running, and we have the guarantee to be called once again in pxa_cam_wakeup(), so we leave the situation as it is, and check the next time. With this approach (which is your approach, but 3+4 are moved to pxa_camera_wakeup), we shouldn't need to stop the DMA chain. The price to pay is a check in pxa_camera_wakeup(), and a restart of a frame queued in an impossibly tiny time window. What do you think of that one ? What do you think? I think we think basically the same thing, and that's good :) I'll make a try this evening, and maybe another couple of days to cross-check all debug traces. I'll try the algorithm we specified (as there might be exchanges in the day). As a fallback, if it doesn't work, I would have to stop the DMA chain as before. Don't hesitate to comment on the algorithm, there's still refining to be done, and I need you on it. I feel something great will come out of it : Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial tuning file update for fi-*
Terve, DVB-T updates for Finland. regards Antti -- http://palosaari.fi/ diff -r 89ace84489b0 util/scan/dvb-t/fi-Rantalaki --- a/util/scan/dvb-t/fi-Rantalaki Sun Mar 08 22:28:51 2009 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,4 +0,0 @@ -# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 71400 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 77000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 89ace84489b0 util/scan/dvb-t/fi-Salla_Saija --- a/util/scan/dvb-t/fi-Salla_SaijaSun Mar 08 22:28:51 2009 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,4 +0,0 @@ -# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 61000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 89ace84489b0 util/scan/dvb-t/fi-Salla_Sarivaara --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-Salla_SarivaaraTue Mar 10 12:59:11 2009 +0200 @@ -0,0 +1,4 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 61000 8MHz 2/3 NONE QAM64 8k 1/8 NONE
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. This sounds like a codec interface as 'described' here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC It would be a first for V4L2 to have a driver that can do this, but I agree that that would be a single device that has both 'output' and 'capture'. Ok. Although this work most probably will be left for future at this point. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? Oh dear. Please don't use 'use counts'. It is perfectly acceptable and desirable to have multiple opens on the same video node. Only one file Use counts are really bad and totally unnecessary. Only if another file handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it make sense to return -EBUSY for certain ioctls or read/write operations. Otherwise you shouldn't limit the user from opening the same device node as many times as he wants and use that to query the video device. ? Having a use count doesn't prevent multiple file handles nor otherwise artificially limit functionality. We need to be able to shut down the slaves when they are no longer needed. IMO having an use count to do this is fine (unless otherwise proven). Also the camera driver does try_module_get() to the slaves when it's opened by the first user. module_put() is called on those when the last user goes away. We'd also like to get rid of the current way of directly telling the slaves what their power state should be. Rather we'd like to tell the slaves what's expected from them. This could translate to open/release/streamon/streamoff commands. To be able to do this, the use count is required --- unless this task is given to the slaves (v4l2_subdevs). BTW, I looked at omap24xxcam_open(): data like fh-pix does *not* belong to the filehandle struct, it should be part of the top-level data structure. That's fixed in the omap34xxcam.c. :) You want to be able to do simple things like querying a video node for the currently selected format. You can't do that if the format is stored in the filehandle! E.g.: you are streaming and you want to run v4l2-ctl --get-fmt-video to check what video format is being used. Things like this must be supported by a well-written v4l2 driver. Again, sadly quite a few v4l2 drivers do this wrong as well :-( I also see that cam-users is not decreased by one if omap24xxcam_sensor_enable() fails. Note that I'm looking at the code in the v4l-dvb repository, the linux-omap git tree might have fixed that already. I'm afraid it's still there. Will fix that. Thanks. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
On Tue, 10 Mar 2009 12:09:48 +0200 Antti Palosaari cr...@iki.fi wrote: Mauro, Could you remove this bad patch patch soon? It must not go to the final 2.6.29 as it breaks so many old devices. One of those is MSI Megasky 580 which is rather popular. regards Antti Antti Palosaari wrote: Hello, This patch breaks devices using tuner behind zl10353 i2c-gate. au6610: Sigmatek DVB-110 DVB-T USB2.0 gl861: MSI Mega Sky 55801 DVB-T USB2.0 A-LINK DTU DVB-T USB2.0 Probably some other too. I think it is better to disable i2c-gate setting callback to NULL after demod attach like dtv5100 does this. Also .no_tuner is bad name what it does currently. My opinion is that current .no_tuner = 1 should be set as default, because most configuration does not this kind of slave tuner setup where tuner is programmed by demod. Change no_tuner to slave_tuner and set slave_tuner = 1 only when needed (not many drivers using that). Hi Antti/Dmitri, I agree that no_tuner is a bad name. The best is to rename it to something like tuner_is_behind_bridge. If equal to 1, then it will use the new behaviour, otherwise the old one, and fix the boards where this trouble were found. Could one of you please do such patchset? Thanks, 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: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: get rid of video_decoder.h
On Tue, 10 Mar 2009 10:12:42 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: V4L1 legacy webcam drivers: linux/include/media/ovcamchip.h linux/drivers/media/video/stv680.c linux/drivers/media/video/ov511.h linux/drivers/media/video/w9966.c linux/drivers/media/video/meye.c linux/drivers/media/video/bw-qcam.c linux/drivers/media/video/cpia.h linux/drivers/media/video/cpia2/cpia2_v4l.c linux/drivers/media/video/cpia2/cpia2.h linux/drivers/media/video/cpia2/cpia2dev.h linux/drivers/media/video/se401.h linux/drivers/media/video/c-qcam.c linux/drivers/media/video/usbvideo/usbvideo.h linux/drivers/media/video/usbvideo/vicam.c linux/drivers/media/video/w9968cf.c linux/drivers/media/video/arv.c linux/drivers/media/video/pwc/pwc.h I've got several of these: w9968cf, usbvideo, cpia_usb, stv680 (I think) and ov511. Once converted one, the other conversions will probably be easy. maybe Jean-Francois or another gspca-submaintainer could convert one of the webcam drivers you have. Then, you can test (and fix). After this changeset, the conversion for the others will likely be trivial. A few capture drivers: linux/drivers/media/video/zoran/zoran_driver.c linux/drivers/media/video/stradis.c linux/drivers/media/video/pms.c And two i2c helper drivers: linux/drivers/media/video/msp3400-driver.c linux/drivers/media/video/tuner-core.c Most of the above are the legacy V4L1 webcam drivers. It would be really nice if someone could volunteer to port those Webcam drivers to gspca. I suspect that it shouldn't hard to remove the few V4L1 bits from zoran_driver, after all the conversions made. Yet, there are some Zoran specific ioctls that use this. We should probably discontinue those zoran-specific ioctls. I didn't dare do that when I did the conversion. Someone would have to analyze these BUZ ioctls, but I think they all have proper v4l2 equivalents. The only BUZ_foo that requires may require some work are the BUZIOC_G_PARAMS/BUZIOC_S_PARAMS, since it has some controls to the MJPEG stream. I'm not sure if everything is implemented. There are some BUZ_ ioctls that are similar to V4L2 (REQBUFS, QBUF). I don't see why we need yet another set of mmap methods here. The BUZIOC_SYNC doesn't make much sense to my eyes, except if you're stopping a stream. In this case, VIDIOC_STREAMOFF should already provide a sync functionality. The last one BUZIOC_G_STATUS is a merge of some other status already existent on V4L2. The only detail here is that the Zoran mmap methods provide two modes: QBUF_PLAY and QBUF_CAPT. We should take some care to understand the logic behind this. It seems also safe to remove V4L1 code from msp3400, since, AFAIK, all drivers that supports it are already converted to V4L2. I didn't realize that there was still some V4L1 code in that driver. It can certainly be removed. Ok. Maybe you could provide us an strip patch for those legacy code. Otherwise, I'll handle that later. After converting stradis, it will be probably safe also to remove V4L1 code from tuner-core. I doubt that there are still some pms hardware around, but it would be interesting to keep this module, since this is the first V4L driver wrote. I have one! I managed to get one for $4 (+$16 shipping :-) ). It actually works (sort of) and I want to convert it to v4l2, just as a fun project. Yes, this seems a very interesting fun project ;) 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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
Hi Mauro On Tue, 10 Mar 2009 12:09:48 +0200 Antti Palosaari cr...@iki.fi wrote: Mauro, Could you remove this bad patch patch soon? It must not go to the final 2.6.29 as it breaks so many old devices. One of those is MSI Megasky 580 which is rather popular. regards Antti Antti Palosaari wrote: Hello, This patch breaks devices using tuner behind zl10353 i2c-gate. au6610: Sigmatek DVB-110 DVB-T USB2.0 gl861: MSI Mega Sky 55801 DVB-T USB2.0 A-LINK DTU DVB-T USB2.0 Probably some other too. I think it is better to disable i2c-gate setting callback to NULL after demod attach like dtv5100 does this. Also .no_tuner is bad name what it does currently. My opinion is that current .no_tuner = 1 should be set as default, because most configuration does not this kind of slave tuner setup where tuner is programmed by demod. Change no_tuner to slave_tuner and set slave_tuner = 1 only when needed (not many drivers using that). Hi Antti/Dmitri, I agree that no_tuner is a bad name. The best is to rename it to something like tuner_is_behind_bridge. If equal to 1, then it will use the new behaviour, otherwise the old one, and fix the boards where this trouble were found. Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. With my best regards, Dmitry. -- 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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
Dmitri Belimov wrote: Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. OK, I will do. For the first phase and as a bug fix I will do that (disable i2c-gate) like dtv5100 driver does. After that I will add new configuration switch for i2c-gate disable and also change .no_tuner name to better one. regards Antti -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. This sounds like a codec interface as 'described' here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC It would be a first for V4L2 to have a driver that can do this, but I agree that that would be a single device that has both 'output' and 'capture'. Ok. Although this work most probably will be left for future at this point. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? Oh dear. Please don't use 'use counts'. It is perfectly acceptable and desirable to have multiple opens on the same video node. Only one file Use counts are really bad and totally unnecessary. Only if another file handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it make sense to return -EBUSY for certain ioctls or read/write operations. Otherwise you shouldn't limit the user from opening the same device node as many times as he wants and use that to query the video device. ? Having a use count doesn't prevent multiple file handles nor otherwise artificially limit functionality. We need to be able to shut down the slaves when they are no longer needed. IMO having an use count to do this is fine (unless otherwise proven). Yes, it is fine for such purposes. As long as it isn't abused to restrict functionality on subsequent opens. Several drivers use it for that, and that is NOT right. But it's OK for powersaving implementations. I should have mentioned that. Also the camera driver does try_module_get() to the slaves when it's opened by the first user. module_put() is called on those when the last user goes away. This is to allow those modules to be unloaded? We'd also like to get rid of the current way of directly telling the slaves what their power state should be. Rather we'd like to tell the slaves what's expected from them. This could translate to open/release/streamon/streamoff commands. To be able to do this, the use count is required --- unless this task is given to the slaves (v4l2_subdevs). Sounds interesting. I would have to see a proposal or proof-of-concept code to determine how useful it is. It's however better to do this after the v4l2-subdev conversion. BTW, I looked at omap24xxcam_open(): data like fh-pix does *not* belong to the filehandle struct, it should be part of the top-level data structure. That's fixed in the omap34xxcam.c. :) Yay! You want to be able to do simple things like querying a video node for the currently selected format. You can't do that if the format is stored in the filehandle! E.g.: you are streaming and you want to run v4l2-ctl --get-fmt-video to check what video format is being used. Things like this must be supported by a well-written v4l2 driver. Again, sadly quite a few v4l2 drivers do this wrong as well :-( I also see that cam-users is not decreased by one if omap24xxcam_sensor_enable() fails. Note that I'm looking at the code in the v4l-dvb repository, the linux-omap git tree might have fixed that already. I'm afraid it's still there. Will fix that. OK. Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: get rid of video_decoder.h
I've got several of these: w9968cf, usbvideo, cpia_usb, stv680 (I think) and ov511. Once converted one, the other conversions will probably be easy. maybe Jean-Francois or another gspca-submaintainer could convert one of the webcam drivers you have. Then, you can test (and fix). After this changeset, the conversion for the others will likely be trivial. I'd be happy to test and fix if someone else can do the initial conversion to gspca. I have neither the gspca experience nor the time to do that part myself. A few capture drivers: linux/drivers/media/video/zoran/zoran_driver.c linux/drivers/media/video/stradis.c linux/drivers/media/video/pms.c And two i2c helper drivers: linux/drivers/media/video/msp3400-driver.c linux/drivers/media/video/tuner-core.c Most of the above are the legacy V4L1 webcam drivers. It would be really nice if someone could volunteer to port those Webcam drivers to gspca. I suspect that it shouldn't hard to remove the few V4L1 bits from zoran_driver, after all the conversions made. Yet, there are some Zoran specific ioctls that use this. We should probably discontinue those zoran-specific ioctls. I didn't dare do that when I did the conversion. Someone would have to analyze these BUZ ioctls, but I think they all have proper v4l2 equivalents. The only BUZ_foo that requires may require some work are the BUZIOC_G_PARAMS/BUZIOC_S_PARAMS, since it has some controls to the MJPEG stream. I'm not sure if everything is implemented. There are some BUZ_ ioctls that are similar to V4L2 (REQBUFS, QBUF). I don't see why we need yet another set of mmap methods here. The BUZIOC_SYNC doesn't make much sense to my eyes, except if you're stopping a stream. In this case, VIDIOC_STREAMOFF should already provide a sync functionality. The last one BUZIOC_G_STATUS is a merge of some other status already existent on V4L2. The only detail here is that the Zoran mmap methods provide two modes: QBUF_PLAY and QBUF_CAPT. We should take some care to understand the logic behind this. It seems also safe to remove V4L1 code from msp3400, since, AFAIK, all drivers that supports it are already converted to V4L2. I didn't realize that there was still some V4L1 code in that driver. It can certainly be removed. Ok. Maybe you could provide us an strip patch for those legacy code. Otherwise, I'll handle that later. I'll added it to my v4l-dvb tree that contains all the other miscellaneous set of patches from me. It would be nice if that could be pulled soon since it fixes a lot of daily build breakages. After converting stradis, it will be probably safe also to remove V4L1 code from tuner-core. I doubt that there are still some pms hardware around, but it would be interesting to keep this module, since this is the first V4L driver wrote. I have one! I managed to get one for $4 (+$16 shipping :-) ). It actually works (sort of) and I want to convert it to v4l2, just as a fun project. Yes, this seems a very interesting fun project ;) Yup! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Not able to view HD-TV via Technisat Skystar HD 2
Goga777 schrieb: since 3 days I have a Technisat Skystar HD 2 in my Computer (PCI-card) was my mail some days ago. My fault: I installed the multiproto-driver, cause I read this: Mantis/S2API driver This is the preferred driver. DVB-S2 support in the Linux kernel is provided by API version 5.0, also known as S2API (and not multiproto). This API was released in kernel version 2.6.28 please try http://mercurial.intuxication.org/hg/s2-liplianin s2api drivers please read the below part, that was, what I did ... So I thought, I can only use this driver, if I use a kernel 2.6.28 which I do not and so I installed the multiproto-driver with part-success. But I read further and further and found out, that I was wrong. So yesterday I installed the S2API-driver with some more success. Channel-switching is very fast now and scan-s2 finds the hd-channels. I can even zap to a hd-channel, but viewing is the problem: szap-output to a normal channel: szap-s2 -a 0 -H -r -S 0 -n 373 zapping to 373 'NDR FS NDS;ARD': delivery DVB-S, modulation QPSK sat 0, frequency 12109 MHz H, symbolrate 2750, coderate 3/4, rolloff 0.35 vpid 0x0a29, apid 0x0a2a, sid 0x0a2c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK status 1f | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK (and so on) mplayer-output for this channel: please try to use another demuxer with mplayer from svn mplayer -demuxer lavf The output of mplayer with this option: Playing /dev/dvb/adapter0/dvr0. libavformat file format detected. [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]non-existing PPS referenced [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]non-existing PPS referenced [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]non-existing PPS referenced [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]B picture before any references, skipping [h264 @ 0x13d2370]decode_slice_header error [h264 @ 0x13d2370]no frame! [h264 @ 0x13d2370]number of reference frames exceeds max (probably corrupt input), discarding one [lavf] Audio stream found, -aid 0 [lavf] Video stream found, -vid 1 VIDEO: [H264] 1280x720 0bpp 50.000 fps0.0 kbps ( 0.0 kbyte/s) == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000-192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [oss] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... [h264 @ 0xc5df60]B picture before any references, skipping [h264 @ 0xc5df60]decode_slice_header error [h264 @ 0xc5df60]no frame! Error while decoding frame! [h264 @ 0xc5df60]B picture before any references, skipping [h264 @ 0xc5df60]decode_slice_header error [h264 @ 0xc5df60]no frame! Error while decoding frame! [h264 @ 0xc5df60]warning: first frame is no keyframe [h264 @ 0xc5df60]Missing reference picture VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1280x720 = 1280x720 Planar YV12 [h264 @ 0xc5df60]error while decoding MB 10 9, bytestream (-18)% 39 0 [h264 @ 0xc5df60]concealing 2919 DC, 2919 AC, 2919 MV errors A:15563.2 V:15564.4 A-V: -1.191 ct: -0.306 0/ 0 86% 20% 0.4% 39 0 Exiting... (End of file) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo
Re: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
Antti Palosaari wrote: Dmitri Belimov wrote: Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. OK, I will do. For the first phase and as a bug fix I will do that (disable i2c-gate) like dtv5100 driver does. After that I will add new configuration switch for i2c-gate disable and also change .no_tuner name to better one. Here it is, please review and test. I kept changes as small as possible to prevent errors. Lets fix more later. http://linuxtv.org/hg/~anttip/zl10353/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/31] video: Auto-load videodev module when device opened.
The videodev module is missing the char-major-81-* alias that would cause it to be auto-loaded when a device of that type is opened. This patch adds the alias. Signed-off-by: Scott James Remnant sc...@canonical.com Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/v4l2-dev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 13f87c2..7de7e9a 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -582,6 +582,7 @@ module_exit(videodev_exit) MODULE_AUTHOR(Alan Cox, Mauro Carvalho Chehab mche...@infradead.org); MODULE_DESCRIPTION(Device registrar for Video4Linux drivers v2); MODULE_LICENSE(GPL); +MODULE_ALIAS_CHARDEV_MAJOR(VIDEO_MAJOR); /* -- 1.6.0.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 spec
Devin Heitmueller schrieb: On Mon, Mar 9, 2009 at 6:03 PM, wk handygewinnsp...@gmx.de wrote: Its a bad idea to expect someone else, the magic volunteer, doing work with *deep impact* on the dvb driver API structure or documentation. Working on this topic determines complete usability of the driver, so MAIN DEVELOPERS have to REVIEW and CONTRIBUTE. If they think, that they cannot do such work in parallel, they should to stop work on drivers for some time. Cut me a $25,000 check and I'll happily do it. Otherwise, don't tell a bunch of volunteer developers how they should be spending their time. What you happen to think is the important is not necessarily what developers feel is the most valuable use of their time. Devin, during your work on drivers you use a lot of tools and applications, most probably a lot of them beeing open-source. Did YOU spend 25000usd for each of the developers of that tools which documentation you was using? Hopefully - after such a comment. Documentation is part of development. -Winfried -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] flexcop-pci: Print a message in case the new stream watchdog detects a problem
Hi Patrick!
I am happy using the new software watchdog added to flexcop-pci driver, but I
do not get any log message. So I added one. The message now uses deb_info, I
hope this is appropriate.
Regards
Matthias
flexcop-pci: Print a message in case the new stream watchdog detects a problem
Print a message in case the new software IRQ watchdog detects a problem.
I choose the info message category, this can be changed if not appropriate.
Signed-off-by: Matthias Schwarzott z...@gentoo.org
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-pci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop-pci.c
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-pci.c
@@ -133,6 +133,7 @@ static void flexcop_pci_irq_check_work(s
deb_chk(no IRQ since the last check\n);
if (fc_pci-stream_problem++ == 3) {
struct dvb_demux_feed *feed;
+deb_info(flexcop-pci: stream problem, resetting pid filter\n);
spin_lock_irq(fc-demux.lock);
list_for_each_entry(feed, fc-demux.feed_list,
Re: [PATCH 21/31] video: Auto-load videodev module when device opened.
On Montag, 2. März 2009, Scott James Remnant wrote: Hi Scott! The videodev module is missing the char-major-81-* alias that would cause it to be auto-loaded when a device of that type is opened. This patch adds the alias. The patch looks fine, but if videodev is not yet loaded, will loading videodev get any devices registered? For that to happen normally some pci video bridge adapter driver is needed, and that registers at videodev module. Without modprobe.conf tricks this still is not loaded then. Regards Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pxa_camera: Remove YUV planar formats hole
On Mon, 9 Mar 2009, Robert Jarzmik wrote: Ok, this one will change I presume - new alignment calculations and line-breaking. In fact, if you adjust width and height earlier in set_fmt, maybe you'll just remove any rounding here completely. Helas, not fully. The problem is with passthrough and rgb formats, where I don't enforce width/height. In the newest form of the patch I have this : if (pcdev-channels == 3) *size = icd-width * icd-height * 2; else *size = roundup(icd-width * icd-height * ((icd-current_fmt-depth + 7) 3), 8); If icd-current_fmt-depth could be set to 16 for planar formats, then you could get rid of the special case here. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 spec
On Mon, 9 Mar 2009, Hans Verkuil wrote: On Monday 09 March 2009 12:08:39 Mauro Carvalho Chehab wrote: On Fri, 6 Mar 2009, wk wrote: Hans Verkuil wrote: Hi Mauro, I noticed that there is an ancient V4L2 spec in our tree in the v4l/API directory. Is that spec used in any way? I don't think so, so I suggest that it is removed. OK. The V4L1 spec that is there should probably be moved to the v4l2-spec directory as that is where people would look for it. We can just keep it there for reference. Nah. Let's just strip and point to some place where V4L1 doc is available, adding some warning that the API is outdated and will be removed from kernel soon. I don't think we should remove the doc from the repo until all drivers are converted to v4l2. I think it would be useful to keep around. Consider someone trying to convert some old app or driver from v4l1 to v4l2. It would be useful for them to have the spec for v4l1 to know what the software was trying to do. You could just point somewhere else, but things move, and that's another link that will need to be kept up to date. And there could be updates to it, like common ways that v4l1 apps violate the spec that you need to deal with when converting to v4l2. -- 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: S4 hang with uvcvideo causing Unlink after no-IRQ? Controller is probably using the wrong IRQ.
On 12:43 Sun 08 Mar 2009, Alan Stern wrote: On Sat, 7 Mar 2009, Brandon Philips wrote: Have you tried suspending just the two devices plugged into that EHCI controller instead of suspending the entire system? That would make it a lot easier to carry out testing. I tried to reproduce with s2ram suspend, echo suspend /sys/bus/usb/devices/.../power/level and /sys/power/pm_test levels but none of them reproduced it. So, at this point the only way I can reproduce this is with a full S4. That's a little misleading. Sorry, what I meant by full was `echo disk /sys/power/state` with none in /sys/power/pm_test Unless I misunderstood your log, the hang occurred _before_ your system entered S4. In fact, it occurred before the memory image was written out to the disk. Yes, this is correct. It freezes before the image is written. Is there some other method I missed of testing? How about echo disk /sys/power/state with various settings in /sys/power/disk? First observation: I can't reproduce this bug with console=ttyS0,115200 console=tty0. Everything works great actually. Is writing to the serial port causing just enough delay to hide the bug? /sys/power/disk tests - testproc# OK test# Unlink after no-IRQ? ... platform# Unlink after no-IRQ? ... reboot # Unlink after no-IRQ? ... shutdown# Unlink after no-IRQ? ... Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-notify
On Mon, 9 Mar 2009, Mauro Carvalho Chehab wrote: On Mon, 9 Mar 2009 08:45:42 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Monday 09 March 2009 02:20:19 Trent Piepho wrote: On Sun, 8 Mar 2009, Hans Verkuil wrote: - zoran/bt819: use new notify functionality. You put compat.h in the wrong spot in this patch. It goes before any header file that are in v4l-dvb, but you've moved it to after v4l2-common. That's not what README.patches says: There are several compatibility procedures already defined in compat.h file. If needed, it is better to include it after all other kernel standard headers, and before any specific header for that file. Something like: The docs are wrong then. I'm the one who came up with the current system for placing compat.h, I think I know how I designed it. It should come after files that come from the kernel source (i.e., header files that are from the old kernel) and before any headers that are in v4l-dvb hg (i.e., headers that are the same no matter what kernel). This way we can take a type like struct delayed_work and use a #define to change that into struct work_struct when compiling on a kernel where the structure still had that name. Since all v4l-dvb code, even headers like media/v4l-common.h, will use the current struct delayed_work, compat.h must come before them for the #define to fix the struct name. We also use this for the common problem of a function gaining or losing an argument. If the macro comes before the funtion is defined in the header from the kernel source then it would mess the function prototype up. should be included at the files under v4l-dvb tree. This header also includes linux/version.h. I changed the build system long ago to include version.h via a gcc command line option. This way you can stick a kernel version compat ifdef anywhere in the file, for instance not including mutex.h was a common thing at the beginning of files when we had compat for pre-mutex kernels, and not have to worry about putting version.h or compat.h before the ifdef. -- 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 utilize DVB Network API
Hello All, The documentation leaves the Network section of the API as To be written... I've looked at the header file, and it may be straightforward to call, but... Does anyone know how to properly invoke this part of the API? Is it correct to assume that the point of the network API is to create a virtual network interface that I can treat like any other NIC (unidirectional, of course)? My goal is to receive multicast packets using a Skystar 2 DVB-S card (rev 2.6), using standard multicast join and UDP receive calls. The dvb_net_if structure has the following fields: __u16 pid; // This is obvious __u16 if_num; // Don't know exactly what goes here??? __u8 feedtype; // This is either 0 (MPE) or 1 (ULE) For example, does the following code snippet the proper way to go about this? struct dbv_net_if dni; int sd; dni.pid = 3022; // My MPEG2 PID dni.if_num = 0; // ??? dni.feedtype = DVB_NET_FEEDTYPE_MPE; sd = open(/dev/dvb/adapter0/net0, O_RDONLY); ioctl(sd, NET_ADD_IF, dni); Now, do I read packets from /dev/dvb/adapter0/net0 using my sd descriptor? Or do I at this point open a standard UDP socket and start listening for packets from the satellite interface? Any help in clearing my basic confusion would be much appreciated. Thank-you! Bob -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Tue, 10 Mar 2009, Hans Verkuil wrote: On Tuesday 10 March 2009 00:50:41 Mauro Carvalho Chehab wrote: On Mon, 9 Mar 2009 08:16:53 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Monday 09 March 2009 02:07:33 Trent Piepho wrote: On Sun, 8 Mar 2009, Hans Verkuil wrote: The last one fixes an ivtv regression caused by this change: changeset: 10811:0a0eba8e64d5 user:Trent Piepho xy...@speakeasy.org date:Tue Mar 03 20:21:02 2009 -0800 summary: videodev: only copy needed part of RW ioctl's parameter The fix is simple: switch on the full ioctl command instead of just the NR field. Thanks to Martin Dauskardt for doing the bisect and tracing the breakage to this change. Switching on the whole ioctl makes the switch statement a lot less efficient. I'd rather just put a if (_IOC_TYPE(cmd) != 'V') return 0; in there. That should fix the non-v4l2 ioctls, right? That was my first thought as well, but I realized that this is one area where you really do not want to take any risk. IMO, it is better to use Trent's way, and reduce the number of places that do memset(0). Personally I think this code is overoptimization. In my view the performance advantage is minimal while reducing the readability of the code. In general, it is a good idea to avoid copying a data that won't be used from userspace. I liked the optimizations done. Let's just fix what's broken and test a lot to avoid causing a kernel regression. I strongly suspect that the extra function call and tests involved takes longer than the initial copy_from_user and memset. Perhaps with the exception of G_FMT, which is really the only one that has a non-trivial amount of data to copy. None of the commands involved are high-performance commands (well, we haven't any of those anyway), nor is a tight inner-loop involved. I'll see if I can run some benchmarks, but I remain convinced that this change has no benefit. If you bothered to read my commit messages and look at the diff stat, you'd see that this really wasn't about saving a few cycles. That's just a nice extra bonus. Code that was scattered thoughout the tree to clear struct fields was replaced with *less* code that is all in one place. It's not a more complicated solution, it's a simpler one. What's more, duplicating struct clearing over and over leads to bugs. For instance, there were two ioctls that were broken because important fields passed from userspace were mistakenly cleared before the driver got them. I mentioned that in my commit message. There are also many many places where drivers did not clear fields that they should have, leaving whatever garbage was in there. Now all those problems are fixed and driver authors don't have to worry about clearing fields and which fields they should clear. -- 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: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: get rid of video_decoder.h
On Tue, 10 Mar 2009, Hans Verkuil wrote: On Tue, 10 Mar 2009 08:31:32 +0100 I suspect that it shouldn't hard to remove the few V4L1 bits from zoran_driver, after all the conversions made. Yet, there are some Zoran specific ioctls that use this. We should probably discontinue those zoran-specific ioctls. I didn't dare do that when I did the conversion. Someone would have to analyze these BUZ ioctls, but I think they all have proper v4l2 equivalents. The real difficulty there will probably be converting the zoran software like lavplay/lavrec to use new ioctls. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Mon, 9 Mar 2009, Andy Walls wrote: On Mon, 2009-03-09 at 08:16 +0100, Hans Verkuil wrote: On Monday 09 March 2009 02:07:33 Trent Piepho wrote: Switching on the whole ioctl makes the switch statement a lot less efficient. I'd rather just put a if (_IOC_TYPE(cmd) != 'V') return 0; in there. That should fix the non-v4l2 ioctls, right? That was my first thought as well, but I realized that this is one area where you really do not want to take any risk. Personally I think this code is overoptimization. In my view the performance advantage is minimal while reducing the readability of the code. On x86_64, I counted 3 bytes per switch case saved. For the 22 switch cases: a total of 66 bytes saved. If compiled code size reduction is the efficiency measure, I suspect there are probably lower hanging fruit to be picked. True, it's no big gain. On x86-32 it's 4 bytes per case, but adding in the if(_IOC_TYPE... code ends up eating most of the savings, for a net savings of 16 bytes total. I suppose using the full cmd does have an advantage if any of the v4l2 ioctls ever get a new version with a different struct size but the same NR value. Or if this code gets used for any non-'V' ioctls. So Mauro, please go ahead can take Hans' patch, but could you merge it at git, so there is no broken window between the two? -- 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] Add support for Terratec Cinergy HT PCI MKII
Hi,
the attachment contains a patch that adds support for Terratec Cinergy HT PCI
mkII. As this is my first patch here please be gentle ;-P If there is something
wrong I'll try to fix it.
Best regards
Stephan Wienczny
# HG changeset patch
# User Stephan Wienczny step...@wienczny.de
# Date 1236712323 -3600
# Node ID 6846c359324b1229061b94926d15e3e4395a36d3
# Parent f7f2fb8805ebfdab6d62c5f0af7c71e7164ef555
Adding support for Terratec Cinergy HT PCI mkII
From: Stephan Wienczny step...@wienczny.de
This patch adds support for Terratec Cinergy HT PCI MKII with card id 79.
Its more or less a copy of Pinnacle Hybrid PCTV.
Thanks to k1ngf1sher on forum.ubuntuusers.de for the idea to copy that card.
Priority: normal
Signed-off-by: Stephan Wienczny step...@wienczny.de
diff -r f7f2fb8805eb -r 6846c359324b
linux/Documentation/video4linux/CARDLIST.cx88
--- a/linux/Documentation/video4linux/CARDLIST.cx88 Tue Mar 10 05:31:34
2009 -0300
+++ b/linux/Documentation/video4linux/CARDLIST.cx88 Tue Mar 10 20:12:03
2009 +0100
@@ -77,3 +77,4 @@
76 - SATTRADE ST4200 DVB-S/S2[b200:4200]
77 - TBS 8910 DVB-S [8910:]
78 - Prof 6200 DVB-S [b022:3022]
+ 79 - Terratec Cinergy HT PCI MKII[153b:1177]
diff -r f7f2fb8805eb -r 6846c359324b linux/drivers/media/video/cx88/cx88-cards.c
--- a/linux/drivers/media/video/cx88/cx88-cards.c Tue Mar 10 05:31:34
2009 -0300
+++ b/linux/drivers/media/video/cx88/cx88-cards.c Tue Mar 10 20:12:03
2009 +0100
@@ -1967,6 +1967,39 @@
} },
.mpeg = CX88_MPEG_DVB,
},
+ [CX88_BOARD_TERRATEC_CINERGY_HT_PCI_MKII] = {
+ .name = Terratec Cinergy HT PCI MKII,
+ .tuner_type = TUNER_XC2028,
+ .tuner_addr = 0x61,
+ .radio_type = TUNER_XC2028,
+ .radio_addr = 0x61,
+ .input = { {
+ .type = CX88_VMUX_TELEVISION,
+ .vmux = 0,
+ .gpio0 = 0x004ff,
+ .gpio1 = 0x010ff,
+ .gpio2 = 0x1,
+ }, {
+ .type = CX88_VMUX_COMPOSITE1,
+ .vmux = 1,
+ .gpio0 = 0x004fb,
+ .gpio1 = 0x010ef,
+ .audioroute = 1,
+ }, {
+ .type = CX88_VMUX_SVIDEO,
+ .vmux = 2,
+ .gpio0 = 0x004fb,
+ .gpio1 = 0x010ef,
+ .audioroute = 1,
+ } },
+ .radio = {
+ .type = CX88_RADIO,
+ .gpio0 = 0x004ff,
+ .gpio1 = 0x010ff,
+ .gpio2 = 0x0ff,
+ },
+ .mpeg = CX88_MPEG_DVB,
+ },
};
/* -- */
@@ -2376,6 +2409,10 @@
.subvendor = 0xb200,
.subdevice = 0x4200,
.card = CX88_BOARD_SATTRADE_ST4200,
+ }, {
+ .subvendor = 0x153b,
+ .subdevice = 0x1177,
+ .card = CX88_BOARD_TERRATEC_CINERGY_HT_PCI_MKII,
},
};
@@ -2852,6 +2889,7 @@
*/
break;
case CX88_BOARD_PINNACLE_HYBRID_PCTV:
+ case CX88_BOARD_TERRATEC_CINERGY_HT_PCI_MKII:
ctl-demod = XC3028_FE_ZARLINK456;
ctl-mts = 1;
break;
diff -r f7f2fb8805eb -r 6846c359324b linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 10 05:31:34 2009 -0300
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 10 20:12:03 2009 +0100
@@ -240,6 +240,12 @@
static struct mt352_config dvico_fusionhdtv_dual = {
.demod_address = 0x0f,
.demod_init= dvico_dual_demod_init,
+};
+
+static struct zl10353_config cx88_terratec_cinergy_ht_pci_mkii_config = {
+ .demod_address = (0x1e 1),
+ .no_tuner = 1,
+ .if2 = 45600,
};
#if defined(CONFIG_VIDEO_CX88_VP3054) ||
(defined(CONFIG_VIDEO_CX88_VP3054_MODULE) defined(MODULE))
@@ -1138,6 +1144,16 @@
if (fe0-dvb.frontend != NULL)
fe0-dvb.frontend-ops.set_voltage =
tevii_dvbs_set_voltage;
break;
+ case CX88_BOARD_TERRATEC_CINERGY_HT_PCI_MKII:
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+
cx88_terratec_cinergy_ht_pci_mkii_config,
+ core-i2c_adap);
+ if (fe0-dvb.frontend) {
+ fe0-dvb.frontend-ops.i2c_gate_ctrl = NULL;
+ if (attach_xc3028(0x61, dev) 0)
+
A question about documentation.
Recently, I submitted a driver for the SQ905C cameras, for which I (partly
due to being new to kernel video support) did not provide any update to
Documentation/video4linux/gspca.txt.
I have not heard what has happened to the driver. I assume that what is
going on is there is a race condition about getting things into 2.6.29,
and there is not time to do a proper evaluation. While I am curious about
the actual problem, though, that is not my question here.
Someone pointed out to me that I probably should have updated the
aforementioned doc file. So I do have a question about that.
Here is the way that gspca.txt looks now (excerpt follows):
List of the webcams known by gspca.
The modules are:
gspca_main main driver
gspca_ subdriver module with as follows
vend:prod
spca501 : MystFromOri Unknow Camera
m5602 0402:5602 ALi Video Camera Controller
spca501 040a:0002 Kodak DVC-325
spca500 040a:0300 Kodak EZ200
(and so on)
Well, now comes the question. I notice that each line in the file
corresponds to a USB Vendor:Product ID, and each line corresponds to one
camera, by brand name and model. Apparently, there is some blessed
universe in which I have not been living the last few years, in which
there is such a one-to-one correspondence.
Below, I give the list of supported cameras. extracted from
libgphoto2/camlibs/digigr8. which as far as I am able to know is
supporting precisely the same set of cameras as does the module sq905c.c
My question is obvious: Which of them do I list? All of them? A sampling
of them? Or what?
Theodore Kilgore
(list follows)
static const struct {
char *name;
CameraDriverStatus status;
unsigned short idVendor;
unsigned short idProduct;
} models[] = {
{Digigr8, 0x2770, 0x905c},
{Che-Ez Snap SNAP-U,0x2770, 0x905c},
{DC-N130t, 0x2770, 0x905C},
{Soundstar TDC-35, 0x2770, 0x905c},
{Nexxtech Mini Digital Camera, 0x2770, 0x905c},
{Vivitar Vivicam35, 0x2770, 0x905c},
{Praktica Slimpix, 0x2770, 0x905c},
{ZINA Mini Digital Keychain Camera, 0x2770, 0x905c},
{Pixie Princess Jelly-Soft, 0x2770, 0x905c},
{Sakar Micro Digital 2428x, 0x2770, 0x905c},
{Jazz JDC9, 0x2770, 0x905c},
{Disney pix micro, 0x2770, 0x9050},
{Suprema Digital Keychain Camera, 0x2770, 0x913d},
{Sakar 28290 and 28292 Digital Concepts Styleshot,
0x2770, 0x913d},
{Sakar 23070 Crayola Digital Camera, 0x2770, 0x913d},
{Sakar 92045 Spiderman,0x2770, 0x913d},
{NULL,0,0,0}
};
As I said, which one(s) of these to list?
--
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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
Hi Antti Antti Palosaari wrote: Dmitri Belimov wrote: Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. OK, I will do. For the first phase and as a bug fix I will do that (disable i2c-gate) like dtv5100 driver does. After that I will add new configuration switch for i2c-gate disable and also change .no_tuner name to better one. Here it is, please review and test. I kept changes as small as possible to prevent errors. Lets fix more later. http://linuxtv.org/hg/~anttip/zl10353/ Looks good. Tomorrow I make some tests and write my results. With my best regards, Dmitry. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[pull] http://linuxtv.org/hg/~tap/v4l-dvb-zoran
Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb-zoran for the following 6 changesets: 01/06: build: Clean up FM801-TEA575x Kconfig http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=a9792eb3e828 02/06: zoran: Unify buffer descriptors http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=41592ce6cba3 03/06: zoran: Drop the lock_norm module parameter http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=da9f9c766f07 04/06: zoran: Don't frighten users with failed buffer allocation http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=f0a275bde923 05/06: zoran: Pass zoran_fh pointers instead of file pointers http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=9eb7b94aa6b6 06/06: zoran: replace functions names in strings with __func__ http://linuxtv.org/hg/~tap/v4l-dvb-zoran?cmd=changeset;node=60b0989f6c7a linux/Documentation/video4linux/Zoran |3 linux/drivers/media/video/zoran/zoran.h| 59 - linux/drivers/media/video/zoran/zoran_card.c | 115 -- linux/drivers/media/video/zoran/zoran_device.c | 20 linux/drivers/media/video/zoran/zoran_device.h |2 linux/drivers/media/video/zoran/zoran_driver.c | 1357 ++--- v4l/Kconfig.sound |9 7 files changed, 669 insertions(+), 896 deletions(-) Thanks, Trent -- 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
