Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Success! I've tracked down the offending change. switch_addr takes on the wrong value and setting the LNA fails. Here's a i2c dump: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c xfer: 20 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 84 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 86 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 94 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 saa7133[0]: i2c xfer: 96 00 saa7133[0]: i2c xfer: 97 =01 =01 =00 =11 =01 =04 =01 =85 saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b tuner' 1-004b: tda829x detected tuner' 1-004b: Setting mode_mask to 0x0e tuner' 1-004b: chip found @ 0x96 (saa7133[0]) tuner' 1-004b: tuner 0x4b: Tuner type absent tuner' i2c attach [addr=0x4b,client=(tuner unset)] tuner' 1-004b: Calling set_type_addr for type=54, addr=0xff, mode=0x04, config=0x01 tuner' 1-004b: set addr for type -1 tuner' 1-004b: defining GPIO callback saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b saa7133[0]: i2c xfer: 96 2f saa7133[0]: i2c xfer: 97 =00 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c1 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c3 =88 saa7133[0]: i2c xfer: c5 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c7 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: setting tuner address to 61 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c3 =08 tda827x: tda827x_attach: tda827x: type set to Philips TDA827X saa7133[0]: i2c xfer: c3 =08 tda827x: tda827xa tuner found tda827x: tda827x_init: tda827x: tda827xa_sleep: saa7133[0]: i2c xfer: c2 30 90 saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: type set to tda8290+75a saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c2 00 00 00 00 dc 05 8b 0c 04 20 ff 00 00 4b saa7133[0]: i2c xfer: 96 21 00 saa7133[0]: i2c xfer: 96 20 01 saa7133[0]: i2c xfer: 96 30 6f tuner' 1-004b: type set to tda8290+75a tuner' 1-004b: tv freq set to 400.00 tda829x 1-004b: setting tda829x to system xx tda829x 1-004b: tda827xa config is 0x01 saa7133[0]: i2c xfer: 96 01 00 saa7133[0]: i2c xfer: 96 02 00 saa7133[0]: i2c xfer: 96 00 00 saa7133[0]: i2c xfer: 96 01 90 saa7133[0]: i2c xfer: 96 28 14 saa7133[0]: i2c xfer: 96 0f 88 saa7133[0]: i2c xfer: 96 05 04 saa7133[0]: i2c xfer: 96 0d 47 saa7133[0]: i2c xfer: 96 21 c0 tda827x: setting tda827x to system xx tda827x: setting LNA to high gain saa7133[0]: i2c xfer: 96 22 00 ^ This address is c2 in all kernels = 5823b3a63c7661272ea7fef7635955e2a50d17eb saa7133[0]: i2c xfer: c2 00 32 f8 00 16 3b bb 1c 04 20 00 saa7133[0]: i2c xfer: c2 90 ff e0 00 99 saa7133[0]: i2c xfer: c2 a0 c0 saa7133[0]: i2c xfer: c2 30 10 saa7133[0]: i2c xfer: c3 =49 =a4 tda827x: AGC2 gain is: 10 ^ The gain reported on good kernels is 3 Looking at the source, the switch_addr to use in the later kernels is somehow autodetected. How that's done, I've yet to fully understand, but somehow it comes up with the wrong address. This patch (which obviously needs improvement) hardwires the address back to its original value, and works for 2.6.30-rc5. diff --git a/drivers/media/common/tuners/tda8290.c b/drivers/media/common/tuners/tda8290.c index 064d14c..498cc7b 100644 --- a/drivers/media/common/tuners/tda8290.c +++ b/drivers/media/common/tuners/tda8290.c @@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe) dvb_attach(tda827x_attach, fe, priv-tda827x_addr, priv-i2c_props.adap, priv-cfg); + tuner_info(ANDERS: setting switch_addr. was 0x%02x, new 0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr); priv-cfg.switch_addr = priv-i2c_props.addr; + priv-cfg.switch_addr = 0xc2 / 2; + tuner_info(ANDERS: new 0x%02x\n,priv-cfg.switch_addr); + } if (fe-ops.tuner_ops.init) fe-ops.tuner_ops.init(fe); Could you please help me out and shed some light on what the proper fix is for setting switch_addr? Thanks, /Anders -- 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: twinhan cards
I have here more detailed output from dst module: [9.070205] dst(0) dst_comm_init: Initializing DST. [9.070273] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [9.072332] dst(0) rdc_reset_state: Resetting state machine [9.072385] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [9.090204] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [9.221629] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [9.222959] dst(0) read_dst: reply is 0xff [9.242137] dst(0) dst_wait_dst_ready: dst wait ready after 1 [9.243786] dst(0) read_dst: reply is 0x0 [9.243873] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [9.244941] dst(0) dst_get_device_id: Recognise [DSTMCI] [9.244996] dst(0) dst_comm_init: Initializing DST. [9.245049] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [9.247111] dst(0) rdc_reset_state: Resetting state machine [9.247165] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [9.260174] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [9.281994] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [9.283344] dst(0) read_dst: reply is 0xff [9.300254] dst(0) dst_wait_dst_ready: dst wait ready after 1 [9.302051] dst(0) read_dst: reply is 0x0 [9.302136] debug_dst_buffer: [ 00 04 00 00 00 00 00 fc] [9.302147] dst(0) dst_get_device_id: Unsupported [9.302202] dst(0) dst_comm_init: Initializing DST. [9.302257] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [9.304324] dst(0) rdc_reset_state: Resetting state machine [9.304378] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [9.320185] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [9.341707] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [9.343064] dst(0) read_dst: reply is 0xff [ 13.350788] dst(0) dst_wait_dst_ready: dst wait NOT ready after 200 [ 13.350869] dst(0) dst_check_mb86a15: Cmd=[0x10], failed [ 13.350924] dst(0) dst_get_device_id: Unsupported [ 13.350981] dst(0) dst_type_print: DST type: satellite [ 13.351045] dst(0) dst_comm_init: Initializing DST. [ 13.351101] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [ 13.353169] dst(0) rdc_reset_state: Resetting state machine [ 13.353225] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [ 13.372739] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [ 13.400080] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [ 13.401456] dst(0) read_dst: reply is 0xff [ 13.403521] dst(0) dst_wait_dst_ready: dst wait ready after 0 [ 13.412580] dst(0) read_dst: reply is 0x0 [ 13.412664] dst(0) dst_get_mac: MAC Address=[cd8d73ec] [ 13.412719] dst(0) dst_get_tuner_info: DST TYpe = MULTI FE [ 13.412775] dst(0) dst_comm_init: Initializing DST. [ 13.412830] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [ 13.414896] dst(0) rdc_reset_state: Resetting state machine [ 13.414952] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [ 13.430089] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [ 13.453302] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [ 13.454627] dst(0) read_dst: reply is 0xff [ 13.456681] dst(0) dst_wait_dst_ready: dst wait ready after 0 [ 13.457939] dst(0) read_dst: reply is 0x0 [ 13.458005] dst(0) dst_comm_init: Initializing DST. [ 13.458059] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [ 13.460123] dst(0) rdc_reset_state: Resetting state machine [ 13.460180] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [ 13.480089] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [ 13.509163] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [ 13.510474] dst(0) read_dst: reply is 0xff [ 17.520072] dst(0) dst_wait_dst_ready: dst wait NOT ready after 200 [ 17.520155] dst(0) dst_fw_ver: Unsupported Command [ 17.520208] dst(0) dst_probe: FW: Unsupported command [ 17.556338] dst_ca_attach: registering DST-CA device [ 17.660165] dst(1) dst_comm_init: Initializing DST. [ 17.660239] dst(1) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [ 17.662307] dst(1) rdc_reset_state: Resetting state machine [ 17.662368] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [ 17.680055] dst(1) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [ 17.811404] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [ 17.812736] dst(1) read_dst: reply is 0xff [ 17.830046] dst(1) dst_wait_dst_ready: dst wait ready after 1 [ 17.831425] dst(1) read_dst: reply is 0x0 [ 17.831488] dst(1) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [ 17.832551] dst(1) dst_get_device_id: Recognise [DSTMCI] [
RE: v4l-dvb rev 11757 broke building under Ubuntu Hardy
Andy,
Thanks for the patch. Please see my response below.
-Original Message-
From: Andy Walls [mailto:awa...@radix.net]
Sent: Friday, May 15, 2009 5:24 AM
To: david.w...@gatech.edu
Cc: Chaithrika U S; linux-media@vger.kernel.org
Subject: Re: v4l-dvb rev 11757 broke building under Ubuntu Hardy
David Ward wrote:
I am using v4l-dvb in order to add the cx18 driver under Ubuntu Hardy
(8.04).
The build is currently broken under Hardy, which uses kernel 2.6.24.
I
have traced the origin of the problem to revision 11757. As seen in
the latest cron job output, the build produces the error when trying
to compile adv7343.c:
/usr/local/src/v4l-dvb/v4l/adv7343.c:506: error: array type has
incomplete element type
/usr/local/src/v4l-dvb/v4l/adv7343.c:518: warning: initialization
from incompatible pointer type
/usr/local/src/v4l-dvb/v4l/adv7343.c:520: error: unknown field
'id_table' specified in initializer
Thanks for resolving this.
David Ward
David,
Please try the patch below.
Chaithrika,
Please review (and test if it is OK) the patch below. It modifies
adv7343.c to what the cs5345.c file does for backward compatability.
It adds some checks against kernel version, which would not go into the
actual kernel, and changes some code to use the v4l2 i2c module
template
from v4l2-i2c-drv.h, which *would* go into the actual kenrel.
Regards,
Andy
Signed-off-by: Andy Walls awa...@radix.net
diff -r 0018ed9bbca3 linux/drivers/media/video/adv7343.c
--- a/linux/drivers/media/video/adv7343.c Tue May 12 16:13:13 2009
+
+++ b/linux/drivers/media/video/adv7343.c Thu May 14 19:51:10 2009 -
0400
@@ -29,6 +29,8 @@
#include media/adv7343.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+#include compat.h
#include adv7343_regs.h
@@ -503,6 +505,7 @@
return 0;
}
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
static const struct i2c_device_id adv7343_id[] = {
{adv7343, 0},
{},
@@ -510,25 +513,12 @@
MODULE_DEVICE_TABLE(i2c, adv7343_id);
-static struct i2c_driver adv7343_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = adv7343,
- },
+#endif
+static struct v4l2_i2c_driver_data v4l2_i2c_data = {
+ .name = adv7343,
.probe = adv7343_probe,
.remove = adv7343_remove,
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
.id_table = adv7343_id,
+#endif
};
-
-static __init int init_adv7343(void)
-{
- return i2c_add_driver(adv7343_driver);
-}
-
-static __exit void exit_adv7343(void)
-{
- i2c_del_driver(adv7343_driver);
-}
-
-module_init(init_adv7343);
-module_exit(exit_adv7343);
During my initial implementations, I did follow the v4l2_i2c_driver_data
procedure.
But after the review comment I got, I changed it. Please refer to the link
below.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg02973.html
Was wondering if this is related to kernel version and is there a
possibility that in the
above patch, the module init and exit functions can be included in kernel
version checks
instead of removing them altogether.
Regards,
Chaithrika
--
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
V4L2 - Capturing uncompressed data
Hello, I'm a French student and I'm doing an intern ship in a French image processing software company, and I've got some questions about V4L2 and more precisely, the video formats. In the application, I just need to capture frames of webcams and display the result. After research, I found the capture example on the http://v4l2spec.bytesex.org/ website. So now, I capture correctly the frames. During the initialisation of the device, I'm doing a VIDIOC_G_FMT in order to get the format description of the webcam. Then, I tried to change the pixelformat. Indeed, I wanted the YUYV FORMAT because I need to get the raw data in order to get the best quality possible. My problem is, after the VIDIOC_S_FMT, the pixelformat field is set back to JPEG FORMAT (and the colorspace too) and so, I don't get raw data, but compressed jpeg data. I know that the VIDIOC_S_FMT try to change these fields but if the driver don't authorise them, it will put the originals back. But, I really need to get the uncompressed data of the captured picture, so is there by any chance, another solution to 'force' and capture the images in an Uncompressed format ? Or is it really set by the driver and so, no chance to have the raw ? So, in my InitDevice I'm doing that : //Get FMT Clear( mFmt, sizeof( mFmt ) ); mFmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; if ( -1 == Xioctl ( mFd, VIDIOC_G_FMT, mFmt ) ) return false; //Set FMT A LA RESOLUTION CHOISIE :Clear( mFmt, sizeof( mFmt ) ); mFmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; mFmt.fmt.pix.width = iInfo.Width; mFmt.fmt.pix.height = iInfo.Height; //I want to capture raw data in YUYV, no JPEG compressed stuff mFmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; mFmt.fmt.pix.field = V4L2_FIELD_INTERLACED; if ( -1 == Xioctl ( mFd, VIDIOC_S_FMT, mFmt ) ) return false; //JPEG - set yuyv failed printf(%d\n,mFmt.fmt.pix.pixelformat); //JPEG - always jpeg, but i don't want this printf(%d\n,mFmt.fmt.pix.colorspace); To be clear, I want the uncompressed pixels of the capture. I already succeeded in converting from JPEG to BGR, but the data are compressed. So now, I don't want to do that conversion. Actually, I want to save the uncompressed data for quality directly! But I don't know if that is possible because the driver of the webcam (VF0420 Live! Cam Vista IM - ov519) specified only JPEG format when I'm doing a 'V4l-info'. I really looked for answers everywhere on the web, so I'm losing hope and that's why I'm asking you that today. I'm sorry if my comment is misplaced or if the answer has already been posted. Thank you all, Regards. Guillaume. -- 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 - Capturing uncompressed data
Hi Guillaume, On Friday 15 May 2009 15:03:11 Guillaume wrote: Hello, I'm a French student and I'm doing an intern ship in a French image processing software company, and I've got some questions about V4L2 and more precisely, the video formats. In the application, I just need to capture frames of webcams and display the result. After research, I found the capture example on the http://v4l2spec.bytesex.org/ website. So now, I capture correctly the frames. During the initialisation of the device, I'm doing a VIDIOC_G_FMT in order to get the format description of the webcam. Then, I tried to change the pixelformat. Indeed, I wanted the YUYV FORMAT because I need to get the raw data in order to get the best quality possible. My problem is, after the VIDIOC_S_FMT, the pixelformat field is set back to JPEG FORMAT (and the colorspace too) and so, I don't get raw data, but compressed jpeg data. I know that the VIDIOC_S_FMT try to change these fields but if the driver don't authorise them, it will put the originals back. But, I really need to get the uncompressed data of the captured picture, so is there by any chance, another solution to 'force' and capture the images in an Uncompressed format ? Or is it really set by the driver and so, no chance to have the raw ? It depends on the camera. If the camera can deliver uncompressed data, you should be able to get that out of the driver. Otherwise you're stuck. [snip] To be clear, I want the uncompressed pixels of the capture. I already succeeded in converting from JPEG to BGR, but the data are compressed. So now, I don't want to do that conversion. Actually, I want to save the uncompressed data for quality directly! But I don't know if that is possible because the driver of the webcam (VF0420 Live! Cam Vista IM - ov519) specified only JPEG format when I'm doing a 'V4l-info'. That probably means that the camera can't deliver uncompressed data, although you should ask the driver's author to make sure. If the camera indeed supports (M)JPEG only, you will probably have to get another camera. I really looked for answers everywhere on the web, so I'm losing hope and that's why I'm asking you that today.I'm sorry if my comment is misplaced or if the answer has already been posted. This is the right place for such questions, don't worry. Best 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: V4L2 - Capturing uncompressed data
Laurent Pinchart laurent.pinchart at skynet.be writes: It depends on the camera. If the camera can deliver uncompressed data, you should be able to get that out of the driver. Otherwise you're stuck. [snip] Ok, it's what I was afraid of. That probably means that the camera can't deliver uncompressed data, although you should ask the driver's author to make sure. If the camera indeed supports (M)JPEG only, you will probably have to get another camera. I'll tell that to my internship supervisor and I'll be back at you if I have more questions. This is the right place for such questions, don't worry. Best regards, Laurent Pinchart Thank you for the cordial welcome, I didn't know how mailing lists worked. Have a good day ! Guillaume. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7130 unstable video
Hello, I have cheap Chinese noname card with 8 Philips 7130 chips, without eeprom. It's dedicated to CCTV. Has no tv tuner, and I don't need sound. Card looks exacly like http://www.cn-dvr.net/products/enproducts76.html and AOP-8008A from http://www.bttv-gallery.de/ I tried modprobe with all posible (1,154) card types, and tested each with mplayer tv://. Some of them worked a bit but image was unstable and colors were substituted. It's hard to describe in detail so I grabbed a few seconds. Image quality is unacceptable for surveillance purpouse http://bartoszcisek.pl/saa7130-sample1.avi (11MB) http://bartoszcisek.pl/saa7130-sample2.avi (13MB) My first thoughts were that there is a lack synchronisation, because image is shifted and moving. Card producer wrote that it has onboard x264 compression, maybe I use wrong codec for mplayer? I tryed x264 but it made only worse, there was no image at all. I've never done any linux driver coding. Can you please advise me how to start? maybe I don't have to code and it's just a matter of configuration? Below I submit logs from lspci, dmesg and mplayer. Camera is OK as I checked it previously on bt878A card. Thanks in advance for any hints, regards Bartek tower:~# lspci -vnn -s 02:0f.0 02:0f.0 Multimedia controller [0480]: Philips Semiconductors SAA7130 Video Broadcast Decoder [1131:7130] (rev 01) Subsystem: Philips Semiconductors Device [1131:] Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at e2007000 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel modules: saa7134 dmesg: saa7130[7]: found at :02:0f.0, rev: 1, irq: 17, latency: 32, mmio: 0xe2007000 saa7134: rant saa7134: Congratulations! Your TV card vendor saved a few saa7134: cents for a eeprom, thus your pci board has no saa7134: subsystem ID and I can't identify it automatically saa7134: /rant saa7134: I feel better now. Ok, here are the good news: saa7134: You can use the card=nr insmod option to specify saa7134: which board do you have. The list: saa7134: card=0 - UNKNOWN/GENERIC saa7134: card=1 - Proteus Pro [philips reference design] 1131:2001 1131:2001 [here was list of cards] saa7134: card=154 - Avermedia AVerTV GO 007 FM Plus 1461:f31d saa7130[7]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] saa7130[7]: board init: gpio is 18e00 IRQ 17/saa7130[7]: IRQF_DISABLED is not guaranteed on shared IRQs saa7130[7]: Huh, no eeprom present (err=-5)? saa7130[7]: registered device video7 [v4l2] saa7130[7]: registered device vbi7 Mplayer: MPlayer dev-SVN-r26940 CPU: AMD Athlon(tm) XP 3200+ (Family: 6, Model: 10, Stepping: 0) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Compiled with runtime CPU detection. Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: Beholder BeholdTV 403 Tuner cap: STEREO LANG1 LANG2 Tuner rxs: MONO Capabilites: video capture video overlay VBI capture device tuner read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = PAL; 5 = PAL-BG; 6 = PAL-H; 7 = PAL-I; 8 = PAL-DK; 9 = PAL-M; 10 = PAL-N; 11 = PAL-Nc; 12 = PAL-60; 13 = SECAM; 14 = SECAM-B; 15 = SECAM-G; 16 = SECAM-H; 17 = SECAM-DK; 18 = SECAM-L; 19 = SECAM-Lc; inputs: 0 = S-Video; 1 = Composite1; 2 = Television; Current input: 0 Current format: BGR24 v4l2: current audio mode is : MONO open: No such file or directory [MGA] Couldn't open: /dev/mga_vid open: No such file or directory [MGA] Couldn't open: /dev/mga_vid [VO_TDFXFB] This driver only supports the 3Dfx Banshee, Voodoo3 and Voodoo 5. s3fb: 4 bpp output is not supported == Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [xv] 640x480 = 640x480 Planar YV12 [VO_XV] Shared memory not supported Reverting to normal Xv. [VO_XV] Shared memory not supported Reverting to normal Xv. Selected video codec: [rawyv12] vfm: raw (RAW YV12) == Audio: no sound Starting playback... v4l2: 106 frames successfully processed, -105 frames dropped. Exiting... (Quit) -- Bartosz Cisek bartoszcisek [ at ] bartoszcisek.pl -- 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: v4l-dvb rev 11757 broke building under Ubuntu Hardy
On Fri, 2009-05-15 at 18:31 +0530, chaithrika wrote:
Andy,
Thanks for the patch. Please see my response below.
-Original Message-
From: Andy Walls [mailto:awa...@radix.net]
Sent: Friday, May 15, 2009 5:24 AM
To: david.w...@gatech.edu
Cc: Chaithrika U S; linux-media@vger.kernel.org
Subject: Re: v4l-dvb rev 11757 broke building under Ubuntu Hardy
David Ward wrote:
I am using v4l-dvb in order to add the cx18 driver under Ubuntu Hardy
(8.04).
The build is currently broken under Hardy, which uses kernel 2.6.24.
I
have traced the origin of the problem to revision 11757. As seen in
the latest cron job output, the build produces the error when trying
to compile adv7343.c:
/usr/local/src/v4l-dvb/v4l/adv7343.c:506: error: array type has
incomplete element type
/usr/local/src/v4l-dvb/v4l/adv7343.c:518: warning: initialization
from incompatible pointer type
/usr/local/src/v4l-dvb/v4l/adv7343.c:520: error: unknown field
'id_table' specified in initializer
Thanks for resolving this.
David Ward
David,
Please try the patch below.
Chaithrika,
Please review (and test if it is OK) the patch below. It modifies
adv7343.c to what the cs5345.c file does for backward compatability.
It adds some checks against kernel version, which would not go into the
actual kernel, and changes some code to use the v4l2 i2c module
template
from v4l2-i2c-drv.h, which *would* go into the actual kenrel.
Regards,
Andy
Signed-off-by: Andy Walls awa...@radix.net
diff -r 0018ed9bbca3 linux/drivers/media/video/adv7343.c
--- a/linux/drivers/media/video/adv7343.c Tue May 12 16:13:13 2009
+
+++ b/linux/drivers/media/video/adv7343.c Thu May 14 19:51:10 2009 -
0400
@@ -29,6 +29,8 @@
#include media/adv7343.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+#include compat.h
#include adv7343_regs.h
@@ -503,6 +505,7 @@
return 0;
}
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
static const struct i2c_device_id adv7343_id[] = {
{adv7343, 0},
{},
@@ -510,25 +513,12 @@
MODULE_DEVICE_TABLE(i2c, adv7343_id);
-static struct i2c_driver adv7343_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = adv7343,
- },
+#endif
+static struct v4l2_i2c_driver_data v4l2_i2c_data = {
+ .name = adv7343,
.probe = adv7343_probe,
.remove = adv7343_remove,
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
.id_table = adv7343_id,
+#endif
};
-
-static __init int init_adv7343(void)
-{
- return i2c_add_driver(adv7343_driver);
-}
-
-static __exit void exit_adv7343(void)
-{
- i2c_del_driver(adv7343_driver);
-}
-
-module_init(init_adv7343);
-module_exit(exit_adv7343);
During my initial implementations, I did follow the v4l2_i2c_driver_data
procedure.
But after the review comment I got, I changed it. Please refer to the link
below.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg02973.html
Oh, OK. What prompted me to suggest that was the adv7343_probe()
function had the wrong prototype (the incompatible pointer type warning)
for that 2.6.24 kernel. The v4l2_i2c_driver_data method was the easiest
way around it.
Perhaps it would just be easier to add the adv7343 driver to the
[2.6.26] section of v4l/versions.txt and forget about backward
compatibility for this module.
Was wondering if this is related to kernel version and is there a
possibility that in the
above patch, the module init and exit functions can be included in kernel
version checks
instead of removing them altogether.
Well if Hans said v4l2-i2c-drv.h is going away, it's best to avoid
trying to use it.
If you want to provide backward compatibility for kernels older than
2.6.26, then the 2 version checks that I put in are needed. You'll need
to figure out the rest of the i2c structure differences and wrap those
in kernel version checks too.
If you don't want to provide backward compatibility, then you'll need to
add an entry in v4l/versions.txt so that builds on older kernels won't
try to compile the module.
Regards,
Andy
Regards,
Chaithrika
--
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: How to interpret error codes for usb_control_msg()?
On Thu, 14 May 2009, Randy Dunlap wrote: Theodore Kilgore wrote: On Thu, 14 May 2009, Randy Dunlap wrote: snip Anyone have any good and clever ideas? I suggest that you ask on the USB mailing list (linux-...@vger.kernel.org). It occurs to me that the problem may not be in the command but instead in something previous to it. Probably due to inexperience though, unfortunately in my case, not due to youth. I will continue to try to chase it down. Thanks for the help. Theodore Kilgore -- 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 00/10 v2] soc-camera conversions
Hi all, this is the next round of soc-camera conversions. Run-tested on i.MX31, PXA270, SH7722, compile-tested only for i.MX1. It should have been a straight-forward port of the previous version to a more current tree, but then I started converting soc_camera_platform, and things became a bit more complex... As a bonus, now soc-camera can handle not only i2c subdevices, and we can even drop the CONFIG_I2C dependency again. I'll also upload a comlpete stack somewhere a bit later, for example for those, wishing to test it on i.MX31, otherwise the series will not apply cleanly. I'd like to push the first 8 of them asap, 9 and 10 will still have to be reworked Paul, I put you on cc on all patches, because, unfortunately, several of them affect arch/sh. But I'll mention it explicitly in each such patch. Have fun. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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 01/10 v2] soc-camera: prepare soc_camera_platform.c and its users for conversion
soc_camera_platform.c is only used by y SuperH ap325rxa board. This patch
converts soc_camera_platform.c and its users for the soc-camera platform-
device conversion and also extends soc-camera core to handle non-I2C cameras.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Paul, may I pull this one over v4l? These patches only touch video
functionality. Then I would need your ack.
arch/sh/boards/board-ap325rxa.c | 43 ++--
drivers/media/video/soc_camera.c| 61 ++
include/media/soc_camera.h |6 +++
include/media/soc_camera_platform.h |2 +
4 files changed, 86 insertions(+), 26 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index cd1fcc0..0a5f97b 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -304,6 +304,9 @@ static int camera_set_capture(struct
soc_camera_platform_info *info,
return ret;
}
+static int ap325rxa_camera_add(struct soc_camera_link *icl, struct device
*dev);
+static void ap325rxa_camera_del(struct soc_camera_link *icl);
+
static struct soc_camera_platform_info camera_info = {
.iface = 0,
.format_name = UYVY,
@@ -317,6 +320,10 @@ static struct soc_camera_platform_info camera_info = {
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8,
.set_capture = camera_set_capture,
+ .link = {
+ .add_device = ap325rxa_camera_add,
+ .del_device = ap325rxa_camera_del,
+ },
};
static struct platform_device camera_device = {
@@ -326,15 +333,20 @@ static struct platform_device camera_device = {
},
};
-static int __init camera_setup(void)
+static int ap325rxa_camera_add(struct soc_camera_link *icl,
+ struct device *dev)
{
- if (camera_probe() 0)
- platform_device_register(camera_device);
+ if (icl != camera_info.link || camera_probe() = 0)
+ return -ENODEV;
- return 0;
+ return platform_device_register(camera_device);
}
-late_initcall(camera_setup);
+static void ap325rxa_camera_del(struct soc_camera_link *icl)
+{
+ if (icl == camera_info.link)
+ platform_device_unregister(camera_device);
+}
#endif /* CONFIG_I2C */
static int ov7725_power(struct device *dev, int mode)
@@ -414,11 +426,19 @@ static struct ov772x_camera_info ov7725_info = {
},
};
-static struct platform_device ap325rxa_camera = {
- .name = soc-camera-pdrv,
- .id = 0,
- .dev= {
- .platform_data = ov7725_info.link,
+static struct platform_device ap325rxa_camera[] = {
+ {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = ov7725_info.link,
+ },
+ }, {
+ .name = soc-camera-pdrv,
+ .id = 1,
+ .dev= {
+ .platform_data = camera_info.link,
+ },
},
};
@@ -429,7 +449,8 @@ static struct platform_device *ap325rxa_devices[]
__initdata = {
ceu_device,
nand_flash_device,
sdcard_cn3_device,
- ap325rxa_camera,
+ ap325rxa_camera[0],
+ ap325rxa_camera[1],
};
static struct spi_board_info ap325rxa_spi_devices[] = {
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 2014e9e..6fae6c6 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1161,45 +1161,76 @@ void soc_camera_video_stop(struct soc_camera_device
*icd)
}
EXPORT_SYMBOL(soc_camera_video_stop);
-static int __devinit soc_camera_pdrv_probe(struct platform_device *pdev)
+#ifdef CONFIG_I2C_BOARDINFO
+static int soc_camera_init_i2c(struct platform_device *pdev,
+ struct soc_camera_link *icl)
{
- struct soc_camera_link *icl = pdev-dev.platform_data;
- struct i2c_adapter *adap;
struct i2c_client *client;
+ struct i2c_adapter *adap = i2c_get_adapter(icl-i2c_adapter_id);
+ int ret;
- if (!icl)
- return -EINVAL;
-
- adap = i2c_get_adapter(icl-i2c_adapter_id);
if (!adap) {
- dev_warn(pdev-dev, Cannot get adapter #%d. No driver?\n,
-icl-i2c_adapter_id);
- /* -ENODEV and -ENXIO do not produce an error on probe()... */
- return -ENOENT;
+ ret = -ENODEV;
+ dev_err(pdev-dev, Cannot get adapter #%d. No driver?\n,
+ icl-i2c_adapter_id);
+ goto ei2cga;
}
icl-board_info-platform_data = icl;
client = i2c_new_device(adap, icl-board_info);
if (!client) {
- i2c_put_adapter(adap);
- return
[PATCH 02/10 v2] ARM: convert pcm037 to the new platform-device soc-camera interface
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This is actually a completion to the other single patches I've sent
earlier for various boards. As I said, pcm037 doesn't have all its
outstanding patches in next yet, so, you'll need to collect them from
trees / lists, or get them when I upload them.
arch/arm/mach-mx3/pcm037.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-mx3/pcm037.c b/arch/arm/mach-mx3/pcm037.c
index bfa814d..af49f03 100644
--- a/arch/arm/mach-mx3/pcm037.c
+++ b/arch/arm/mach-mx3/pcm037.c
@@ -293,9 +293,18 @@ static int pcm037_camera_power(struct device *dev, int on)
return 0;
}
+static struct i2c_board_info pcm037_i2c_2_devices[] = {
+ {
+ I2C_BOARD_INFO(mt9t031, 0x5d),
+ },
+};
+
static struct soc_camera_link iclink = {
- .bus_id = 0,/* Must match with the camera ID */
- .power = pcm037_camera_power,
+ .bus_id = 0,/* Must match with the camera ID */
+ .power = pcm037_camera_power,
+ .board_info = pcm037_i2c_2_devices[0],
+ .i2c_adapter_id = 2,
+ .module_name= mt9t031,
};
static struct i2c_board_info pcm037_i2c_devices[] = {
@@ -308,9 +317,10 @@ static struct i2c_board_info pcm037_i2c_devices[] = {
}
};
-static struct i2c_board_info pcm037_i2c_2_devices[] = {
- {
- I2C_BOARD_INFO(mt9t031, 0x5d),
+static struct platform_device pcm037_camera = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
.platform_data = iclink,
},
};
@@ -390,6 +400,9 @@ static struct platform_device *devices[] __initdata = {
pcm037_flash,
pcm037_eth,
pcm037_sram_device,
+#if defined(CONFIG_I2C_IMX) || defined(CONFIG_I2C_IMX_MODULE)
+ pcm037_camera,
+#endif
};
static struct ipu_platform_data mx3_ipu_data = {
@@ -447,9 +460,6 @@ static void __init mxc_board_init(void)
i2c_register_board_info(1, pcm037_i2c_devices,
ARRAY_SIZE(pcm037_i2c_devices));
- i2c_register_board_info(2, pcm037_i2c_2_devices,
- ARRAY_SIZE(pcm037_i2c_2_devices));
-
mxc_register_device(mxc_i2c_device1, pcm037_i2c_1_data);
mxc_register_device(mxc_i2c_device2, pcm037_i2c_2_data);
#endif
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10 v2] soc_camera_platform: pass device pointer from soc-camera core on .add_device()
Add a struct device pointer to struct soc_camera_platform_info and let the user
(ap325rxa) pass it down to soc_camera_platform.c in its .add_device() method.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Paul, another mixed one, should be quite easy to review though:-)
arch/sh/boards/board-ap325rxa.c |2 ++
include/media/soc_camera_platform.h |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index 0a5f97b..ac964e4 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -339,6 +339,8 @@ static int ap325rxa_camera_add(struct soc_camera_link *icl,
if (icl != camera_info.link || camera_probe() = 0)
return -ENODEV;
+ camera_info.dev = dev;
+
return platform_device_register(camera_device);
}
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index af224de..3e8f020 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -14,6 +14,8 @@
#include linux/videodev2.h
#include media/soc_camera.h
+struct device;
+
struct soc_camera_platform_info {
int iface;
char *format_name;
@@ -21,6 +23,7 @@ struct soc_camera_platform_info {
struct v4l2_pix_format format;
unsigned long bus_param;
void (*power)(int);
+ struct device *dev;
int (*set_capture)(struct soc_camera_platform_info *info, int enable);
struct soc_camera_link link;
};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10 v2] sh: soc-camera updates
Update ap325rxa to specify .bus_id in struct soc_camera_link explicitly, remove
unused .iface from struct soc_camera_platform_info.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Paul, you certainly could take this one, as well as a couple others, but
maybe easier to push them all together.
arch/sh/boards/board-ap325rxa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index ac964e4..f644ad7 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -308,7 +308,6 @@ static int ap325rxa_camera_add(struct soc_camera_link *icl,
struct device *dev);
static void ap325rxa_camera_del(struct soc_camera_link *icl);
static struct soc_camera_platform_info camera_info = {
- .iface = 0,
.format_name = UYVY,
.format_depth = 16,
.format = {
@@ -321,6 +320,7 @@ static struct soc_camera_platform_info camera_info = {
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8,
.set_capture = camera_set_capture,
.link = {
+ .bus_id = 0,
.add_device = ap325rxa_camera_add,
.del_device = ap325rxa_camera_del,
},
@@ -421,6 +421,7 @@ static struct ov772x_camera_info ov7725_info = {
.flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
.edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
.link = {
+ .bus_id = 0,
.power = ov7725_power,
.board_info = ap325rxa_i2c_camera[0],
.i2c_adapter_id = 0,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10 v2] soc-camera: remove unused .iface from struct soc_camera_platform_info
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/media/soc_camera_platform.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index b144f94..bb70401 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -17,7 +17,6 @@
struct device;
struct soc_camera_platform_info {
- int iface;
const char *format_name;
unsigned long format_depth;
struct v4l2_pix_format format;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10 v2] sh: prepare board-ap325rxa.c for v4l2-subdev conversion
We will be registering and unregistering the soc_camera_platform platform
device multiple times, therefore we need a .release() method and have to
nullify the kobj.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Another one for sh. Again have to synchronise.
arch/sh/boards/board-ap325rxa.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/sh/boards/board-ap325rxa.c b/arch/sh/boards/board-ap325rxa.c
index f644ad7..9329fe5 100644
--- a/arch/sh/boards/board-ap325rxa.c
+++ b/arch/sh/boards/board-ap325rxa.c
@@ -323,13 +323,19 @@ static struct soc_camera_platform_info camera_info = {
.bus_id = 0,
.add_device = ap325rxa_camera_add,
.del_device = ap325rxa_camera_del,
+ .module_name= soc_camera_platform,
},
};
+static void dummy_release(struct device *dev)
+{
+}
+
static struct platform_device camera_device = {
.name = soc_camera_platform,
.dev= {
.platform_data = camera_info,
+ .release= dummy_release,
},
};
@@ -346,8 +352,11 @@ static int ap325rxa_camera_add(struct soc_camera_link *icl,
static void ap325rxa_camera_del(struct soc_camera_link *icl)
{
- if (icl == camera_info.link)
- platform_device_unregister(camera_device);
+ if (icl != camera_info.link)
+ return;
+
+ platform_device_unregister(camera_device);
+ memset(migor_camera_device.dev.kobj, 0,
sizeof(migor_camera_device.dev.kobj));
}
#endif /* CONFIG_I2C */
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10 v2] v4l2-subdev: add a v4l2_i2c_subdev_board() function
Introduce a function similar to v4l2_i2c_new_subdev() but taking a pointer to a
struct i2c_board_info as a parameter instead of a client type and an I2C
address, and make v4l2_i2c_new_subdev() a wrapper around it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hans, renamed as you requested and updated to a (more) current state.
drivers/media/video/v4l2-common.c | 30 +++---
include/media/v4l2-common.h |5 +
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index f576ef6..ab190aa 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -758,30 +758,38 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct
i2c_client *client,
}
EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
-
-
/* Load an i2c sub-device. */
struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr)
{
- struct v4l2_subdev *sd = NULL;
- struct i2c_client *client;
struct i2c_board_info info;
- BUG_ON(!v4l2_dev);
-
- if (module_name)
- request_module(module_name);
-
/* Setup the i2c board info with the device type and
the device address. */
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ return v4l2_i2c_subdev_board(v4l2_dev, adapter, module_name, info);
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+
+/* Load an i2c sub-device using provided struct i2c_board_info. */
+struct v4l2_subdev *v4l2_i2c_subdev_board(struct v4l2_device *v4l2_dev,
+ struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+
+ BUG_ON(!v4l2_dev);
+
+ if (module_name)
+ request_module(module_name);
+
/* Create the i2c client */
- client = i2c_new_device(adapter, info);
+ client = i2c_new_device(adapter, info);
/* Note: it is possible in the future that
c-driver is NULL if the driver is still being loaded.
We need better support from the kernel so that we
@@ -808,7 +816,7 @@ error:
i2c_unregister_device(client);
return sd;
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_board);
/* Probe and load an i2c sub-device. */
struct v4l2_subdev *v4l2_i2c_new_probed_subdev(struct v4l2_device *v4l2_dev,
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index c48c24e..a67f5c3 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -131,6 +131,7 @@ struct i2c_driver;
struct i2c_adapter;
struct i2c_client;
struct i2c_device_id;
+struct i2c_board_info;
struct v4l2_device;
struct v4l2_subdev;
struct v4l2_subdev_ops;
@@ -142,6 +143,10 @@ struct v4l2_subdev_ops;
struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/* Same as above but uses user-provided struct i2c_board_info */
+struct v4l2_subdev *v4l2_i2c_subdev_board(struct v4l2_device *v4l2_dev,
+ struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info);
/* Probe and load an i2c module and return an initialized v4l2_subdev struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the adapter. */
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/10 v2] v4l2-subdev: re-add s_standby to v4l2_subdev_core_ops
NOT FOR SUBMISSION. Probably, another solution has to be found. soc-camera
drivers need an .init() (marked as don't use) and a .halt() methods.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hans, you moved s_standby to tuner_ops, and init is not recommended for
new drivers. Suggestions?
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..ba907be 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -97,6 +97,7 @@ struct v4l2_subdev_core_ops {
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident
*chip);
int (*log_status)(struct v4l2_subdev *sd);
int (*init)(struct v4l2_subdev *sd, u32 val);
+ int (*s_standby)(struct v4l2_subdev *sd, u32 standby);
int (*load_fw)(struct v4l2_subdev *sd);
int (*reset)(struct v4l2_subdev *sd, u32 val);
int (*s_gpio)(struct v4l2_subdev *sd, u32 val);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10 v2] soc-camera conversions
On Fri, 15 May 2009, Guennadi Liakhovetski wrote: Hi all, this is the next round of soc-camera conversions. Run-tested on i.MX31, PXA270, SH7722, compile-tested only for i.MX1. It should have been a straight-forward port of the previous version to a more current tree, but then I started converting soc_camera_platform, and things became a bit more complex... As a bonus, now soc-camera can handle not only i2c subdevices, and we can even drop the CONFIG_I2C dependency again. I'll also upload a comlpete stack somewhere a bit later, for example for those, wishing to test it on i.MX31, otherwise the series will not apply cleanly. All available at http://download.open-technology.de/soc-camera/20090515/ As you can see from -base it is still based on next of 20090507, i.e., 9 days ago:-( If you take a newer tree, some of those patches will already be there, so, I think, the easiest would be to base your tests on the same base. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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: s2255drv: adding V4L2_MODE_HIGHQUALITY
From: Dean Anderson d...@sensoray.com
Adding V4L2_MODE_HIGHQUALITY feature.
Signed-off-by: Dean Anderson d...@sensoray.com
--- v4l-dvb-0018ed9bbca3/linux/drivers/media/video/s2255drv.c.orig
2009-05-15 10:15:36.0 -0700
+++ v4l-dvb-0018ed9bbca3/linux/drivers/media/video/s2255drv.c 2009-05-15
10:20:43.0 -0700
@@ -110,6 +110,8 @@
#define SCALE_4CIFS1 /* 640x480(NTSC) or 704x576(PAL) */
#define SCALE_2CIFS2 /* 640x240(NTSC) or 704x288(PAL) */
#define SCALE_1CIFS3 /* 320x240(NTSC) or 352x288(PAL) */
+/* SCALE_4CIFSI is the 2 fields interpolated into one */
+#define SCALE_4CIFSI 4 /* 640x480(NTSC) or 704x576(PAL) high quality */
#define COLOR_YUVPL1 /* YUV planar */
#define COLOR_YUVPK2 /* YUV packed */
@@ -239,6 +241,8 @@
struct s2255_mode mode[MAX_CHANNELS];
/* jpeg compression */
struct v4l2_jpegcompression jc[MAX_CHANNELS];
+ /* capture parameters (for high quality mode full size) */
+ struct v4l2_captureparm cap_parm[MAX_CHANNELS];
const struct s2255_fmt *cur_fmt[MAX_CHANNELS];
int cur_frame[MAX_CHANNELS];
int last_frame[MAX_CHANNELS];
@@ -1021,9 +1025,16 @@
fh-type = f-type;
norm = norm_minw(fh-dev-vdev[fh-channel]);
if (fh-width norm_minw(fh-dev-vdev[fh-channel])) {
- if (fh-height norm_minh(fh-dev-vdev[fh-channel]))
- fh-mode.scale = SCALE_4CIFS;
- else
+ if (fh-height norm_minh(fh-dev-vdev[fh-channel])) {
+ if (fh-dev-cap_parm[fh-channel].capturemode
+ V4L2_MODE_HIGHQUALITY) {
+ fh-mode.scale = SCALE_4CIFSI;
+ dprintk(2, scale 4CIFSI\n);
+ } else {
+ fh-mode.scale = SCALE_4CIFS;
+ dprintk(2, scale 4CIFS\n);
+ }
+ } else
fh-mode.scale = SCALE_2CIFS;
} else {
@@ -1124,6 +1135,7 @@
if (mode-format == FORMAT_NTSC) {
switch (mode-scale) {
case SCALE_4CIFS:
+ case SCALE_4CIFSI:
linesPerFrame = NUM_LINES_4CIFS_NTSC * 2;
pixelsPerLine = LINE_SZ_4CIFS_NTSC;
break;
@@ -1141,6 +1153,7 @@
} else if (mode-format == FORMAT_PAL) {
switch (mode-scale) {
case SCALE_4CIFS:
+ case SCALE_4CIFSI:
linesPerFrame = NUM_LINES_4CIFS_PAL * 2;
pixelsPerLine = LINE_SZ_4CIFS_PAL;
break;
@@ -1496,6 +1509,33 @@
dprintk(2, setting jpeg quality %d\n, jc-quality);
return 0;
}
+
+static int vidioc_g_parm(struct file *file, void *priv,
+struct v4l2_streamparm *sp)
+{
+ struct s2255_fh *fh = priv;
+ struct s2255_dev *dev = fh-dev;
+ if (sp-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ sp-parm.capture.capturemode = dev-cap_parm[fh-channel].capturemode;
+ dprintk(2, getting parm %d\n, sp-parm.capture.capturemode);
+ return 0;
+}
+
+static int vidioc_s_parm(struct file *file, void *priv,
+struct v4l2_streamparm *sp)
+{
+ struct s2255_fh *fh = priv;
+ struct s2255_dev *dev = fh-dev;
+
+ if (sp-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ dev-cap_parm[fh-channel].capturemode = sp-parm.capture.capturemode;
+ dprintk(2, setting param capture mode %d\n,
+ sp-parm.capture.capturemode);
+ return 0;
+}
static int s2255_open(struct file *file)
{
int minor = video_devdata(file)-minor;
@@ -1787,6 +1827,8 @@
#endif
.vidioc_s_jpegcomp = vidioc_s_jpegcomp,
.vidioc_g_jpegcomp = vidioc_g_jpegcomp,
+ .vidioc_s_parm = vidioc_s_parm,
+ .vidioc_g_parm = vidioc_g_parm,
};
static struct video_device template = {
--
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
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:Fri May 15 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11783:0018ed9bbca3 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc4-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc4-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc4-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc4-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc4-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc4-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc4-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc4-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc4): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
log of em28xx based KWorld DVB-T310U as requested by driver
Hello, here is the dmesg for the USB tv stick I purchased as Kworld/V-Stream DVB-T310U DVB-T/Analog-Tuner,USB Stick. It indeed seems to be from KWorld according to its labelling :-) Picture works in tvtime. No sound. arecord -l lists no audio capture device other than my audio chips. V4L2 used is v4l-dvb-83712d149893. Markus Rechberger got sound to work back in Ubuntu 8.04 days with a vanilla kernel I compiled. I used his driver though. The card= options needs to be 48. It gets autodetected to 49. Perhaps a typo somewhere. Using 48 I get the dmesg I attach below the first. The only difference seems to be the registering of the dvb-t interface. Ubuntu 9.04 autoloads the driver. Where would I have to insert the card=48 option (twice it may appear from the dmesg)? Do you have help on getting analog sound to work here? [ 10.951996] em28xx: New device USB 2881 Device @ 480 Mbps (eb1a:e310, interface 0, class 0) [ 10.952019] em28xx #0: Identified as MSI DigiVox A/D (card=49) [ 10.952213] em28xx #0: chip ID is em2882/em2883 [ 11.019577] ath_hal: module license 'Proprietary' taints kernel. [ 11.021383] AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) [ 11.120218] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 10 e3 d0 12 5c 03 6a 22 00 00 [ 11.120227] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 07 00 00 00 00 00 00 00 00 00 00 [ 11.120233] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 01 00 00 00 00 00 5b 1e 00 00 [ 11.120239] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 11.120245] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120251] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120257] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 11.120262] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 44 00 [ 11.120268] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 11.120274] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120280] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120286] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120292] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120297] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120303] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120309] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.120316] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x166a0441 [ 11.120318] em28xx #0: EEPROM info: [ 11.120319] em28xx #0: AC97 audio (5 sample rates) [ 11.120321] em28xx #0: 500mA max power [ 11.120322] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 11.126494] em28xx #0: found i2c device @ 0x1e [???] [ 11.167853] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 11.173598] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [ 11.175476] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 11.187855] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 11.187859] em28xx #0: You may try to use card=n insmod option to workaround that. [ 11.187861] em28xx #0: Please send an email with this log to: [ 11.187862] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 11.187864] em28xx #0: Board eeprom hash is 0x166a0441 [ 11.187866] em28xx #0: Board i2c devicelist hash is 0x944d008f [ 11.187867] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 11.187869] em28xx #0: card=0 - Unknown EM2800 video grabber [ 11.187871] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 11.187873] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 11.187875] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 11.187877] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 11.187878] em28xx #0: card=5 - MSI VOX USB 2.0 [ 11.187880] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 11.187882] em28xx #0: card=7 - Leadtek Winfast USB II [ 11.187883] em28xx #0: card=8 - Kworld USB2800 [ 11.187885] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 11.187887] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 11.187889] em28xx #0: card=11 - Terratec Hybrid XS [ 11.187891] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 11.187893] em28xx #0: card=13 - Terratec Prodigy XS [ 11.187894] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 11.187896] em28xx #0: card=15 - V-Gear PocketTV [ 11.187898] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 11.187900] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 11.187901] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 11.187903] em28xx #0: card=19 - PointNix Intra-Oral Camera [ 11.187905] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [ 11.187907] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video
[PATCH 0/9] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446 These patches add support for VPFE (Video Processing Front End) based video capture on DM355 and DM6446 EVMs. For more details on the hardware configuration and capabilities, please refer the vpfe_capture.c header. This patch set consists of following:- Patch 1: VPFE Capture bridge driver Patch 2: CCDC hw device header file Patch 3: DM355 CCDC hw module Patch 4: DM644x CCDC hw module Patch 5: common types used across CCDC modules Patch 6: Makefile and config files for the driver Patch 7: DM355 platform and board setup Patch 8: DM644x platform and board setup Patch 9: Remove outdated driver files from davinci git tree The initial version of this driver was reviewed by reviewers mentioned below. Following are the Major comments incorporated into the driver based on this :- 1) Restructure the files into following:- vpfe_capture.[ch] - bridge driver ccdc_types.h - types used across ccdc modules vpfe_types.h - types used across vpfe specific drivers dm644x_ccdc.[ch] - ccdc module for DM644x dm644x_ccdc_regs.h - register defines for DM644x dm355_ccdc.[ch] - ccdc module for DM355 dm355_ccdc_regs.h - register defines for DM644x 2) Simplify data structures for vpfe capture driver (avoid structure based on multiple channels) 3) Cleanup device registration and initialization 4) Video buffer handling issues In addition to this, the driver is ported to the new sub device model. Tested the driver using the tvp5146 decoder (version migrated to sub device model by Vaibhav Hiremath and is being reviewed currently on the list). So this patch depends on the above driver. NOTE: Dependent on the TVP514x decoder driver patch for migrating the driver to sub device model from Vaibhav Hiremath Following tests are performed. 1) Capture and display video (PAL NTSC) from tvp5146 decoder. Displayed using fbdev device driver available on davinci git tree 2) Tested with driver built statically and dynamically Muralidhara Karicheri Reviewed By Hans Verkuil. Reviewed By Laurent Pinchart. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.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
[PATCH 2/9] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
This has comments incorporated from previous review.
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/davinci/ccdc_hw_device.h | 109
1 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 include/media/davinci/ccdc_hw_device.h
diff --git a/include/media/davinci/ccdc_hw_device.h
b/include/media/davinci/ccdc_hw_device.h
new file mode 100644
index 000..71904f3
--- /dev/null
+++ b/include/media/davinci/ccdc_hw_device.h
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include linux/videodev2.h
+#include linux/device.h
+#include media/davinci/vpfe_types.h
+#include media/davinci/ccdc_types.h
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* set vpss base address */
+ void (*set_vpss_base)(void *base, int size);
+ void (*enable) (int en);
+ /* Pointer to function to enable or disable ccdc */
+ void (*reset) (void);
+ /* reset sbl. only for 6446 */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw frame type */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*setparams) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*getparams) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(enum vpfe_hw_pix_format *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* Pointer to function to set buffer type */
+ enum vpfe_hw_pix_format (*get_pixelformat) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixelformat) (enum vpfe_hw_pix_format pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query SoC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set SoC control */
+ int (*setcontrol)(struct v4l2_control *ctrl);
+ /* Get SoC control */
+ int (*getcontrol)(struct v4l2_control *ctrl);
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[30];
+ /* module owner */
+ struct module *owner;
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct
[PATCH 4/9] dm644x ccdc module for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM644x CCDC hw module
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE
This has the comments incorporated from the previous review
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm644x_ccdc.c | 1018
drivers/media/video/davinci/dm644x_ccdc_regs.h | 140
include/media/davinci/dm644x_ccdc.h| 206 +
3 files changed, 1364 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
create mode 100644 include/media/davinci/dm644x_ccdc.h
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..24a358f
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,1018 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ * Split module parameter structure to module specific ioctl structs
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include asm/page.h
+#include media/davinci/ccdc_hw_device.h
+#include media/davinci/dm644x_ccdc.h
+#include dm644x_ccdc_regs.h
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .image_invert_enable = 0,
+ .data_sz = _10BITS,
+ .alaw = {
+ .b_alaw_enable = 0
+ },
+ .blk_clamp = {
+ .b_clamp_enable = 0,
+ .dc_sub = 0
+ },
+ .blk_comp = {0, 0, 0, 0},
+ .fault_pxl = {
+ .fpc_enable = 0
+ },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_BAYER_FORMATS 2
+#define CCDC_MAX_RAW_YUV_FORMATS 2
+
+/* Raw Bayer formats */
+static enum vpfe_hw_pix_format
+ ccdc_raw_bayer_hw_formats[CCDC_MAX_RAW_BAYER_FORMATS] =
+ {VPFE_BAYER_8BIT_PACK_ALAW, VPFE_BAYER};
+
+/* Raw YUV formats */
+static enum vpfe_hw_pix_format
+ ccdc_raw_yuv_hw_formats[CCDC_MAX_RAW_YUV_FORMATS] =
+ {VPFE_UYVY, VPFE_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static void *__iomem vpss_base_addr;
+static int vpss_addr_size;
+static struct ccdc_config_params_raw ccdc_hw_params_raw_temp;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+ if (offset = ccdc_addr_size)
+ return __raw_readl(ccdc_base_addr +
[PATCH 5/9] ccdc types used across ccdc modules for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
common types used across CCDC modules
This has the common types used by all ccdc hw modules
This has the comments incorporated from the previous review
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/davinci/ccdc_types.h | 43
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 include/media/davinci/ccdc_types.h
diff --git a/include/media/davinci/ccdc_types.h
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+ CCDC_PIXFMT_RAW,
+ CCDC_PIXFMT_YCBCR_16BIT,
+ CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+ CCDC_FRMFMT_PROGRESSIVE,
+ CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode */
+enum ccdc_pixorder {
+ CCDC_PIXORDER_YCBYCR,
+ CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+ CCDC_BUFTYPE_FLD_INTERLEAVED,
+ CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] DM355 platform changes for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM355 platform and board setup
This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.
This has comments incorporated from previous review.
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm355-evm.c| 72 ++-
arch/arm/mach-davinci/dm355.c | 65 +
arch/arm/mach-davinci/include/mach/dm355.h |2 +
arch/arm/mach-davinci/include/mach/mux.h |9
4 files changed, 145 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index f32e3d8..3a3f5e0 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
#include linux/io.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/videodev2.h
+#include media/tvp514x.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
@@ -134,12 +136,23 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+#define TVP5146_I2C_ADDR 0x5D
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
- { I2C_BOARD_INFO(dm355evm_msp, 0x25),
+ { I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
- /* plus irq */ },
+ },
+ {
+ I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+ .platform_data = tvp5146_pdata,
+ },
+ /* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
- /* { I2C_BOARD_INFO(tvp5146, 0x5d), }, */
};
static void __init evm_init_i2c(void)
@@ -178,6 +191,57 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = (struct v4l2_input *)tvp5146_inputs,
+ .routes = (struct v4l2_routing *)tvp5146_routes,
+ .can_route = 1,
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM355 EVM,
+ .ccdc = DM355 CCDC,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -189,6 +253,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index bccc5a8..9d80496 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355, INT_EDMA_TC1_ERR, 4,1,1,
false)
EVT_CFG(DM355, EVT8_ASP1_TX,0,1,0, false)
EVT_CFG(DM355, EVT9_ASP1_RX,1,1,0, false)
EVT_CFG(DM355, EVT26_MMC0_RX, 2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK, 0, 14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0, 13,1,1, false)
+MUX_CFG(DM355, VIN_CAM_VD, 0, 12,1,1, false)
+MUX_CFG(DM355, VIN_CAM_HD, 0, 11,1,1, false)
+MUX_CFG(DM355, VIN_YIN_EN, 0, 10,1,1, false)
+MUX_CFG(DM355, VIN_CINL_EN,0, 0, 0xff, 0x55,false)
+MUX_CFG(DM355, VIN_CINH_EN,0, 8, 3,3, false)
#endif
};
@@ -604,6 +612,47 @@ static struct platform_device dm355_edma_device = {
[PATCH 8/9] DM6446 platform changes for vpfe capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM644x platform and board setup
This adds plarform and board setup changes required to support
vpfe capture driver on DM644x
This has comments incorporated from previous review.
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm644x-evm.c| 68 ++-
arch/arm/mach-davinci/dm644x.c | 42
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
3 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index e97216c..c419dad 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
#include linux/io.h
#include linux/phy.h
#include linux/clk.h
-
+#include linux/videodev2.h
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
@@ -195,6 +196,57 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = (struct v4l2_input *)tvp5146_inputs,
+ .routes = (struct v4l2_routing *)tvp5146_routes,
+ .can_route = 1,
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM6446 EVM,
+ .ccdc = DM6446 CCDC,
+};
+
static struct platform_device rtc_dev = {
.name = rtc_davinci_evm,
.id = -1,
@@ -446,6 +498,13 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+#define TVP5146_I2C_ADDR (0x5D)
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
/*
* MSP430 supports RTC, card detection, input from IR remote, and
* a bit more. It triggers interrupts on GPIO(7) from pressing
@@ -557,9 +616,12 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO(24c256, 0x50),
.platform_data = eeprom_info,
},
+ {
+ I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+ .platform_data = tvp5146_pdata,
+ },
/* ALSO:
* - tvl320aic33 audio codec (0x1b)
-* - tvp5146 video decoder (0x5d)
*/
};
@@ -590,6 +652,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init
davinci_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm644x_set_vpfe_config(vpfe_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 45abac4..c58ca9c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -530,6 +530,46 @@ static struct platform_device dm644x_edma_device = {
.resource = edma_resources,
};
+static struct resource vpfe_resources[] = {
+ {
+ .start = IRQ_VDINT0,
+ .end= IRQ_VDINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = IRQ_VDINT1,
+ .end= IRQ_VDINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01c70400,
+ .end= 0x01c70400 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 0x01c73400,
+ .end= 0x01c73400 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 vpfe_capture_dma_mask =
[PATCH 9/9] remove outdated video driver files of dm6446
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
Remove outdated driver files from davinci git tree
This has comments incorporated from previous review.
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
drivers/media/video/ccdc_davinci.c | 124
drivers/media/video/davinci_vpfe.c | 1136
include/media/ccdc_davinci.h | 144 -
include/media/davinci_vpfe.h | 121
4 files changed, 0 insertions(+), 1525 deletions(-)
delete mode 100644 drivers/media/video/ccdc_davinci.c
delete mode 100644 drivers/media/video/davinci_vpfe.c
delete mode 100644 include/media/ccdc_davinci.h
delete mode 100644 include/media/davinci_vpfe.h
diff --git a/drivers/media/video/ccdc_davinci.c
b/drivers/media/video/ccdc_davinci.c
deleted file mode 100644
index d3cd333..000
--- a/drivers/media/video/ccdc_davinci.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- *
- *
- * Copyright (C) 2006 Texas Instruments Inc
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-/* ccdc_davinci.c */
-
-#include media/ccdc_davinci.h
-#define debug_print(x...) //printk(x)
-void ccdc_reset()
-{
- int i;
- /* disable CCDC */
- ccdc_enable(0);
- /* set all registers to default value */
- for (i = 0; i = 0x94; i += 4) {
- regw(0, i);
- }
- regw(0, PCR);
- regw(0, SYN_MODE);
- regw(0, HD_VD_WID);
- regw(0, PIX_LINES);
- regw(0, HORZ_INFO);
- regw(0, VERT_START);
- regw(0, VERT_LINES);
- regw(0x00ff, CULLING);
- regw(0, HSIZE_OFF);
- regw(0, SDOFST);
- regw(0, SDR_ADDR);
- regw(0, VDINT);
- regw(0, REC656IF);
- regw(0, CCDCFG);
- regw(0, FMTCFG);
- regw(0, VP_OUT);
-}
-
-void ccdc_setwin(ccdc_params_ycbcr * params)
-{
- int horz_start, horz_nr_pixels;
- int vert_start, vert_nr_lines;
-
- /* configure horizonal and vertical starts and sizes */
- horz_start = params-win.left 1;
- horz_nr_pixels = (params-win.width 1) - 1;
- regw((horz_start 16) | horz_nr_pixels, HORZ_INFO);
-
- vert_start = params-win.top;
-
- if (params-frm_fmt == CCDC_FRMFMT_INTERLACED) {
- vert_nr_lines = (params-win.height 1) - 1;
- vert_start = 1;
- } else {
- vert_nr_lines = params-win.height - 1;
- }
- regw((vert_start 16) | vert_start, VERT_START);
- regw(vert_nr_lines, VERT_LINES);
-}
-
-void ccdc_config_ycbcr(ccdc_params_ycbcr * params)
-{
- u32 syn_mode;
-
- /* first reset the CCDC */
- /* all registers have default values after reset */
- /* This is important since we assume default values to be set in */
- /* a lot of registers that we didn't touch */
- ccdc_reset();
-
- /* configure pixel format */
- syn_mode = (params-pix_fmt 0x3) 12;
-
- /* configure video frame format */
- syn_mode |= (params-frm_fmt 0x1) 7;
-
- /* setup BT.656 sync mode */
- if (params-bt656_enable) {
- regw(3, REC656IF);
-
- /* configure the FID, VD, HD pin polarity */
- /* fld,hd pol positive, vd negative, 8-bit pack mode */
- syn_mode |= 0x0F04;
- } else {/* y/c external sync mode */
- syn_mode |= ((params-fid_pol 0x1) 4);
- syn_mode |= ((params-hd_pol 0x1) 3);
- syn_mode |= ((params-vd_pol 0x1) 2);
- }
-
- /* configure video window */
- ccdc_setwin(params);
-
- /* configure the order of y cb cr in SD-RAM */
- regw((params-pix_order 11) | 0x8000, CCDCFG);
-
- /* configure the horizontal line offset */
- /* this is done by rounding up width to a multiple of 16 pixels */
- /* and multiply by two to account for y:cb:cr 4:2:2 data */
- regw(((params-win.width * 2) + 31) 0xffe0, HSIZE_OFF);
-
- /* configure the memory line offset */
- if (params-buf_type == CCDC_BUFTYPE_FLD_INTERLEAVED) {
- /* two fields are interleaved in memory */
-
Re: V4L2 - Capturing uncompressed data
On Fri, 15 May 2009, Laurent Pinchart wrote: Hi Guillaume, On Friday 15 May 2009 15:03:11 Guillaume wrote: [snip] My problem is, after the VIDIOC_S_FMT, the pixelformat field is set back to JPEG FORMAT (and the colorspace too) and so, I don't get raw data, but compressed jpeg data. I know that the VIDIOC_S_FMT try to change these fields but if the driver don't authorise them, it will put the originals back. But, I really need to get the uncompressed data of the captured picture, so is there by any chance, another solution to 'force' and capture the images in an Uncompressed format ? Or is it really set by the driver and so, no chance to have the raw ? It depends on the camera. ...and the driver. I don't know much about various _web_cameras and their drivers, but I could well imagine, that you're asking for an unsupported YUV variation, whereas some other format would be supported. Why don't you use VIDIOC_ENUM_FMT to list all supported formats? Or even look in the driver source - it's open:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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
Re: [linux-dvb] Hauppauge WinTV-CI
Is Wintv-CI, the Common Interface from Hauppauge, working on linux now ? not Goga -- 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
Preliminary results with an SN9C2028 camera
I decided recently to work on support for the SN9C2028 dual-mode cameras, which are supported as still cameras in libgphoto2/camlibs/sonix. Today, I succeeded in getting three frames out of one of them, using svv -gr, and I was able to convert two of the three frames to nice images using the same decompression algorithm which is used for the cameras in stillcam mode. There is a lot of work to do yet: support for all appropriate resolution settings (which are what? I do not yet know), support for all known cameras for which I can chase down an owner, and incorporation of the decompression code in libv4l. However, I thought you might like to know that some success has been achieved. As regards all known cameras I have tried unsuccessfully to contact the owner of a Genius Smart 300. It is sold in Europe, not over here, and the only person I know who had one has not answered my request for further information. I suspect the reason for that is his old e-mail is no longer valid; he was a student from Armenia studying in Switzerland and may have gone home now. So, I ask the question of the list. Does anyone know an owner of a Genius Smart 300 and can get for me a USB snoop of it starting up to do streaming? Theodore Kilgore -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi Anders, Am Freitag, den 15.05.2009, 11:18 +0200 schrieb Anders Eriksson: Success! I've tracked down the offending change. switch_addr takes on the wrong value and setting the LNA fails. Here's a i2c dump: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c xfer: 20 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 84 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 86 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 94 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 saa7133[0]: i2c xfer: 96 00 saa7133[0]: i2c xfer: 97 =01 =01 =00 =11 =01 =04 =01 =85 saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b tuner' 1-004b: tda829x detected tuner' 1-004b: Setting mode_mask to 0x0e tuner' 1-004b: chip found @ 0x96 (saa7133[0]) tuner' 1-004b: tuner 0x4b: Tuner type absent tuner' i2c attach [addr=0x4b,client=(tuner unset)] tuner' 1-004b: Calling set_type_addr for type=54, addr=0xff, mode=0x04, config=0x01 tuner' 1-004b: set addr for type -1 tuner' 1-004b: defining GPIO callback saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b saa7133[0]: i2c xfer: 96 2f saa7133[0]: i2c xfer: 97 =00 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c1 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c3 =88 saa7133[0]: i2c xfer: c5 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c7 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: setting tuner address to 61 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c3 =08 tda827x: tda827x_attach: tda827x: type set to Philips TDA827X saa7133[0]: i2c xfer: c3 =08 tda827x: tda827xa tuner found tda827x: tda827x_init: tda827x: tda827xa_sleep: saa7133[0]: i2c xfer: c2 30 90 saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: type set to tda8290+75a saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c2 00 00 00 00 dc 05 8b 0c 04 20 ff 00 00 4b saa7133[0]: i2c xfer: 96 21 00 saa7133[0]: i2c xfer: 96 20 01 saa7133[0]: i2c xfer: 96 30 6f tuner' 1-004b: type set to tda8290+75a tuner' 1-004b: tv freq set to 400.00 tda829x 1-004b: setting tda829x to system xx tda829x 1-004b: tda827xa config is 0x01 saa7133[0]: i2c xfer: 96 01 00 saa7133[0]: i2c xfer: 96 02 00 saa7133[0]: i2c xfer: 96 00 00 saa7133[0]: i2c xfer: 96 01 90 saa7133[0]: i2c xfer: 96 28 14 saa7133[0]: i2c xfer: 96 0f 88 saa7133[0]: i2c xfer: 96 05 04 saa7133[0]: i2c xfer: 96 0d 47 saa7133[0]: i2c xfer: 96 21 c0 tda827x: setting tda827x to system xx tda827x: setting LNA to high gain saa7133[0]: i2c xfer: 96 22 00 ^ This address is c2 in all kernels = 5823b3a63c7661272ea7fef7635955e2a50d17eb saa7133[0]: i2c xfer: c2 00 32 f8 00 16 3b bb 1c 04 20 00 saa7133[0]: i2c xfer: c2 90 ff e0 00 99 saa7133[0]: i2c xfer: c2 a0 c0 saa7133[0]: i2c xfer: c2 30 10 saa7133[0]: i2c xfer: c3 =49 =a4 tda827x: AGC2 gain is: 10 ^ The gain reported on good kernels is 3 Looking at the source, the switch_addr to use in the later kernels is somehow autodetected. How that's done, I've yet to fully understand, but somehow it comes up with the wrong address. This patch (which obviously needs improvement) hardwires the address back to its original value, and works for 2.6.30-rc5. diff --git a/drivers/media/common/tuners/tda8290.c b/drivers/media/common/tuners/tda8290.c index 064d14c..498cc7b 100644 --- a/drivers/media/common/tuners/tda8290.c +++ b/drivers/media/common/tuners/tda8290.c @@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe) dvb_attach(tda827x_attach, fe, priv-tda827x_addr, priv-i2c_props.adap, priv-cfg); + tuner_info(ANDERS: setting switch_addr. was 0x%02x, new 0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr); priv-cfg.switch_addr = priv-i2c_props.addr; + priv-cfg.switch_addr = 0xc2 / 2; + tuner_info(ANDERS: new 0x%02x\n,priv-cfg.switch_addr); + } if (fe-ops.tuner_ops.init) fe-ops.tuner_ops.init(fe); Could you please help me out and shed some light on what the proper fix is for setting switch_addr? Thanks, /Anders thanks a lot for all your time and energy you did spend on this. I suggest we start collecting photographs of different LNA circuits on the wiki. For now, Tom offered his support already off list, I think we should start about the question, if that early Hauppauge HVR 1110 has such an LNA type one at all, since this caused to not look at it further, as it seemed to be without problems. Tom, I know you carefully worked on it, but can you reassure that this LNA config one is really needed on your device? Cheers, Hermann -- To unsubscribe from this list:
