Re: [PATCH 1/3 v2] ezx: Add camera support for A780 and A910 EZX phones
Ping.
Guennadi, did you see the patch below? Or I should completely remove
the .init() callback like you said in another message?
As I said, my humble preference would be to keep GPIOs setup local to
the driver somehow, but you just tell me what to do :)
On Fri, 6 Nov 2009 18:29:10 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
On Fri, 6 Nov 2009 15:11:55 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Thu, 5 Nov 2009, Antonio Ospite wrote:
See? It's power(), reset(), init().
Maybe the problem is in soc_camera_probe()?
Sorry, you'd have to elaborate more on this. So, what's wrong with that
sequence? it doesn't make sense to reset a powered down device or reset
after init or whatever...
I mean, when probing (or even opening) the device, pxacamera.init()
is now called *after* the power ON and reset. If I kept disabled (high)
nCAM_EN in init(), as it should've been, this would have overridden
the previous power(1) call.
Isn't init() in pxacamera platform data meant to initialize the device
before it can be powered ON? In fact I am requesting the gpios in
a780_pxacamera_init, and if power() or reset() are called before it, then
they will be invalid, because the gpios have not been requested yet.
Moreover, pxacamera.init() is called in pxa_camera_activate, which is
called in pxa_camera_add_device, which in turn is invoked by
soc_camera_open() every time.
Shouldn't the init() method, where I request gpios, be called
only on probe?
Let me be more schematic, when probing the camera we have:
soc_camera_probe() /* same in soc_camera_open! */
|-icl-power(1)
|-icl-reset()
|-icd-ops-add()
|- pxacamera.init() /* requesting gpios here! */
|-video_dev_create(icd)
|-...
Maybe we should have something like:
pxacamera.init() /* request gpios only once! on probe. */
soc_camera_probe() /* same in soc_camera_open */
|-icl-power(1)
|-icl-reset()
|-icd-ops-add()
|-video_dev_create(icd)
|-...
Or, I'm missing what init() is supposed to do :)
Does a patch like this make sense to you?
(I've read the other mail about removing .init just before hitting Send,
this can be an alternative to removing it, having GPIOs setup in the
user driver seems clearer to me.)
diff --git a/drivers/media/video/pxa_camera.c
b/drivers/media/video/pxa_camera.c
index 6952e96..3101bcb 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -881,18 +882,8 @@ static void recalculate_fifo_timeout(struct
pxa_camera_dev *pcdev,
static void pxa_camera_activate(struct pxa_camera_dev *pcdev)
{
- struct pxacamera_platform_data *pdata = pcdev-pdata;
- struct device *dev = pcdev-soc_host.v4l2_dev.dev;
u32 cicr4 = 0;
- dev_dbg(dev, Registered platform device at %p data %p\n,
- pcdev, pdata);
-
- if (pdata pdata-init) {
- dev_dbg(dev, %s: Init gpios\n, __func__);
- pdata-init(dev);
- }
-
/* disable all interrupts */
__raw_writel(0x3ff, pcdev-base + CICR0);
@@ -1651,6 +1644,17 @@ static int __devinit pxa_camera_probe(struct
platform_device *pdev)
pcdev-res = res;
pcdev-pdata = pdev-dev.platform_data;
+
+ dev_dbg(pdev-dev, Registered platform device at %p data %p\n,
+ pcdev, pcdev-pdata);
+
+ if (pcdev-pdata pcdev-pdata-init) {
+ dev_dbg(pdev-dev, %s: Init gpios\n, __func__);
+ err = pcdev-pdata-init(pdev-dev);
+ if (err)
+ goto exit_clk;
+ }
+
pcdev-platform_flags = pcdev-pdata-flags;
if (!(pcdev-platform_flags (PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
pgp7eMfkgWJNi.pgp
Description: PGP signature
Re: [PATCH 1/3 v2] ezx: Add camera support for A780 and A910 EZX phones
On Tue, 10 Nov 2009, Antonio Ospite wrote: Ping. Guennadi, did you see the patch below? Or I should completely remove the .init() callback like you said in another message? As I said, my humble preference would be to keep GPIOs setup local to the driver somehow, but you just tell me what to do :) Yes, please make GPIO config static and remove .init. 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: ov538-ov7690
Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Michael Michael -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tw68-v2/tw68-i2c.c:145: error: unknown field ‘clie nt_register’ specified in initializer
Hey, I'm trying to compile tw68 and I'm getting the following: make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-i2c.o /root/tw68-v2/tw68-i2c.c:145: error: unknown field ‘client_register’ specified in initializer /root/tw68-v2/tw68-i2c.c:145: warning: missing braces around initializer /root/tw68-v2/tw68-i2c.c:145: warning: (near initialization for ‘tw68_adap_sw_template.dev_released’) /root/tw68-v2/tw68-i2c.c:145: warning: initialization makes integer from pointer without a cast /root/tw68-v2/tw68-i2c.c:145: error: initializer element is not computable at load time /root/tw68-v2/tw68-i2c.c:145: error: (near initialization for ‘tw68_adap_sw_template.dev_released.done’) make[2]: *** [/root/tw68-v2/tw68-i2c.o] Error 1 make[1]: *** [_module_/root/tw68-v2] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' make: *** [all] Error 2 Any ideas? -- 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: tw68-v2/tw68-i2c.c:145: error: unknown field ‘ client_register’ specified in initializer
Hi, On Tue, Nov 10, 2009 at 1:19 PM, Roman Gaufman hacke...@gmail.com wrote: Hey, I'm trying to compile tw68 and I'm getting the following: make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-i2c.o /root/tw68-v2/tw68-i2c.c:145: error: unknown field ‘client_register’ specified in initializer /root/tw68-v2/tw68-i2c.c:145: warning: missing braces around initializer /root/tw68-v2/tw68-i2c.c:145: warning: (near initialization for ‘tw68_adap_sw_template.dev_released’) /root/tw68-v2/tw68-i2c.c:145: warning: initialization makes integer from pointer without a cast /root/tw68-v2/tw68-i2c.c:145: error: initializer element is not computable at load time /root/tw68-v2/tw68-i2c.c:145: error: (near initialization for ‘tw68_adap_sw_template.dev_released.done’) make[2]: *** [/root/tw68-v2/tw68-i2c.o] Error 1 make[1]: *** [_module_/root/tw68-v2] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' make: *** [all] Error 2 Any ideas? yes, the i2c part got outdated by some kernel change. anyway it is still not used so you can safely remove tw68-i2c.c from Makefile. regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- 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: tw68-v2/tw68-i2c.c:145: error: unknown field ‘ client_register’ specified in initializer
Thanks, managed to compile but getting -1 Unknown symbol in module now - any ideas? # make make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-video.o CC [M] /root/tw68-v2/tw68-controls.o CC [M] /root/tw68-v2/tw68-fileops.o CC [M] /root/tw68-v2/tw68-ioctls.o CC [M] /root/tw68-v2/tw68-vbi.o CC [M] /root/tw68-v2/tw68-ts.o CC [M] /root/tw68-v2/tw68-risc.o CC [M] /root/tw68-v2/tw68-input.o CC [M] /root/tw68-v2/tw68-tvaudio.o LD [M] /root/tw68-v2/tw68.o Building modules, stage 2. MODPOST 1 modules CC /root/tw68-v2/tw68.mod.o LD [M] /root/tw68-v2/tw68.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' # insmod tw68.ko insmod: error inserting 'tw68.ko': -1 Unknown symbol in module # uname -a Linux xanview-dev 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux 2009/11/10 Domenico Andreoli cav...@gmail.com: Hi, On Tue, Nov 10, 2009 at 1:19 PM, Roman Gaufman hacke...@gmail.com wrote: Hey, I'm trying to compile tw68 and I'm getting the following: make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-i2c.o /root/tw68-v2/tw68-i2c.c:145: error: unknown field ‘client_register’ specified in initializer /root/tw68-v2/tw68-i2c.c:145: warning: missing braces around initializer /root/tw68-v2/tw68-i2c.c:145: warning: (near initialization for ‘tw68_adap_sw_template.dev_released’) /root/tw68-v2/tw68-i2c.c:145: warning: initialization makes integer from pointer without a cast /root/tw68-v2/tw68-i2c.c:145: error: initializer element is not computable at load time /root/tw68-v2/tw68-i2c.c:145: error: (near initialization for ‘tw68_adap_sw_template.dev_released.done’) make[2]: *** [/root/tw68-v2/tw68-i2c.o] Error 1 make[1]: *** [_module_/root/tw68-v2] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' make: *** [all] Error 2 Any ideas? yes, the i2c part got outdated by some kernel change. anyway it is still not used so you can safely remove tw68-i2c.c from Makefile. regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ezx: Add camera support for A780 and A910 EZX phones
On Wed, 4 Nov 2009 14:38:40 +0800
Eric Miao eric.y.m...@gmail.com wrote:
Hi Antonio,
Patch looks generally OK except for the MFP/GPIO usage...
Eric,
while I was at it I also checked the original code Motorola released.
It has:
PGSR(GPIO_CAM_EN) |= GPIO_bit(GPIO_CAM_EN);
PGSR(GPIO_CAM_RST)|= GPIO_bit(GPIO_CAM_RST);
After checking PXA manual and arch/arm/mach-pxa/mfp-pxa2xx.c,
I'd translate this to:
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 77286a2..6a47a9d 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -281,8 +281,8 @@ static unsigned long gen1_pin_config[] __initdata = {
GPIO94_CIF_DD_5,
GPIO17_CIF_DD_6,
GPIO108_CIF_DD_7,
- GPIO50_GPIO,/* CAM_EN */
- GPIO19_GPIO,/* CAM_RST */
+ GPIO50_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_EN */
+ GPIO19_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_RST */
/* EMU */
GPIO120_GPIO, /* EMU_MUX1 */
@@ -338,8 +338,8 @@ static unsigned long gen2_pin_config[] __initdata = {
GPIO48_CIF_DD_5,
GPIO93_CIF_DD_6,
GPIO12_CIF_DD_7,
- GPIO50_GPIO,/* CAM_EN */
- GPIO28_GPIO,/* CAM_RST */
+ GPIO50_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_EN */
+ GPIO28_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_RST */
GPIO17_GPIO,/* CAM_FLASH */
};
#endif
Is that right?
I am putting also this into the next version I am going to send for
submission, if you don't object.
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
pgpAF30Zdff2C.pgp
Description: PGP signature
Re: tw68-v2/tw68-i2c.c:145: error: unknown field ‘ client_register’ specified in initializer
Hi On Tue, Nov 10, 2009 at 1:40 PM, Roman Gaufman hacke...@gmail.com wrote: Thanks, managed to compile but getting -1 Unknown symbol in module now - any ideas? # make make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-video.o CC [M] /root/tw68-v2/tw68-controls.o CC [M] /root/tw68-v2/tw68-fileops.o CC [M] /root/tw68-v2/tw68-ioctls.o CC [M] /root/tw68-v2/tw68-vbi.o CC [M] /root/tw68-v2/tw68-ts.o CC [M] /root/tw68-v2/tw68-risc.o CC [M] /root/tw68-v2/tw68-input.o CC [M] /root/tw68-v2/tw68-tvaudio.o LD [M] /root/tw68-v2/tw68.o Building modules, stage 2. MODPOST 1 modules CC /root/tw68-v2/tw68.mod.o LD [M] /root/tw68-v2/tw68.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.31-14-generic' # insmod tw68.ko insmod: error inserting 'tw68.ko': -1 Unknown symbol in module dmesg would show which symbol is missing. the quick hack i suggest is to load the bttv driver with modprobe bttv, which brings in all the usual v4l2 modules, unload it and the reload the tw68.ko ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
Hi Guennadi, On Friday 30 October 2009 15:01:06 Guennadi Liakhovetski wrote: Introduce new v4l2-subdev sensor operations, move .enum_framesizes() and .enum_frameintervals() methods to it, I understand that we need sensor-specific operations, but I'm not sure if those two are really unneeded for non-sensor video. Speaking about enum_framesizes() and enum_frameintervals(), wouldn't it be better to provide a static array of data instead of a callback function ? That should be dealt with in another patch set of course. add a new .g_skip_top_lines() method and switch soc-camera to use it instead of .y_skip_top soc_camera_device member, which can now be removed. BTW, the lines of garbage you get at the beginning of the image is actually probably meta-data (such as exposure settings). Maybe the g_skip_top_lines() operation could be renamed to something meta-data related. Applications could also be interested in getting the data. -- 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: tw68-v2/tw68-i2c.c:145: error: unknown field ‘ client_register’ specified in initializer
Thank you, managed to modprobe the module. However now when I try to open the device with mplayer, the system just freezes. No error messages, just freezes and I have to hold the power button for 5 seconds. Any ideas? This is what I get in dmesg when I insmod tw68.ko: [ 94.913695] tw68: v4l2 driver version 0.0.1 loaded [ 94.913744] tw68 :03:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 94.913750] tw6804[0]: found at :03:00.0, rev: 16, irq: 16, latency: 32, mmio: 0xfbdff000 [ 94.913755] tw6804[0]: subsystem: :, board: GENERIC [card=0,autodetected] [ 94.913774] tw6804[0]: Unable to determine board type, using generic values [ 95.020034] IRQ 16/tw6804[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.020074] tw6804[0]: registered device video1 [v4l2] [ 95.020084] tw6804[0]: registered device vbi0 [ 95.020253] tw68 :03:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 95.020258] tw6804[1]: found at :03:01.0, rev: 16, irq: 17, latency: 32, mmio: 0xfbdfd000 [ 95.020263] tw6804[1]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.020610] tw6804[1]: Unable to determine board type, using generic values [ 95.129871] IRQ 17/tw6804[1]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.129899] tw6804[1]: registered device video2 [v4l2] [ 95.129910] tw6804[1]: registered device vbi1 [ 95.130075] tw68 :03:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 95.130081] tw6804[2]: found at :03:02.0, rev: 16, irq: 18, latency: 32, mmio: 0xfbdfb000 [ 95.130086] tw6804[2]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.130093] tw6804[2]: Unable to determine board type, using generic values [ 95.239712] IRQ 18/tw6804[2]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.239740] tw6804[2]: registered device video3 [v4l2] [ 95.239752] tw6804[2]: registered device vbi2 [ 95.239901] tw68 :03:03.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 95.239907] tw6804[3]: found at :03:03.0, rev: 16, irq: 19, latency: 32, mmio: 0xfbdf9000 [ 95.239912] tw6804[3]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.239919] tw6804[3]: Unable to determine board type, using generic values [ 95.349553] IRQ 19/tw6804[3]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.349581] tw6804[3]: registered device video4 [v4l2] [ 95.349592] tw6804[3]: registered device vbi3 [ 95.349733] tw68 :03:04.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 95.349738] tw6804[4]: found at :03:04.0, rev: 16, irq: 16, latency: 32, mmio: 0xfbdf7000 [ 95.349743] tw6804[4]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.349751] tw6804[4]: Unable to determine board type, using generic values [ 95.459394] IRQ 16/tw6804[4]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.459423] tw6804[4]: registered device video5 [v4l2] [ 95.459435] tw6804[4]: registered device vbi4 [ 95.459578] tw68 :03:05.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 95.459583] tw6804[5]: found at :03:05.0, rev: 16, irq: 17, latency: 32, mmio: 0xfbdf5000 [ 95.459588] tw6804[5]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.459595] tw6804[5]: Unable to determine board type, using generic values [ 95.569236] IRQ 17/tw6804[5]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.569263] tw6804[5]: registered device video6 [v4l2] [ 95.569274] tw6804[5]: registered device vbi5 [ 95.569417] tw68 :03:06.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 95.569422] tw6804[6]: found at :03:06.0, rev: 16, irq: 18, latency: 32, mmio: 0xfbdf3000 [ 95.569427] tw6804[6]: subsystem: 1797:6804, board: GENERIC [card=0,autodetected] [ 95.569434] tw6804[6]: Unable to determine board type, using generic values [ 95.679077] IRQ 18/tw6804[6]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.679105] tw6804[6]: registered device video7 [v4l2] [ 95.679117] tw6804[6]: registered device vbi6 [ 95.679263] tw68 :03:07.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 95.679268] tw6804[7]: found at :03:07.0, rev: 16, irq: 19, latency: 32, mmio: 0xfbdf1000 [ 95.679273] tw6804[7]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.679280] tw6804[7]: Unable to determine board type, using generic values [ 95.788918] IRQ 19/tw6804[7]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.788946] tw6804[7]: registered device video8 [v4l2] [ 95.788957] tw6804[7]: registered device vbi7 2009/11/10 Domenico Andreoli cav...@gmail.com: Hi On Tue, Nov 10, 2009 at 1:40 PM, Roman Gaufman hacke...@gmail.com wrote: Thanks, managed to compile but getting -1 Unknown symbol in module now - any ideas? # make make -C /lib/modules/2.6.31-14-generic/build M=/root/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.31-14-generic' CC [M] /root/tw68-v2/tw68-core.o CC [M] /root/tw68-v2/tw68-cards.o CC [M] /root/tw68-v2/tw68-video.o CC [M]
Re: tw68-v2/tw68-i2c.c:145: error: unknown field ‘ client_register’ specified in initializer
I swapped my graphics card and techwell DVR card places and now it works, thanks you!!! Only 1 question, the readme says there is no audio yet - any ideas when/if audio will be available? :) Thanks again! Roman 2009/11/10 Roman Gaufman hacke...@gmail.com: Thank you, managed to modprobe the module. However now when I try to open the device with mplayer, the system just freezes. No error messages, just freezes and I have to hold the power button for 5 seconds. Any ideas? This is what I get in dmesg when I insmod tw68.ko: [ 94.913695] tw68: v4l2 driver version 0.0.1 loaded [ 94.913744] tw68 :03:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 94.913750] tw6804[0]: found at :03:00.0, rev: 16, irq: 16, latency: 32, mmio: 0xfbdff000 [ 94.913755] tw6804[0]: subsystem: :, board: GENERIC [card=0,autodetected] [ 94.913774] tw6804[0]: Unable to determine board type, using generic values [ 95.020034] IRQ 16/tw6804[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.020074] tw6804[0]: registered device video1 [v4l2] [ 95.020084] tw6804[0]: registered device vbi0 [ 95.020253] tw68 :03:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 95.020258] tw6804[1]: found at :03:01.0, rev: 16, irq: 17, latency: 32, mmio: 0xfbdfd000 [ 95.020263] tw6804[1]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.020610] tw6804[1]: Unable to determine board type, using generic values [ 95.129871] IRQ 17/tw6804[1]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.129899] tw6804[1]: registered device video2 [v4l2] [ 95.129910] tw6804[1]: registered device vbi1 [ 95.130075] tw68 :03:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 95.130081] tw6804[2]: found at :03:02.0, rev: 16, irq: 18, latency: 32, mmio: 0xfbdfb000 [ 95.130086] tw6804[2]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.130093] tw6804[2]: Unable to determine board type, using generic values [ 95.239712] IRQ 18/tw6804[2]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.239740] tw6804[2]: registered device video3 [v4l2] [ 95.239752] tw6804[2]: registered device vbi2 [ 95.239901] tw68 :03:03.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 95.239907] tw6804[3]: found at :03:03.0, rev: 16, irq: 19, latency: 32, mmio: 0xfbdf9000 [ 95.239912] tw6804[3]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.239919] tw6804[3]: Unable to determine board type, using generic values [ 95.349553] IRQ 19/tw6804[3]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.349581] tw6804[3]: registered device video4 [v4l2] [ 95.349592] tw6804[3]: registered device vbi3 [ 95.349733] tw68 :03:04.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 95.349738] tw6804[4]: found at :03:04.0, rev: 16, irq: 16, latency: 32, mmio: 0xfbdf7000 [ 95.349743] tw6804[4]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.349751] tw6804[4]: Unable to determine board type, using generic values [ 95.459394] IRQ 16/tw6804[4]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.459423] tw6804[4]: registered device video5 [v4l2] [ 95.459435] tw6804[4]: registered device vbi4 [ 95.459578] tw68 :03:05.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 95.459583] tw6804[5]: found at :03:05.0, rev: 16, irq: 17, latency: 32, mmio: 0xfbdf5000 [ 95.459588] tw6804[5]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.459595] tw6804[5]: Unable to determine board type, using generic values [ 95.569236] IRQ 17/tw6804[5]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.569263] tw6804[5]: registered device video6 [v4l2] [ 95.569274] tw6804[5]: registered device vbi5 [ 95.569417] tw68 :03:06.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 95.569422] tw6804[6]: found at :03:06.0, rev: 16, irq: 18, latency: 32, mmio: 0xfbdf3000 [ 95.569427] tw6804[6]: subsystem: 1797:6804, board: GENERIC [card=0,autodetected] [ 95.569434] tw6804[6]: Unable to determine board type, using generic values [ 95.679077] IRQ 18/tw6804[6]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.679105] tw6804[6]: registered device video7 [v4l2] [ 95.679117] tw6804[6]: registered device vbi6 [ 95.679263] tw68 :03:07.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 95.679268] tw6804[7]: found at :03:07.0, rev: 16, irq: 19, latency: 32, mmio: 0xfbdf1000 [ 95.679273] tw6804[7]: subsystem: :, board: GENERIC [card=0,autodetected] [ 95.679280] tw6804[7]: Unable to determine board type, using generic values [ 95.788918] IRQ 19/tw6804[7]: IRQF_DISABLED is not guaranteed on shared IRQs [ 95.788946] tw6804[7]: registered device video8 [v4l2] [ 95.788957] tw6804[7]: registered device vbi7 2009/11/10 Domenico Andreoli cav...@gmail.com: Hi On Tue, Nov 10, 2009 at 1:40 PM, Roman Gaufman hacke...@gmail.com wrote:
[PATCH] Davinci VPFE Capture: Add support for Control ioctls
From: Vaibhav Hiremath hvaib...@ti.com
Added support for Control IOCTL,
- s_ctrl
- g_ctrl
- queryctrl
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index abe21e4..9c859a7 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1368,6 +1368,41 @@ static int vpfe_g_std(struct file *file, void *priv,
v4l2_std_id *std_id)
return 0;
}
+static int vpfe_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, queryctrl, qctrl);
+
+}
+
+static int vpfe_g_ctrl(struct file *file, void *priv, struct v4l2_control
*ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, g_ctrl, ctrl);
+}
+
+static int vpfe_s_ctrl(struct file *file, void *priv, struct v4l2_control
*ctrl)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ struct vpfe_subdev_info *sdinfo;
+
+ sdinfo = vpfe_dev-current_subdev;
+
+ return v4l2_device_call_until_err(vpfe_dev-v4l2_dev, sdinfo-grp_id,
+core, s_ctrl, ctrl);
+}
+
/*
* Videobuf operations
*/
@@ -1939,6 +1974,9 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
.vidioc_querystd = vpfe_querystd,
.vidioc_s_std= vpfe_s_std,
.vidioc_g_std= vpfe_g_std,
+ .vidioc_queryctrl= vpfe_queryctrl,
+ .vidioc_g_ctrl = vpfe_g_ctrl,
+ .vidioc_s_ctrl = vpfe_s_ctrl,
.vidioc_reqbufs = vpfe_reqbufs,
.vidioc_querybuf = vpfe_querybuf,
.vidioc_qbuf = vpfe_qbuf,
--
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 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
On Tue, 10 Nov 2009, Laurent Pinchart wrote:
Hi Guennadi,
On Friday 30 October 2009 15:01:06 Guennadi Liakhovetski wrote:
Introduce new v4l2-subdev sensor operations, move .enum_framesizes() and
.enum_frameintervals() methods to it,
I understand that we need sensor-specific operations, but I'm not sure if
those two are really unneeded for non-sensor video.
I suspect that wasn't my idea:-) Ok, found:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/8990/focus=9078
Speaking about enum_framesizes() and enum_frameintervals(), wouldn't it be
better to provide a static array of data instead of a callback function ?
That
should be dealt with in another patch set of course.
TBH, I don't understand why these methods are needed at all. Why the
existing {S,G,TRY}_FMT are not enough. So, obviously, this isn't a
question to me either.
add a new .g_skip_top_lines() method and switch soc-camera to use it instead
of .y_skip_top soc_camera_device member, which can now be removed.
BTW, the lines of garbage you get at the beginning of the image is actually
probably meta-data (such as exposure settings). Maybe the g_skip_top_lines()
operation could be renamed to something meta-data related. Applications could
also be interested in getting the data.
Aha, that's interesting, thanks! Yes, we could easily rename it to
.g_metadata_lines() or something like that.
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: Siano DVB driver and locking/sleeping
On Mon, Nov 9, 2009 at 11:09 AM, Tim Borgeaud t...@tangobravo.co.uk wrote: I am actually a FreeBSD user that has been using some Linux DVB driver code to create a kernel module for FreeBSD. I am working at getting various bits of Linux driver code to compile on FreeBSD (see http://www.tangobravo.co.uk/v4l-compat). During development of compatibility code (to allow Linux driver source to be used more easily with FreeBSD) I have happened to take a look at the source code for the siano driver (drivers/media/dvb/siano/). Within the smscoreapi.c source code there is some code, concerning locking and waiting, that seems to run contrary to my expectations. It leads me to suspect that my emulation of Linux locking and waiting (sleeping) functionality may be incomplete or, just possibly, that the siano driver code could do with some adjustment. In smscoreapi.c there are two functions: smscore_getbuffer and smscore_putbuffer. These appear to be synchronized using a spin lock. In smscore_getbuffer: --- DEFINE_WAIT(wait); spin_lock_irqsave(coredev-bufferslock, flags); /* This function must return a valid buffer, since the buffer list is * finite, we check that there is an available buffer, if not, we wait * until such buffer become available. */ prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE); if (list_empty(coredev-buffers)) schedule(); finish_wait(coredev-buffer_mng_waitq, wait); cb = (struct smscore_buffer_t *) coredev-buffers.next; list_del(cb-entry); spin_unlock_irqrestore(coredev-bufferslock, flags); --- It appears that schedule() could be invoked while the coredev-bufferslock spinlock is held. I was under the impression that one should not hold a spin lock while calling a function that may cause a thread to sleep. This suggests that either: 1) The schedule() drops the spin lock in some way that I am unaware of. I'd like to know if I need to investigate such functionality of schedule(). 2) It is permissible to sleep with a spin lock held and that in this case deadlock could not be caused. In addition, smscore_putbuffer simply consists of: - wake_up_interruptible(coredev-buffer_mng_waitq); list_add_locked(cb-entry, coredev-buffers, coredev-bufferslock); - I am not certain how the synchronization works. However, without better knowledge of when certain events may take place in the Linux kernel, it appears that the wake_up_interruptible in smscore_putbuffer completes before any new buffer is actually added to the coredev-buffers list. As far as I can tell, if a thread is made to sleep inside smscore_getbuffer and the coredev-bufferslock is held during the sleep, the thread will wait for a second thread to execute the wake_up_interruptible in smscore_putbuffer (perhaps why the spin lock cannot be held before the wake_up?). Then, if the sleeping thread does not actually get woken until after the list_add_locked is invoked (from smscore_putbuffer), deadlock would appear possible since the list_add_locked function call will end up spinning while waiting for the spin lock to be released (by the sleeping thread). If the sleeping thread is woken and resumes before the list_add_locked completes (i.e. before it obtains the spin lock), then it would seem possible that the two statements in smscore_getbuffer: cb = (struct smscore_buffer_t *) coredev-buffers.next; list_del(cb-entry); Will not produce the desired results. The buffers list will be empty and coredev-buffers-next == coredev-buffers (not the address of a smscore_buffer_t). Even if the spin lock is dropped in schedule(), there might exist a race where, after the wake_up_interruptible it might be possible for the woken thread to try to retrieve the next buffer before the list_add_locked completes. Is there some synchronization in the siano driver or some functionality of Linux that I am unaware of that would prevent these potential problems? The Siano driver is not a model Linux driver by any means. You have found problems in the driver that should be dealt with, not replicated. This is the open source community -- we're glad that Siano went as far as contributing this driver to the Linux Kernel. Anybody is welcome to improve on the current codebase, patches are always welcome. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
On Tue, 10 Nov 2009, Laurent Pinchart wrote:
On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote:
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how
video data is stored in RAM. This is not a one-to-one correspondence,
therefore we cannot use fourcc codes to configure subdevice output data
formats. This patch adds codes for several such on-the-bus formats and an
API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt()
API for configuring those codes. After all users of the old API in struct
v4l2_subdev_video_ops are converted, the API will be removed.
[snip]
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 04193eb..1e86f39 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
[snip]
@@ -206,6 +207,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+ enum_imgbus_fmt: enumerate pixel formats provided by a video data
Do we need to make that dynamic (and O(n)) or could we use a static array of
image bug frame formats ?
The current soc-camera uses a static array. It works for its users, but I
do not know about others.
source */
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config); @@ -227,6 +230,11 @@ struct v4l2_subdev_video_ops {
int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
+ int (*enum_imgbus_fmt)(struct v4l2_subdev *sd, int index,
+ enum v4l2_imgbus_pixelcode *code);
+ int (*g_imgbus_fmt)(struct v4l2_subdev *sd, struct v4l2_imgbus_framefmt
*fmt);
+ int (*try_imgbus_fmt)(struct v4l2_subdev *sd, struct
v4l2_imgbus_framefmt
*fmt);
+ int (*s_imgbus_fmt)(struct v4l2_subdev *sd, struct v4l2_imgbus_framefmt
*fmt); };
Obviously those calls will need to be moved to pad operations later.
Right.
They will
be exposed to userspace through ioctls on the media controller device and/or
the subdevices, so the v4l2_imgbus_pixelcode type shouldn't be an enum.
Ok, will use __u32 for it then just as all other enum types...
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: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client API optional
On Tue, 10 Nov 2009, Laurent Pinchart wrote: Hi Guennadi, On Thursday 05 November 2009 18:07:09 Karicheri, Muralidharan wrote: Guennadi, in the v4l2_queryctrl struct. I think, this is unrelated. Muralidharan just complained about the soc_camera_find_qctrl() function being used in client subdev drivers, that were to be converted to v4l2-subdev, specifically, in mt9t031.c. And I just explained, that that's just a pretty trivial library function, that does not introduce any restrictions on how that subdev driver can be used in non-soc-camera configurations, apart from the need to build and load the soc-camera module. In other words, any v4l2-device bridge driver should be able to communicate with such a subdev driver, calling that function. If soc_camera_find_qctrl() is such a generic function, why don't you move it to v4l2-common.c so that other platforms doesn't have to build SOC camera sub system to use this function? Your statement reinforce this. I second this. Hans is working on a controls framework that should (hopefully :-)) make drivers simpler by handling common tasks in the v4l core. Well, if you look at the function itself and at how it got replaced in this version of the patch by O(1) operations, you'll, probably, agree, that avoiding that function where possible is better than making it generic. But if there are any legitimate users for it - sure, can make it generic too. Do you have any plan to work on the bus hardware configuration API ? When that will be available the mt9t031 driver could be made completely soc-camera-free. I'd love to first push the proposed image-bus upstream. Even with just that many drivers can already be re-used. As for bus configuration, I thought there were enough people working on it already:-) If not, maybe I could have a look at it, but we better reach some agreement on that beforehand to avoid duplicating the effort. 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] v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/Documentation/DocBook/v4l/videodev2.h.xml |2 ++
linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml
b/linux/Documentation/DocBook/v4l/videodev2.h.xml
index 9700206..eef7ba4 100644
--- a/linux/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml
@@ -565,6 +565,7 @@ struct link
linkend=v4l2-framebufferv4l2_framebuffer/link {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
+#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@@ -572,6 +573,7 @@ struct link
linkend=v4l2-framebufferv4l2_framebuffer/link {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
+#define V4L2_FBUF_FLAG_SRC_CHROMAKEY0x0040
struct link linkend=v4l2-clipv4l2_clip/link {
struct link linkend=v4l2-rectv4l2_rect/linkc;
diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
index f701706..e7dda48 100644
--- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
+++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml
@@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive
overlays./entry
inverted alpha channel of the framebuffer or VGA signal. Alpha
blending makes no sense for destructive overlays./entry
/row
+ row
+ entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry
+ entry0x0080/entry
+ entryThe device supports Source Chroma-keying. Framebuffer pixels
+with the chroma-key colors are replaced by video pixels, which is exactly
opposite of
+constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry
+ /row
/tbody
/tgroup
/table
@@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend
function is:
output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The
actual alpha depth depends on the framebuffer pixel format./entry
/row
+ row
+ entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry
+ entry0x0040/entry
+ entryUse source chroma-keying. The source chroma-key color is
+determined by the structfieldchromakey/structfield field of
+v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref
+linkend=overlay / and xref linkend=osd /.
+Both chroma-keying are mutual exclusive to each other, so same
+structfieldchromakey/structfield field of v4l2-window; is being
used./entry
+ /row
/tbody
/tgroup
/table
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] soc_camera: multiple input capable enum, g s
soc_camera: multiple input capable enum, g s
From: Philipp Wiesner p.wies...@gmx.net
I did some small changes to support soc camera devices with multiple inputs,
e.g. tw9910 (driver doesn't support this yet).
soc-camera.c:
soc_camera_enum_input: capable of handling multiple inputs.
soc_camera_g_input: calls icd's g_input if present.
soc_camera_s_input: calls icd's s_input if present.
soc-camera.h:
struct soc_camera_ops: Added aliases for g_input and s_input functions here.
Priority: normal
Signed-off-by: Philipp Wiesner p.wies...@gmx.net
diff -r 43878f8dbfb0 -r a5254e7d306a linux/drivers/media/video/soc_camera.c
--- a/linux/drivers/media/video/soc_camera.cSun Nov 01 07:17:46 2009 -0200
+++ b/linux/drivers/media/video/soc_camera.cTue Nov 03 17:17:49 2009 +0100
@@ -119,11 +119,10 @@
struct soc_camera_device *icd = icf-icd;
int ret = 0;
- if (inp-index != 0)
- return -EINVAL;
-
if (icd-ops-enum_input)
ret = icd-ops-enum_input(icd, inp);
+ else if (inp-index != 0)
+ return -EINVAL;
else {
/* default is camera */
inp-type = V4L2_INPUT_TYPE_CAMERA;
@@ -136,17 +135,30 @@
static int soc_camera_g_input(struct file *file, void *priv, unsigned int *i)
{
- *i = 0;
+ struct soc_camera_file *icf = file-private_data;
+ struct soc_camera_device *icd = icf-icd;
+ int ret = 0;
- return 0;
+ if (icd-ops-g_input)
+ ret = icd-ops-g_input(icd, i);
+ else
+ *i = 0;
+
+ return ret;
}
static int soc_camera_s_input(struct file *file, void *priv, unsigned int i)
{
- if (i 0)
+ struct soc_camera_file *icf = file-private_data;
+ struct soc_camera_device *icd = icf-icd;
+ int ret = 0;
+
+ if (icd-ops-s_input)
+ ret = icd-ops-s_input(icd, i);
+ else if (i 0)
return -EINVAL;
- return 0;
+ return ret;
}
static int soc_camera_s_std(struct file *file, void *priv, v4l2_std_id *a)
diff -r 43878f8dbfb0 -r a5254e7d306a linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h Sun Nov 01 07:17:46 2009 -0200
+++ b/linux/include/media/soc_camera.h Tue Nov 03 17:17:49 2009 +0100
@@ -197,6 +197,8 @@
unsigned long (*query_bus_param)(struct soc_camera_device *);
int (*set_bus_param)(struct soc_camera_device *, unsigned long);
int (*enum_input)(struct soc_camera_device *, struct v4l2_input *);
+ int (*g_input)(struct soc_camera_device *, unsigned int *);
+ int (*s_input)(struct soc_camera_device *, unsigned int);
const struct v4l2_queryctrl *controls;
int num_controls;
};
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
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: tw68-v2/tw68-i2c.c:145: error: unknown field ???client_register??? specified in initializer
On Tue, Nov 10, 2009 at 01:48:43PM +, Roman Gaufman wrote: I swapped my graphics card and techwell DVR card places and now it works, thanks you!!! have you a PCI-E techwell board? i'm taking the driver out of the freezer trying to get rid of the IRQF_DISABLED warning flag. i'm interested in seeing your /proc/interrupts, if possible, before and after the boards swap. Only 1 question, the readme says there is no audio yet - any ideas when/if audio will be available? :) bad news here, i can't promise anything. anyway i'd like to push this driver to kernel staging and audio support is required for this step. so it is one of my topmost TODO entries. Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ezx: Add camera support for A780 and A910 EZX phones
On Tue, Nov 10, 2009 at 8:48 PM, Antonio Ospite
osp...@studenti.unina.it wrote:
On Wed, 4 Nov 2009 14:38:40 +0800
Eric Miao eric.y.m...@gmail.com wrote:
Hi Antonio,
Patch looks generally OK except for the MFP/GPIO usage...
Eric,
while I was at it I also checked the original code Motorola released.
It has:
PGSR(GPIO_CAM_EN) |= GPIO_bit(GPIO_CAM_EN);
PGSR(GPIO_CAM_RST)|= GPIO_bit(GPIO_CAM_RST);
After checking PXA manual and arch/arm/mach-pxa/mfp-pxa2xx.c,
I'd translate this to:
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 77286a2..6a47a9d 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -281,8 +281,8 @@ static unsigned long gen1_pin_config[] __initdata = {
GPIO94_CIF_DD_5,
GPIO17_CIF_DD_6,
GPIO108_CIF_DD_7,
- GPIO50_GPIO, /* CAM_EN */
- GPIO19_GPIO, /* CAM_RST */
+ GPIO50_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_EN */
+ GPIO19_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_RST */
/* EMU */
GPIO120_GPIO, /* EMU_MUX1 */
@@ -338,8 +338,8 @@ static unsigned long gen2_pin_config[] __initdata = {
GPIO48_CIF_DD_5,
GPIO93_CIF_DD_6,
GPIO12_CIF_DD_7,
- GPIO50_GPIO, /* CAM_EN */
- GPIO28_GPIO, /* CAM_RST */
+ GPIO50_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_EN */
+ GPIO28_GPIO | MFP_LPM_DRIVE_HIGH, /* CAM_RST */
GPIO17_GPIO, /* CAM_FLASH */
};
#endif
Is that right?
That's right.
I am putting also this into the next version I am going to send for
submission, if you don't object.
No I won't, feel free to.
--
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: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
On Tue, Nov 10, 2009 at 4:39 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Yes I rebooted the system after compiling and installing through 'make install' last v4l-dvb source, but with no luck, /dev/dvb device is still not present. Attached you can find the full dmesg, since system boot Thanks a lot again. P.s. Sorry for top posting, it's gmail0s default and sometimes I forget. Hello Valerio, Now that I have taken another look at the dmesg output, I see that this device is 0ccd:0043 and *not* 0ccd:0042. This prompted me to take another look at the driver, and indeed that board is not presently supported. It's the DVB only version of the board (as opposed to the hybrid). I can probably make it work, but it's a rather old board and not terribly high on my list of priorities. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tw68-v2/tw68-i2c.c:145: error: unknown field ???client_register??? specified in initializer
On Tue, Nov 10, 2009 at 01:48:43PM +, Roman Gaufman wrote:
I swapped my graphics card and techwell DVR card places and now it
works, thanks you!!!
could you please try the following patch swapping the boards back to
the original order?
--- a/tw68-core.c
+++ b/tw68-core.c
@@ -695,8 +695,7 @@ static int __devinit tw68_initdev(struct pci_dev *pci_dev,
tw68_hw_init1(dev);
/* get irq */
- err = request_irq(pci_dev-irq, tw68_irq,
- IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
+ err = request_irq(pci_dev-irq, tw68_irq, IRQF_SHARED, dev-name, dev);
if (err 0) {
printk(KERN_ERR %s: can't get IRQ %d\n,
dev-name, pci_dev-irq);
-[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
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: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
2009/11/10 Devin Heitmueller dheitmuel...@kernellabs.com: On Tue, Nov 10, 2009 at 4:39 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Yes I rebooted the system after compiling and installing through 'make install' last v4l-dvb source, but with no luck, /dev/dvb device is still not present. Attached you can find the full dmesg, since system boot Thanks a lot again. P.s. Sorry for top posting, it's gmail0s default and sometimes I forget. Hello Valerio, Now that I have taken another look at the dmesg output, I see that this device is 0ccd:0043 and *not* 0ccd:0042. This prompted me to take another look at the driver, and indeed that board is not presently supported. It's the DVB only version of the board (as opposed to the hybrid). I can probably make it work, but it's a rather old board and not terribly high on my list of priorities. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Hi Devin, I feared about that So, in this moment my only possibilities available to make it work are: - use an older kernel (=2.6.27) to compile successfully em28xx-new (maybe it could be better to use older linux distro) - make em28xx-new to compile on 2.6.31 kernel version - wait for device support on next kernel releases I have good programming knowledge, but few with C and driver programming, so if you can suggest me how can I modify em28xx-new sources to make them work on 2.6.31, then I can try to adjust them and then make this driver available just waiting for kernel support. Thanks a lot Valerio -- 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: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
On Tue, Nov 10, 2009 at 10:49 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Hi Devin, I feared about that So, in this moment my only possibilities available to make it work are: - use an older kernel (=2.6.27) to compile successfully em28xx-new (maybe it could be better to use older linux distro) - make em28xx-new to compile on 2.6.31 kernel version - wait for device support on next kernel releases I have good programming knowledge, but few with C and driver programming, so if you can suggest me how can I modify em28xx-new sources to make them work on 2.6.31, then I can try to adjust them and then make this driver available just waiting for kernel support. In theory you just need your board profile properly defined in em28xx-cards.c and em28xx-dvb.c. If I were going to choose between trying to make the old em28xx-new compile under the current kernel, and adding the 10-15 lines of code to the in-kernel em28xx driver, I would probably consider choosing the latter (and then feel free to submit the patch to be merged upstream). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ov538-ov7690
On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote: Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? -71 = -EPROTO (from include/asm-generic/errno.h). -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt): -EPROTO (*, **) a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error footnotes: (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. --- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
soc_camera, v4l2 api, gstreamer: setting errno ?
I'm having some trouble using gstreamer with soc_camera and am a
modified tw9910 driver. I had difficulties compiling the latest sources
for my target so I'm using old kernel and gstreamer versions. But my
question may still be valid, because the problem doesn't seem to be fixed
and this may be interesting for driver programming in the future.
The part I'm suspecting is
if (v4l2_ioctl (fd, VIDIOC_S_FMT, format) 0) {
if (errno != EINVAL)
goto set_fmt_failed;
[v4l2src_calls.c,1223]
According to V4L2 api documentation drivers should set errno, but all drivers
I've seen in the soc_camera framework (including soc_camera.c)
only 'return -errno'. Should device drivers (like tw9910) set errno or
should soc_camera use return values and set errno? Is it correct that
none of them happens at the moment?
--
DSL-Preisknaller: DSL Komplettpakete von GMX schon für
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02
--
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: tw68-v2/tw68-i2c.c:145: error: unknown field ???client_register??? specified in initializer
2009/11/10 Domenico Andreoli cav...@gmail.com: On Tue, Nov 10, 2009 at 01:48:43PM +, Roman Gaufman wrote: I swapped my graphics card and techwell DVR card places and now it works, thanks you!!! have you a PCI-E techwell board? Yep, it's PCI-E 8 audio/video dvr card. i'm taking the driver out of the freezer trying to get rid of the IRQF_DISABLED warning flag. i'm interested in seeing your /proc/interrupts, if possible, before and after the boards swap. Both with the patch: After the swap (working): CPU0 CPU1 CPU2 CPU3 0: 22 0 0 40 IO-APIC-edge timer 1: 0 0 0 2 IO-APIC-edge i8042 4: 0 0 0 2 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 543773 IO-APIC-fasteoi ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4] 17: 0 0 0 40297 IO-APIC-fasteoi pata_jmicron, ohci1394, tw6804[1], tw6804[5] 18: 0 0 0 24680 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6] 19: 0 0 40184 0 IO-APIC-fasteoi uhci_hcd:usb7, tw6804[3], tw6804[7] 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 0218 0 0 IO-APIC-fasteoi HDA Intel 23: 0 0 0108 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 24: 934040 0 0 0 HPET_MSI-edge hpet2 25: 0 390326 0 0 HPET_MSI-edge hpet3 26: 0 0 590635 0 HPET_MSI-edge hpet4 27: 0 0 0 845999 HPET_MSI-edge hpet5 33: 0 0 0 0 PCI-MSI-edge ahci 34: 812442 0 0 0 PCI-MSI-edge eth1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 54 38 23 8 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts CNT: 0 0 0 0 Performance counter interrupts PND: 0 0 0 0 Performance pending work RES: 4027 5400 6102 6462 Rescheduling interrupts CAL:124139137 44 Function call interrupts TLB: 27517 22022 23155 17498 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 41 41 41 41 Machine check polls ERR: 0 MIS: 0 Before swap (system freezes as soon as I try to open video device): # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 22 0 0 1 IO-APIC-edge timer 1: 0 0 0 2 IO-APIC-edge i8042 4: 0 0 0 2 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 9090 IO-APIC-fasteoi ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4] 17: 0 0 0 3 IO-APIC-fasteoi pata_jmicron, ohci1394, tw6804[1], tw6804[5] 18: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6] 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb7, tw6804[3], tw6804[7] 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 0218 0 0 IO-APIC-fasteoi HDA Intel 23: 0 0 0103 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 24: 3102 0 0 0 HPET_MSI-edge hpet2 25: 0 2403 0 0 HPET_MSI-edge hpet3 26: 0 0 1899 0 HPET_MSI-edge hpet4 27: 0 0 0 2835 HPET_MSI-edge hpet5 33: 0 0 0 0 PCI-MSI-edge ahci 34:816 0 0 0 PCI-MSI-edge eth1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 54 38 23 8 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts CNT: 0 0 0 0 Performance
Re: ov538-ov7690
Hi, Randy Dunlap wrote: On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote: Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? -71 = -EPROTO (from include/asm-generic/errno.h). -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt): -EPROTO (*, **) a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error footnotes: (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. OK, but it's a failure of the ehci transaction on my laptop and seems that is not so frequent. I think that can be a cable problem. (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :( Michael --- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ov538-ov7690
On Tue, 10 Nov 2009 17:51:15 +0100 Michael Trimarchi wrote: Hi, Randy Dunlap wrote: On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote: Hi, Michael Trimarchi wrote: Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? -71 = -EPROTO (from include/asm-generic/errno.h). -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt): -EPROTO (*, **) a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error footnotes: (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. OK, but it's a failure of the ehci transaction on my laptop and seems that is not so frequent. I think that can be a cable problem. Probably could be a cable problem. If you suspect that it is a USB (ehci) problem, you should raise this issue on the linux-...@vger.kernel.org mailing list. (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :( I don't even know what vl2 vl1 means. ;) --- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge HVR-1600 cx18 loading problem
My new Hauppauge HVR-1600 does not load the firmware. The driver was built using the source from over the weekend. I am using mythbuntu. Below is a modprobe cx18 debug=511 command Any help would greatly be appreciated. [43594.063182] cx18: Start initialization, version 1.2.0 [43594.063306] cx18-0: Initializing card 0 [43594.063312] cx18-0: Autodetected Hauppauge card [43594.063447] cx18-0: info: base addr: 0xdc00 [43594.063450] cx18-0: info: Enabling pci device [43594.063478] cx18 :00:0c.0: PCI INT A - Link[LNKA] - GSI 10 (level, low) - IRQ 10 [43594.063493] cx18-0: info: cx23418 (rev 0) at 00:0c.0, irq: 10, latency: 64, memory: 0xdc00 [43594.063498] cx18-0: info: attempting ioremap at 0xdc00 len 0x0400 [43594.065656] cx18-0: cx23418 revision 0101 (B) [43594.246946] cx18-0: info: GPIO initial dir: cffe/ out: 3001/ [43594.246970] cx18-0: info: activating i2c... [43594.246973] cx18-0: i2c: i2c init [43594.362969] tveeprom 5-0050: Hauppauge model 74041, rev C6B2, serial# 6380357 [43594.362976] tveeprom 5-0050: MAC address is 00-0D-FE-61-5B-45 [43594.362981] tveeprom 5-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) [43594.362987] tveeprom 5-0050: TV standards NTSC(M) (eeprom 0x08) [43594.362991] tveeprom 5-0050: audio processor is CX23418 (idx 38) [43594.362995] tveeprom 5-0050: decoder processor is CX23418 (idx 31) [43594.363000] tveeprom 5-0050: has no radio, has IR receiver, has IR transmitter [43594.363004] cx18-0: Autodetected Hauppauge HVR-1600 [43594.363008] cx18-0: info: NTSC tuner detected [43594.363011] cx18-0: Simultaneous Digital and Analog TV capture supported [43594.542552] IRQ 10/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs [43594.551681] tuner 6-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) [43594.554867] cs5345 5-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [43594.557430] tuner-simple 6-0061: creating new instance [43594.557436] tuner-simple 6-0061: type set to 50 (TCL 2002N) [43594.558186] cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total) [43594.558268] cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total) [43594.558310] cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total) [43594.558351] cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total) [43594.558389] cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total) [43594.558570] cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total) [43594.558732] cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB) [43594.558738] DVB: registering new adapter (cx18) [43594.594104] cx18 :00:0c.0: firmware: requesting v4l-cx23418-cpu.fw [43594.607124] cx18-0: Mismatch at offset 0 [43594.607137] cx18-0: Retry loading firmware [43594.608161] cx18 :00:0c.0: firmware: requesting v4l-cx23418-cpu.fw [43594.649832] cx18-0: Mismatch at offset 0 [43594.649848] cx18-0: Failed to initialize on minor 3 [43594.682215] cx18-0: Failed to initialize on minor 3 [43594.691048] MXL5005S: Attached at address 0x63 [43594.691063] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... [43594.708643] cx18-0: DVB Frontend registered [43594.708651] cx18-0: Registered DVB adapter0 for TS (32 x 32 kB) [43594.708711] cx18-0: Registered device video33 for encoder YUV (16 x 128 kB) [43594.708749] cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes) [43594.708785] cx18-0: Registered device video25 for encoder PCM audio (256 x 4 kB) [43594.708790] cx18-0: Initialized card: Hauppauge HVR-1600 [43594.708829] cx18: End initialization [43594.716719] cx18-0: Failed to initialize on minor 4 [43594.723793] cx18-0: Failed to initialize on minor 5 [43594.726277] cx18-0: Failed to initialize on minor 6 [43594.736339] cx18-0: Failed to initialize on minor 6 [43594.757957] cx18-0: Failed to initialize on minor 4 [43594.784206] cx18-0: Failed to initialize on minor 5 Thanks, John -- 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: tw68-v2/tw68-i2c.c:145: error: unknown field ???client_register??? specified in initializer
On Tue, Nov 10, 2009 at 04:51:47PM +, Roman Gaufman wrote: 2009/11/10 Domenico Andreoli cav...@gmail.com: On Tue, Nov 10, 2009 at 01:48:43PM +, Roman Gaufman wrote: I swapped my graphics card and techwell DVR card places and now it works, thanks you!!! have you a PCI-E techwell board? Yep, it's PCI-E 8 audio/video dvr card. there are a lot of cheap boards based on these chips on ebay i'm taking the driver out of the freezer trying to get rid of the IRQF_DISABLED warning flag. i'm interested in seeing your /proc/interrupts, if possible, before and after the boards swap. Both with the patch: After the swap (working): CPU0 CPU1 CPU2 CPU3 0: 22 0 0 40 IO-APIC-edge timer 1: 0 0 0 2 IO-APIC-edge i8042 4: 0 0 0 2 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 543773 IO-APIC-fasteoi ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4] 17: 0 0 0 40297 IO-APIC-fasteoi pata_jmicron, ohci1394, tw6804[1], tw6804[5] 18: 0 0 0 24680 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6] 19: 0 0 40184 0 IO-APIC-fasteoi uhci_hcd:usb7, tw6804[3], tw6804[7] 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 0218 0 0 IO-APIC-fasteoi HDA Intel 23: 0 0 0108 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 24: 934040 0 0 0 HPET_MSI-edge hpet2 25: 0 390326 0 0 HPET_MSI-edge hpet3 26: 0 0 590635 0 HPET_MSI-edge hpet4 27: 0 0 0 845999 HPET_MSI-edge hpet5 33: 0 0 0 0 PCI-MSI-edge ahci 34: 812442 0 0 0 PCI-MSI-edge eth1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 54 38 23 8 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts CNT: 0 0 0 0 Performance counter interrupts PND: 0 0 0 0 Performance pending work RES: 4027 5400 6102 6462 Rescheduling interrupts CAL:124139137 44 Function call interrupts TLB: 27517 22022 23155 17498 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 41 41 41 41 Machine check polls ERR: 0 MIS: 0 Before swap (system freezes as soon as I try to open video device): # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 22 0 0 1 IO-APIC-edge timer 1: 0 0 0 2 IO-APIC-edge i8042 4: 0 0 0 2 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 9090 IO-APIC-fasteoi ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4] 17: 0 0 0 3 IO-APIC-fasteoi pata_jmicron, ohci1394, tw6804[1], tw6804[5] 18: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6] 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb7, tw6804[3], tw6804[7] 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 0218 0 0 IO-APIC-fasteoi HDA Intel 23: 0 0 0103 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 24: 3102 0 0 0 HPET_MSI-edge hpet2 25: 0 2403 0 0 HPET_MSI-edge hpet3 26: 0 0 1899 0 HPET_MSI-edge hpet4 27: 0 0 0 2835 HPET_MSI-edge hpet5 33: 0 0 0 0 PCI-MSI-edge ahci 34:816 0 0 0 PCI-MSI-edge eth1 NMI: 0 0
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. - decode_tm6000: fix compilation - davinci: remove stray duplicate config pointer - davinci: add missing vpif_capture.c/h files - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture: add i2c adapter id in platform data - Davinci VPFE Capture: Take i2c adapter id through platform data - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added ROTATE and BG_COLOR control documentation - Davinci VPFE Capture: Add support for Control ioctls - V4L2: Add Capability and Flag field for Chroma Key - v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY Note that the third patch (davinci: remove stray duplicate config pointer) is a high-prio bug fix that must go into 2.6.32. I discovered that for some reason the davinci/vpif_capture.c/h files were missing in the v4l-dvb master repo, so they are added back in the fourth patch (I copied them from 2.6.32-rc6). There is one arch patch involved here as well: http://patchwork.kernel.org/patch/53426/ This patch belongs after Davinci VPFE Capture: add i2c adapter id in platform data but before Take i2c adapter id through platform data. The new controls and chromakey cap/flag were originally discussed in January to April this year based on omap patches from Hardik Shah. I actually thought these patches were committed months ago, but they apparently fell on the floor. The original discussion is here: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg00624.html Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/vpif_capture.c | 2168 + b/linux/drivers/media/video/davinci/vpif_capture.h | 165 + linux/Documentation/DocBook/v4l/controls.xml | 20 linux/Documentation/DocBook/v4l/pixfmt.xml |5 linux/Documentation/DocBook/v4l/videodev2.h.xml| 1103 +- linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 linux/drivers/media/video/davinci/vpfe_capture.c | 45 linux/drivers/media/video/davinci/vpif_display.c |1 linux/drivers/media/video/v4l2-common.c|9 linux/include/linux/videodev2.h|6 linux/include/media/davinci/vpfe_capture.h |2 v4l2-apps/util/Makefile|2 v4l2-apps/util/decode_tm6000.c |2 13 files changed, 2987 insertions(+), 558 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 3/4 v6] TVP7002 driver for DM365
Hans,
Thanks for all your patient and detailed reviews. I've addressed most of
the comments. There is one thing though that seems odd but is there due
to a good reason. The devices requires to be turned off and on again
during the s_stream function, in which it 'forgets' its previous state
and therefore register values have to be kept in memory and set back for
initialization purposes.
Regards,
Hans Verkuil wrote:
Hi Santiago,
See review comments below:
On Friday 06 November 2009 16:42:56 santiago.nu...@ridgerun.com wrote:
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
drivers/media/video/tvp7002.c | 1423 +
1 files changed, 1423 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..7d945d9
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1423 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+ u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+ { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+ { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+ { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+ { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+ { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+ { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+ { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+ { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+ { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+ { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE },
+ { TVP7002_IN_MUX_SEL_1, 0x00,
Re: [PATCH 3/4 v6] TVP7002 driver for DM365
On Tuesday 10 November 2009 19:12:13 Santiago Nunez-Corrales wrote: Hans, Thanks for all your patient and detailed reviews. I've addressed most of the comments. There is one thing though that seems odd but is there due to a good reason. The devices requires to be turned off and on again during the s_stream function, in which it 'forgets' its previous state and therefore register values have to be kept in memory and set back for initialization purposes. Hmm. It's still pretty ugly. Wouldn't it be more elegant to record this state at a higher level? E.g. instead of restoring gain registers you would store the current gain value in the state struct and just set the gain again. Ditto for things like the output standard, etc. Another question is: why does it need to be reset? That's rather peculiar. Are there powersaving considerations? Is this normal behavior for this device? I can't imagine that this is how the tvp7002 designers expected it to be used, so I get the feeling that what you are doing is more a kludge to hammer the driver into the v4l2_subdev API. Can you look at this some more? I have downloaded the tvp7002 datasheet, so you can also point me to the relevant sections/register descriptions of the datasheet. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: ov538-ov7690
Em Tue, 10 Nov 2009 09:09:10 -0800 Randy Dunlap rdun...@xenotime.net escreveu: (**) This is also one of several codes that different kinds of host controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. Ok, this is not a big issue because I can use vlc to test the camera. But anybody knows why camorama, camstream, cheese crash during test. is it driver depend? or not? Could be driver. Easily could be a device problem too. I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :( I don't even know what vl2 vl1 means. ;) He is probably referring to V4L1 x V4L2 API calls. Very unlikely. What libv4l does is to convert userspace calls via V4L1 to a V4L2 call to kernel. So, you're basically using the same API to communicate to userspace. It should be noticed that, if you're not using libv4l for the other applications, then you may be using a different format at the driver, since libv4l has the capability of doing format conversions. So, it could be possible that the device firmware for some formats are broken. Another possibility is that maybe libv4l is just discarding such errors. Or, as Randy mentioned, it can be just a cable or a connector with bad contact. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] go7007: Add struct v4l2_device.
From: Pete Eberlein p...@sensoray.com
This adds a struct v4l2_device to the go7007 device struct and registers
it during v4l2 initialization. The v4l2_device registration overwrites
the go-dev device_data, which is a struct usb_interface with intfdata set
to the struct go7007. This changes intfdata to point to the struct
v4l2_device inside struct go7007, which is what v4l2_device_register will
also set it to (and warn about non-null drvdata on register.) Since usb
disconnect can happen any time, this intfdata should always be present.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 19c0469c02c3 -r a603ad1e6a1c
linux/drivers/staging/go7007/go7007-driver.c
--- a/linux/drivers/staging/go7007/go7007-driver.c Sat Nov 07 15:51:01
2009 -0200
+++ b/linux/drivers/staging/go7007/go7007-driver.c Tue Nov 10 10:41:56
2009 -0800
@@ -49,7 +49,7 @@
go-hpi_ops-read_interrupt(go);
if (wait_event_timeout(go-interrupt_waitq,
go-interrupt_available, 5*HZ) 0) {
- v4l2_err(go-video_dev, timeout waiting for read interrupt\n);
+ v4l2_err(go-v4l2_dev, timeout waiting for read interrupt\n);
return -1;
}
if (!go-interrupt_available)
@@ -315,7 +315,7 @@
if (go7007_send_firmware(go, fw, fw_len) 0 ||
go7007_read_interrupt(go, intr_val, intr_data) 0) {
- v4l2_err(go-video_dev, error transferring firmware\n);
+ v4l2_err(go-v4l2_dev, error transferring firmware\n);
rv = -1;
goto start_error;
}
@@ -324,7 +324,7 @@
go-parse_length = 0;
go-seen_frame = 0;
if (go7007_stream_start(go) 0) {
- v4l2_err(go-video_dev, error starting stream transfer\n);
+ v4l2_err(go-v4l2_dev, error starting stream transfer\n);
rv = -1;
goto start_error;
}
@@ -420,7 +420,7 @@
for (i = 0; i length; ++i) {
if (go-active_buf != NULL
go-active_buf-bytesused = GO7007_BUF_SIZE - 3) {
- v4l2_info(go-video_dev, dropping oversized frame\n);
+ v4l2_info(go-v4l2_dev, dropping oversized frame\n);
go-active_buf-offset -= go-active_buf-bytesused;
go-active_buf-bytesused = 0;
go-active_buf-modet_active = 0;
@@ -668,7 +668,7 @@
if (i2c_del_adapter(go-i2c_adapter) == 0)
go-i2c_adapter_online = 0;
else
- v4l2_err(go-video_dev,
+ v4l2_err(go-v4l2_dev,
error removing I2C adapter!\n);
}
diff -r 19c0469c02c3 -r a603ad1e6a1c linux/drivers/staging/go7007/go7007-priv.h
--- a/linux/drivers/staging/go7007/go7007-priv.hSat Nov 07 15:51:01
2009 -0200
+++ b/linux/drivers/staging/go7007/go7007-priv.hTue Nov 10 10:41:56
2009 -0800
@@ -21,6 +21,8 @@
* user-space applications.
*/
+#include media/v4l2-device.h
+
struct go7007;
/* IDs to activate board-specific support code */
@@ -167,6 +169,7 @@
int channel_number; /* for multi-channel boards like Adlink PCI-MPG24 */
char name[64];
struct video_device *video_dev;
+ struct v4l2_device v4l2_dev;
int ref_count;
enum { STATUS_INIT, STATUS_ONLINE, STATUS_SHUTDOWN } status;
spinlock_t spinlock;
@@ -240,6 +243,11 @@
unsigned short interrupt_data;
};
+static inline struct go7007 *to_go7007(struct v4l2_device *v4l2_dev)
+{
+ return container_of(v4l2_dev, struct go7007, v4l2_dev);
+}
+
/* All of these must be called with the hpi_lock mutex held! */
#define go7007_interface_reset(go) \
((go)-hpi_ops-interface_reset(go))
diff -r 19c0469c02c3 -r a603ad1e6a1c linux/drivers/staging/go7007/go7007-usb.c
--- a/linux/drivers/staging/go7007/go7007-usb.c Sat Nov 07 15:51:01 2009 -0200
+++ b/linux/drivers/staging/go7007/go7007-usb.c Tue Nov 10 10:41:56 2009 -0800
@@ -1057,7 +1057,7 @@
usb_rcvintpipe(usb-usbdev, 4),
usb-intr_urb-transfer_buffer, 2*sizeof(u16),
go7007_usb_readinterrupt_complete, go, 8);
- usb_set_intfdata(intf, go);
+ usb_set_intfdata(intf, go-v4l2_dev);
/* Boot the GO7007 */
if (go7007_boot_encoder(go, go-board_info-flags
@@ -1233,7 +1233,7 @@
static void go7007_usb_disconnect(struct usb_interface *intf)
{
- struct go7007 *go = usb_get_intfdata(intf);
+ struct go7007 *go = to_go7007(usb_get_intfdata(intf));
struct go7007_usb *usb = go-hpi_context;
struct urb *vurb, *aurb;
int i;
diff -r 19c0469c02c3 -r a603ad1e6a1c linux/drivers/staging/go7007/go7007-v4l2.c
--- a/linux/drivers/staging/go7007/go7007-v4l2.cSat Nov 07 15:51:01
2009 -0200
[PATCH 2/5] s2250: Mutex function usage.
From: Pete Eberlein p...@sensoray.com
Fix mutex function usage, which was overlooked in a previous patch.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r a603ad1e6a1c -r 99e4a0cf6788 linux/drivers/staging/go7007/s2250-board.c
--- a/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:41:56
2009 -0800
+++ b/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:47:34
2009 -0800
@@ -261,7 +261,7 @@
memset(buf, 0xcd, 6);
usb = go-hpi_context;
- if (down_interruptible(usb-i2c_lock) != 0) {
+ if (mutex_lock_interruptible(usb-i2c_lock) != 0) {
printk(KERN_INFO i2c lock failed\n);
kfree(buf);
return -EINTR;
@@ -270,7 +270,7 @@
kfree(buf);
return -EFAULT;
}
- up(usb-i2c_lock);
+ mutex_unlock(usb-i2c_lock);
*val = (buf[0] 8) | buf[1];
kfree(buf);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] s2250: Change module structure
From: Pete Eberlein p...@sensoray.com
The s2250-board i2c module was converted to use v4l2-i2c-drv.h in
preparation for its subdev conversion. This change prevented the
s2250-loader from being initialized within the same module due to
the module_init and module_exit function definitions in v4l2-i2c-drv.h.
Therefore, s2250-loader is now its own module, and the header for
exporting s2250-loader functions is no longer needed.
The s2250 i2c module name was 2220-board in some places, and was
changed to s2250.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 99e4a0cf6788 -r 5fe2031944d4 linux/drivers/staging/go7007/Makefile
--- a/linux/drivers/staging/go7007/Makefile Tue Nov 10 10:47:34 2009 -0800
+++ b/linux/drivers/staging/go7007/Makefile Tue Nov 10 10:54:51 2009 -0800
@@ -5,7 +5,7 @@
obj-$(CONFIG_VIDEO_GO7007) += go7007.o
obj-$(CONFIG_VIDEO_GO7007_USB) += go7007-usb.o
-obj-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD) += s2250.o
+obj-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD) += s2250.o s2250-loader.o
obj-$(CONFIG_VIDEO_GO7007_SAA7113) += wis-saa7113.o
obj-$(CONFIG_VIDEO_GO7007_OV7640) += wis-ov7640.o
obj-$(CONFIG_VIDEO_GO7007_SAA7115) += wis-saa7115.o
@@ -17,7 +17,7 @@
go7007-objs += go7007-v4l2.o go7007-driver.o go7007-i2c.o go7007-fw.o \
snd-go7007.o
-s2250-objs += s2250-board.o s2250-loader.o
+s2250-objs += s2250-board.o
# Uncomment when the saa7134 patches get into upstream
#ifneq ($(CONFIG_VIDEO_SAA7134),)
diff -r 99e4a0cf6788 -r 5fe2031944d4
linux/drivers/staging/go7007/go7007-driver.c
--- a/linux/drivers/staging/go7007/go7007-driver.c Tue Nov 10 10:47:34
2009 -0800
+++ b/linux/drivers/staging/go7007/go7007-driver.c Tue Nov 10 10:54:51
2009 -0800
@@ -219,7 +219,7 @@
modname = wis-ov7640;
break;
case I2C_DRIVERID_S2250:
- modname = s2250-board;
+ modname = s2250;
break;
default:
modname = NULL;
diff -r 99e4a0cf6788 -r 5fe2031944d4 linux/drivers/staging/go7007/go7007-usb.c
--- a/linux/drivers/staging/go7007/go7007-usb.c Tue Nov 10 10:47:34 2009 -0800
+++ b/linux/drivers/staging/go7007/go7007-usb.c Tue Nov 10 10:54:51 2009 -0800
@@ -425,7 +425,7 @@
.num_i2c_devs= 1,
.i2c_devs= {
{
- .type = s2250_board,
+ .type = s2250,
.id = I2C_DRIVERID_S2250,
.addr = 0x43,
},
diff -r 99e4a0cf6788 -r 5fe2031944d4 linux/drivers/staging/go7007/s2250-board.c
--- a/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:47:34
2009 -0800
+++ b/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:54:51
2009 -0800
@@ -20,10 +20,13 @@
#include linux/usb.h
#include linux/i2c.h
#include linux/videodev2.h
+#include media/v4l2-device.h
#include media/v4l2-common.h
-#include s2250-loader.h
+#include media/v4l2-i2c-drv.h
#include go7007-priv.h
-#include wis-i2c.h
+
+MODULE_DESCRIPTION(Sensoray 2250/2251 i2c v4l2 subdev driver);
+MODULE_LICENSE(GPL v2);
#define TLV320_ADDRESS 0x34
#define VPX322_ADDR_ANALOGCONTROL1 0x02
@@ -575,7 +578,7 @@
dec-audio = audio;
i2c_set_clientdata(client, dec);
- printk(KERN_DEBUG
+ printk(KERN_INFO
s2250: initializing video decoder on %s\n,
adapter-name);
@@ -648,46 +651,20 @@
return 0;
}
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
static struct i2c_device_id s2250_id[] = {
- { s2250_board, 0 },
+ { s2250, 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, s2250_id);
-static struct i2c_driver s2250_driver = {
- .driver = {
- .name = Sensoray 2250 board driver,
- },
- .probe = s2250_probe,
- .remove = s2250_remove,
- .command= s2250_command,
- .id_table = s2250_id,
+#endif
+static struct v4l2_i2c_driver_data v4l2_i2c_data = {
+ .name = s2250,
+ .probe = s2250_probe,
+ .remove = s2250_remove,
+ .command = s2250_command,
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
+ .id_table = s2250_id,
+#endif
};
-
-static int __init s2250_init(void)
-{
- int r;
-
- r = s2250loader_init();
- if (r 0)
- return r;
-
- r = i2c_add_driver(s2250_driver);
- if (r 0)
- s2250loader_cleanup();
-
- return r;
-}
-
-static void __exit s2250_cleanup(void)
-{
- i2c_del_driver(s2250_driver);
-
- s2250loader_cleanup();
-}
-
-module_init(s2250_init);
-module_exit(s2250_cleanup);
-
-MODULE_AUTHOR();
-MODULE_DESCRIPTION(Board driver for Sensoryray 2250);
-MODULE_LICENSE(GPL v2);
diff -r 99e4a0cf6788 -r 5fe2031944d4 linux/drivers/staging/go7007/s2250-loader.c
--- a/linux/drivers/staging/go7007/s2250-loader.c Tue Nov
[PATCH 4/5] s2250: subdev conversion
From: Pete Eberlein p...@sensoray.com
Convert the s2250 i2c driver to use v4l2 subdev interface.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 5fe2031944d4 -r a44341b7bf67 linux/drivers/staging/go7007/s2250-board.c
--- a/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:54:51
2009 -0800
+++ b/linux/drivers/staging/go7007/s2250-board.cTue Nov 10 10:56:51
2009 -0800
@@ -23,6 +23,7 @@
#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-i2c-drv.h
+#include media/v4l2-subdev.h
#include go7007-priv.h
MODULE_DESCRIPTION(Sensoray 2250/2251 i2c v4l2 subdev driver);
@@ -115,6 +116,7 @@
};
struct s2250 {
+ struct v4l2_subdev sd;
v4l2_std_id std;
int input;
int brightness;
@@ -126,6 +128,11 @@
struct i2c_client *audio;
};
+static inline struct s2250 *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct s2250, sd);
+}
+
/* from go7007-usb.c which is Copyright (C) 2005-2006 Micronas USA Inc.*/
static int go7007_usb_vendor_request(struct go7007 *go, u16 request,
u16 value, u16 index, void *transfer_buffer, int length, int in)
@@ -309,253 +316,262 @@
}
-static int s2250_command(struct i2c_client *client,
-unsigned int cmd, void *arg)
+/* - */
+
+static int s2250_s_video_routing(struct v4l2_subdev *sd, u32 input, u32 output,
+u32 config)
{
- struct s2250 *dec = i2c_get_clientdata(client);
+ struct s2250 *state = to_state(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int vidsys;
- switch (cmd) {
- case VIDIOC_S_INPUT:
- {
- int vidsys;
- int *input = arg;
+ vidsys = (state-std == V4L2_STD_NTSC) ? 0x01 : 0x00;
+ if (input == 0) {
+ /* composite */
+ write_reg_fp(client, 0x20, 0x020 | vidsys);
+ write_reg_fp(client, 0x21, 0x662);
+ write_reg_fp(client, 0x140, 0x060);
+ } else if (input == 1) {
+ /* S-Video */
+ write_reg_fp(client, 0x20, 0x040 | vidsys);
+ write_reg_fp(client, 0x21, 0x666);
+ write_reg_fp(client, 0x140, 0x060);
+ } else {
+ return -EINVAL;
+ }
+ state-input = input;
+ return 0;
+}
- vidsys = (dec-std == V4L2_STD_NTSC) ? 0x01 : 0x00;
- if (*input == 0) {
- /* composite */
- write_reg_fp(client, 0x20, 0x020 | vidsys);
- write_reg_fp(client, 0x21, 0x662);
- write_reg_fp(client, 0x140, 0x060);
- } else {
- /* S-Video */
- write_reg_fp(client, 0x20, 0x040 | vidsys);
- write_reg_fp(client, 0x21, 0x666);
- write_reg_fp(client, 0x140, 0x060);
- }
- dec-input = *input;
+static int s2250_s_std(struct v4l2_subdev *sd, v4l2_std_id norm)
+{
+ struct s2250 *state = to_state(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ u16 vidsource;
+
+ vidsource = (state-input == 1) ? 0x040 : 0x020;
+ switch (norm) {
+ case V4L2_STD_NTSC:
+ write_regs_fp(client, vid_regs_fp);
+ write_reg_fp(client, 0x20, vidsource | 1);
break;
+ case V4L2_STD_PAL:
+ write_regs_fp(client, vid_regs_fp);
+ write_regs_fp(client, vid_regs_fp_pal);
+ write_reg_fp(client, 0x20, vidsource);
+ break;
+ default:
+ return -EINVAL;
}
- case VIDIOC_S_STD:
- {
- v4l2_std_id *std = arg;
- u16 vidsource;
+ state-std = norm;
+ return 0;
+}
- vidsource = (dec-input == 1) ? 0x040 : 0x020;
- dec-std = *std;
- switch (dec-std) {
- case V4L2_STD_NTSC:
- write_regs_fp(client, vid_regs_fp);
- write_reg_fp(client, 0x20, vidsource | 1);
- break;
- case V4L2_STD_PAL:
- write_regs_fp(client, vid_regs_fp);
- write_regs_fp(client, vid_regs_fp_pal);
- write_reg_fp(client, 0x20, vidsource);
- break;
- default:
- return -EINVAL;
- }
- break;
- }
- case VIDIOC_QUERYCTRL:
- {
- struct v4l2_queryctrl *ctrl = arg;
- static const u32 user_ctrls[] = {
- V4L2_CID_BRIGHTNESS,
- V4L2_CID_CONTRAST,
- V4L2_CID_SATURATION,
- V4L2_CID_HUE,
-
[PATCH 5/5] go7007: subdev conversion
From: Pete Eberlein p...@sensoray.com
Convert the go7007 driver to v4l2 subdev interface, using v4l2 i2c
subdev functions instead of i2c functions directly. The v4l2 ioctl ops
functions call subdev ops instead of i2c commands.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r a44341b7bf67 -r 76b500418fae
linux/drivers/staging/go7007/go7007-driver.c
--- a/linux/drivers/staging/go7007/go7007-driver.c Tue Nov 10 10:56:51
2009 -0800
+++ b/linux/drivers/staging/go7007/go7007-driver.c Tue Nov 10 11:20:10
2009 -0800
@@ -193,7 +193,8 @@
static int init_i2c_module(struct i2c_adapter *adapter, const char *type,
int id, int addr)
{
- struct i2c_board_info info;
+ struct go7007 *go = i2c_get_adapdata(adapter);
+ struct v4l2_device *v4l2_dev = go-v4l2_dev;
char *modname;
switch (id) {
@@ -225,14 +226,10 @@
modname = NULL;
break;
}
- if (modname != NULL)
- request_module(modname);
- memset(info, 0, sizeof(struct i2c_board_info));
- info.addr = addr;
- strlcpy(info.type, type, I2C_NAME_SIZE);
- if (!i2c_new_device(adapter, info))
+ if (v4l2_i2c_new_subdev(v4l2_dev, adapter, modname, type, addr, NULL))
return 0;
+
if (modname != NULL)
printk(KERN_INFO
go7007: probing for module %s failed\n, modname);
@@ -262,6 +259,11 @@
if (ret 0)
return -1;
+ /* v4l2 init must happen before i2c subdevs */
+ ret = go7007_v4l2_init(go);
+ if (ret 0)
+ return ret;
+
if (!go-i2c_adapter_online
go-board_info-flags GO7007_BOARD_USE_ONBOARD_I2C) {
if (go7007_i2c_init(go) 0)
@@ -282,7 +284,7 @@
go-audio_enabled = 1;
go7007_snd_init(go);
}
- return go7007_v4l2_init(go);
+ return 0;
}
EXPORT_SYMBOL(go7007_register_encoder);
diff -r a44341b7bf67 -r 76b500418fae linux/drivers/staging/go7007/go7007-v4l2.c
--- a/linux/drivers/staging/go7007/go7007-v4l2.cTue Nov 10 10:56:51
2009 -0800
+++ b/linux/drivers/staging/go7007/go7007-v4l2.cTue Nov 10 11:20:10
2009 -0800
@@ -29,6 +29,7 @@
#include linux/videodev2.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/v4l2-subdev.h
#include linux/i2c.h
#include linux/mutex.h
#include linux/uaccess.h
@@ -46,6 +47,9 @@
#defineV4L2_MPEG_VIDEO_ENCODING_MPEG_4 3
#endif
+#define call_all(dev, o, f, args...) \
+ v4l2_device_call_until_err(dev, 0, o, f, ##args)
+
static void deactivate_buffer(struct go7007_buffer *gobuf)
{
int i;
@@ -247,19 +251,23 @@
go-modet_map[i] = 0;
if (go-board_info-sensor_flags GO7007_SENSOR_SCALING) {
- struct video_decoder_resolution res;
+ struct v4l2_format res;
- res.width = width;
+ if (fmt != NULL) {
+ res = *fmt;
+ } else {
+ res.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ res.fmt.pix.width = width;
+ }
+
if (height sensor_height / 2) {
- res.height = height / 2;
+ res.fmt.pix.height = height / 2;
go-encoder_v_halve = 0;
} else {
- res.height = height;
+ res.fmt.pix.height = height;
go-encoder_v_halve = 1;
}
- if (go-i2c_adapter_online)
- i2c_clients_command(go-i2c_adapter,
- DECODER_SET_RESOLUTION, res);
+ call_all(go-v4l2_dev, video, s_fmt, res);
} else {
if (width = sensor_width / 4) {
go-encoder_h_halve = 1;
@@ -385,7 +393,7 @@
}
#endif
-static int mpeg_queryctrl(struct v4l2_queryctrl *ctrl)
+static int mpeg_query_ctrl(struct v4l2_queryctrl *ctrl)
{
static const u32 mpeg_ctrls[] = {
V4L2_CID_MPEG_CLASS,
@@ -973,51 +981,35 @@
struct v4l2_queryctrl *query)
{
struct go7007 *go = ((struct go7007_file *) priv)-go;
+ int id = query-id;
- if (!go-i2c_adapter_online)
- return -EIO;
+ if (0 == call_all(go-v4l2_dev, core, queryctrl, query))
+ return 0;
- i2c_clients_command(go-i2c_adapter, VIDIOC_QUERYCTRL, query);
-
- return (!query-name[0]) ? mpeg_queryctrl(query) : 0;
+ query-id = id;
+ return mpeg_query_ctrl(query);
}
static int vidioc_g_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
struct go7007 *go = ((struct go7007_file *) priv)-go;
- struct v4l2_queryctrl query;
- if (!go-i2c_adapter_online)
-
[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:Tue Nov 10 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13327:19c0469c02c3 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc6-armv5: ERRORS linux-2.6.32-rc6-armv5-davinci: ERRORS 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-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc6-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc6-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS 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-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc6-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc6-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc6-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc6-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc6-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc6): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: soc_camera, v4l2 api, gstreamer: setting errno ?
Hi Philipp,
On Tuesday 10 November 2009 17:13:18 Philipp Wiesner wrote:
I'm having some trouble using gstreamer with soc_camera and am a
modified tw9910 driver. I had difficulties compiling the latest sources
for my target so I'm using old kernel and gstreamer versions. But my
question may still be valid, because the problem doesn't seem to be fixed
and this may be interesting for driver programming in the future.
The part I'm suspecting is
if (v4l2_ioctl (fd, VIDIOC_S_FMT, format) 0) {
if (errno != EINVAL)
goto set_fmt_failed;
[v4l2src_calls.c,1223]
According to V4L2 api documentation drivers should set errno, but all
drivers I've seen in the soc_camera framework (including soc_camera.c)
only 'return -errno'. Should device drivers (like tw9910) set errno or
should soc_camera use return values and set errno? Is it correct that none
of them happens at the moment?
errno is a userspace variable. Kernel drivers return a negative error code
which is stored into errno by the ioctl() function in glibc.
--
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
[PATCH 0/4 v7] Support for TVP7002 in DM365
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Latest changes from Hans included. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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 1/4 v7] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides required chip identification definitions
within v4l2.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..688b7ed 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
@@ -147,9 +150,15 @@ enum {
/* module ths7303: just ident 7303 */
V4L2_IDENT_THS7303 = 7303,
+ /* module ths7353: just ident 7353 */
+ V4L2_IDENT_THS7353 = 7353,
+
/* module adv7343: just ident 7343 */
V4L2_IDENT_ADV7343 = 7343,
+ /* module ths8200: just ident 8200 */
+ V4L2_IDENT_THS8200 = 8200,
+
/* module wm8739: just ident 8739 */
V4L2_IDENT_WM8739 = 8739,
--
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 2/4 v7] Definitions for TVP7002 in DM365
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the required definitions for the TVP7002 driver in DM365. Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com --- drivers/media/video/tvp7002_reg.h | 150 + include/media/tvp7002.h | 54 + 2 files changed, 204 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/tvp7002_reg.h create mode 100644 include/media/tvp7002.h diff --git a/drivers/media/video/tvp7002_reg.h b/drivers/media/video/tvp7002_reg.h new file mode 100644 index 000..0e34ca9 --- /dev/null +++ b/drivers/media/video/tvp7002_reg.h @@ -0,0 +1,150 @@ +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics + * Digitizer with Horizontal PLL registers + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com + * + * This code is partially based upon the TVP5150 driver + * written by Mauro Carvalho Chehab (mche...@infradead.org), + * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com + * and the TVP7002 driver in the TI LSP 2.10.00.14 + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Naming conventions + * -- + * + * FDBK: Feedback + * DIV: Divider + * CTL: Control + * SEL: Select + * IN:Input + * OUT: Output + * R: Red + * G: Green + * B: Blue + * OFF: Offset + * THRS: Threshold + * DGTL: Digital + * LVL: Level + * PWR: Power + * MVIS: Macrovision + * W: Width + * H: Height + * ALGN: Alignment + * CLK: Clocks + * TOL: Tolerance + * BWTH: Bandwidth + * COEF: Coefficient + * STAT: Status + * AUTO: Automatic + * FLD: Field + * L:Line + */ + +#define TVP7002_CHIP_REV 0x00 +#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01 +#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02 +#define TVP7002_HPLL_CRTL 0x03 +#define TVP7002_HPLL_PHASE_SEL 0x04 +#define TVP7002_CLAMP_START0x05 +#define TVP7002_CLAMP_W0x06 +#define TVP7002_HSYNC_OUT_W0x07 +#define TVP7002_B_FINE_GAIN0x08 +#define TVP7002_G_FINE_GAIN0x09 +#define TVP7002_R_FINE_GAIN0x0a +#define TVP7002_B_FINE_OFF_MSBS0x0b +#define TVP7002_G_FINE_OFF_MSBS 0x0c +#define TVP7002_R_FINE_OFF_MSBS 0x0d +#define TVP7002_SYNC_CTL_1 0x0e +#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f +#define TVP7002_SYNC_ON_G_THRS 0x10 +#define TVP7002_SYNC_SEPARATOR_THRS0x11 +#define TVP7002_HPLL_PRE_COAST 0x12 +#define TVP7002_HPLL_POST_COAST0x13 +#define TVP7002_SYNC_DETECT_STAT 0x14 +#define TVP7002_OUT_FORMATTER 0x15 +#define TVP7002_MISC_CTL_1 0x16 +#define TVP7002_MISC_CTL_2 0x17 +#define TVP7002_MISC_CTL_3 0x18 +#define TVP7002_IN_MUX_SEL_1 0x19 +#define TVP7002_IN_MUX_SEL_20x1a +#define TVP7002_B_AND_G_COARSE_GAIN0x1b +#define TVP7002_R_COARSE_GAIN 0x1c +#define TVP7002_FINE_OFF_LSBS 0x1d +#define TVP7002_B_COARSE_OFF 0x1e +#define TVP7002_G_COARSE_OFF0x1f +#define TVP7002_R_COARSE_OFF0x20 +#define TVP7002_HSOUT_OUT_START0x21 +#define TVP7002_MISC_CTL_4 0x22 +#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25 +#define TVP7002_AUTO_LVL_CTL_ENABLE0x26 +#define TVP7002_DGTL_ALC_OUT_MSBS 0x27 +#define TVP7002_AUTO_LVL_CTL_FILTER0x28 +/* Reserved 0x29*/ +#define TVP7002_FINE_CLAMP_CTL 0x2a +#define TVP7002_PWR_CTL0x2b +#define TVP7002_ADC_SETUP 0x2c +#define TVP7002_COARSE_CLAMP_CTL 0x2d +#define TVP7002_SOG_CLAMP 0x2e +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30 +#define TVP7002_ALC_PLACEMENT 0x31 +/* Reserved 0x32 */ +/* Reserved 0x33 */ +#define TVP7002_MVIS_STRIPPER_W0x34 +#define TVP7002_VSYNC_ALGN 0x35 +#define TVP7002_SYNC_BYPASS0x36 +#define TVP7002_L_FRAME_STAT_LSBS 0x37 +#define TVP7002_L_FRAME_STAT_MSBS 0x38 +#define
[PATCH 3/4 v7] TVP7002 driver for DM365
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
drivers/media/video/tvp7002.c | 1475 +
1 files changed, 1475 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..a43cb84
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1475 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ 0
+#define TVP7002_WRITE 1
+#define TVP7002_RESERVED 2
+
+/* Total frame lines information */
+#define TVP7002_LINES_720 0x2EE
+#define TVP7002_LINES_1080 0x465
+
+/* Clocks per line assuming 6.5 MHz internal clock +- 6% */
+#define TVP7002_CPL_1080P_60_LOWER 90
+#define TVP7002_CPL_1080P_60_UPPER 102
+#define TVP7002_CPL_1080_60_LOWER 181
+#define TVP7002_CPL_1080_60_UPPER 205
+#define TVP7002_CPL_1080_50_LOWER 217
+#define TVP7002_CPL_1080_50_UPPER 245
+#define TVP7002_CPL_720P_50_LOWER 163
+#define TVP7002_CPL_720P_50_UPPER 183
+#define TVP7002_CPL_720P_60_LOWER 135
+#define TVP7002_CPL_720P_60_UPPER 153
+
+#define INTERLACED_VIDEO 0
+#define PROGRESSIVE_VIDEO 1
+
+/* Indexes for digital video presets */
+#define INDEX_720P60 0
+#define INDEX_1080I60 1
+#define INDEX_1080I50 2
+#define INDEX_720P50 3
+#define INDEX_1080P60 4
+#define INDEX_480P59_945
+#define INDEX_576P50 6
+
+/* Number of pixels and number of lines per frame for different standards */
+#define NTSC_NUM_ACTIVE_PIXELS (720)
+#define NTSC_NUM_ACTIVE_LINES (480)
+#define PAL_NUM_ACTIVE_PIXELS (720)
+#define PAL_NUM_ACTIVE_LINES(576)
+#define HD_720_NUM_ACTIVE_PIXELS(1280)
+#define HD_720_NUM_ACTIVE_LINES (720)
+#define HD_1080_NUM_ACTIVE_PIXELS (1920)
+#define HD_1080_NUM_ACTIVE_LINES(1080)
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT 5
+#define TVP7002_INPR_MASK (0x01 TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT 8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+ u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+ {
[PATCH 4/4 v7] Menu support for TVP7002 in DM365
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides menu configuration options for the TVP7002 decoder driver in DM365. Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com --- drivers/media/video/Kconfig | 32 drivers/media/video/Makefile |2 ++ 2 files changed, 34 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e6186b3..f33652e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -392,6 +392,15 @@ config VIDEO_TVP5150 To compile this driver as a module, choose M here: the module will be called tvp5150. +config VIDEO_TVP7002 + tristate Texas Instruments TVP7002 video decoder + depends on VIDEO_V4L2 I2C + ---help--- + Support for the Texas Instruments TVP7002 video decoder. + + To compile this driver as a module, choose M here: the + module will be called tvp7002. + config VIDEO_VPX3220 tristate vpx3220a, vpx3216b vpx3214c video decoders depends on VIDEO_V4L2 I2C @@ -466,6 +475,29 @@ config VIDEO_THS7303 To compile this driver as a module, choose M here: the module will be called ths7303. +config VIDEO_THS7353 + tristate THS7353 Video Amplifier + depends on I2C + help + Support for TI THS7353 video amplifier + + To compile this driver as a module, choose M here: the + module will be called ths7353. + +config VIDEO_THS7353_LUMA_CHANNEL + int THS7353 channel number for Luma Input + default 3 + depends on VIDEO_THS7353 + help + Select the luma channel number for the THS7353 input. + + THS7353 has three identical channels. For the component + interface, luma input will be connected to one of these + channels and cb and cr will be connected to other channels + This config option is used to select the luma input channel + number. Possible values for this option are 1,2 or 3. Any + other value will result in value 2. + config VIDEO_ADV7343 tristate ADV7343 video encoder depends on I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index e541932..d9a421a 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -53,9 +53,11 @@ obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o obj-$(CONFIG_VIDEO_THS7303) += ths7303.o +obj-$(CONFIG_VIDEO_THS7353) += ths7353.o obj-$(CONFIG_VIDEO_VINO) += indycam.o obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o obj-$(CONFIG_VIDEO_CS5345) += cs5345.o obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -- 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
RE: OMAP 3 ISP and N900 sensor driver update
Hi Laurent, I have also copied Vaibhav from TI in this email since this is of interesting to his area of work as well. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com Who is working on the CCDC driver for OMAP35xx? Just for the sake of correctness, we're working on an OMAP34xx, not an OMAP35xx. I don't think that makes a big difference though. That is right! As far as I know nobody on our side is currently working on the CCDC driver. We're focusing on the previewer and resizer first. After a week or so, I need to start migrating the CCDC driver to sub device interface so that application can directly configure the parameters with out having to go through video node. Ultimately it is expected that ccdc will have a device node that will allow application to open the device and configure the parameters (in the context of Media controller). But to begin with I intend to port the existing CCDC driver for DM6446 and DM355 to sub device interface. Since the VPFE IPs are common across DM6446 OMAP 35xx, we could use a common sub device across both platforms. Coordinating our efforts on that front would indeed be very nice. Ok. So I this context, could you please update me on the CCDC development on OMAP platform that you work? I haven't checked the Davinci VPFE drivers recently. I suppose they already use the v4l2_subdev interface for their I2C sensors and tuners. If not, that would be the first step. Yes. The vpfe drivers defines all sub device configuration data in the platform specific code and use that information to load up sub devices. Example tvp514x is loaded by vpfe capture driver and also mt9t031. On the OMAP34xx platform, the ISP driver is already somehow separated from the omap34xxcam driver, although not nicely. In a nutshell, here's the current plan. Parts 1 and 2 are already implemented and code is available in Sakari's linux-omap tree. I will check this out some time next week as I am currently tied up with internal release deadline. 1. Board code registers an omap34xxcam platform device. The platform data contains an array of v4l2_subdev_i2c_board_info structures filled with information about all I2C sub-devices (sensor, flash controller, lens controller, ...). vpfe capture does similar things. 2. The omap34xxcam driver is loaded. Its probe function is called with a pointer to the platform device. The driver registers a v4l2_device and creates I2C subdevices using the data supplied through platform data. vpfe capture does similar things.. The vpfe capture is already part of the v4l2 sub system. You can find the code under /drivers/media/video/davinci 3. The omap34xxcam driver calls the ISP core with a pointer to the v4l2_device structure to register all ISP subdevices. The ISP core maintains pointers to the ISP subdevices. I was thinking in similar lines. We could define configuration for the ISP sub devices in the platform code. For example, register IO space for each IP (Preview Engine, Resizer, H3A etc) can be configured at platform level. But how is the sub device operations invoked from the camera driver? Are there wrapper functions in ISP core for each of the operations? As ISP submodules (CCDC, previewer, resizer) are not truly independent, we were not planning to split them into separate kernel modules. The ISP core needs to call explicitly into the submodules for instance to dispatch interrupts. IMO, to re-use, we need to define common operations across all of the ISP sub modules (ccdc ops, resizer ops, preview-ops etc) since at hight level hardware provide similar functions . I am assuming ISP core is a glue layer that load up all of the ISP sub devices and provide function calls to set format, get format, etc, right? Currently vpfe capture is interfaced to ccdc modules through an interface (ccdc_hw_if.h). I am planning to convert it to a sub device. In that case, ccdc along with other sub modules will be loaded up by a vpfe core similar to ISP core. So by standardizing on common operations, we could re-use the IP (sub device) across VPFE and OMAP. I will investigate the OMAP tree that Sakari maintains before starting my development. Also the Resizer and Preview Engine will have to be used for memory to memory operation as well. So re-use from that perspective is needed as well. There was an RFC for this from Samsung recently. Did you have a chance to review this? It should be possible to use a single CCDC code base across multiple platforms. The ISP core module would depend on the CCDC module directly. I'm not sure how the CCDC module should be called though. An omap prefix won't work, as it's used on Davinci as well, and an ISP prefix is too generic. Do you have any internal code name for the ISP device used on Davinci and OMAP platforms ? The ISP is called VPFE in DaVinci. In our internal release, we call it imp (short for image pipeline). We use the name
Re: MSI StarCam Racer - No valid video chain found
Hi Martin, On Wednesday 04 November 2009 23:03:16 Martin Rod wrote: Hi Laurent, I send you log file with trace (kernel 2.6.30.9) Thanks. The log shows that your problem comes from UVC descriptors parsing. This has been fixed in 2.6.31, so you should upgrade to at least that version or install the latest uvcvideo driver. I have tried this kernel (on UBNT RouterStation and OpenWrt) with results: 2.6.28.10. - camera works, I tried only snapshots (I have to use external power for USB, without external power sometimes works, sometimes no ...) 2.6.31.5 - kernel copmpiles ok, but uvcvideo module was missing, I don't know why ... Check that the uvcvideo driver is selected using make menuconfig. -- 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: Hauppauge HVR-1600 cx18 loading problem
On Tue, 2009-11-10 at 12:13 -0500, John Nuszkowski wrote: My new Hauppauge HVR-1600 does not load the firmware. The driver was built using the source from over the weekend. I am using mythbuntu. Below is a modprobe cx18 debug=511 command Any help would greatly be appreciated. [43594.063182] cx18: Start initialization, version 1.2.0 [43594.063306] cx18-0: Initializing card 0 [43594.063312] cx18-0: Autodetected Hauppauge card [43594.063447] cx18-0: info: base addr: 0xdc00 [43594.063450] cx18-0: info: Enabling pci device [43594.063478] cx18 :00:0c.0: PCI INT A - Link[LNKA] - GSI 10 (level, low) - IRQ 10 [43594.063493] cx18-0: info: cx23418 (rev 0) at 00:0c.0, irq: 10, latency: 64, memory: 0xdc00 [43594.063498] cx18-0: info: attempting ioremap at 0xdc00 len 0x0400 [43594.065656] cx18-0: cx23418 revision 0101 (B) [43594.246946] cx18-0: info: GPIO initial dir: cffe/ out: 3001/ [43594.246970] cx18-0: info: activating i2c... [43594.246973] cx18-0: i2c: i2c init [43594.362969] tveeprom 5-0050: Hauppauge model 74041, rev C6B2, serial# 6380357 [43594.362976] tveeprom 5-0050: MAC address is 00-0D-FE-61-5B-45 [43594.362981] tveeprom 5-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) [43594.362987] tveeprom 5-0050: TV standards NTSC(M) (eeprom 0x08) [43594.362991] tveeprom 5-0050: audio processor is CX23418 (idx 38) [43594.362995] tveeprom 5-0050: decoder processor is CX23418 (idx 31) [43594.363000] tveeprom 5-0050: has no radio, has IR receiver, has IR transmitter [43594.363004] cx18-0: Autodetected Hauppauge HVR-1600 [43594.363008] cx18-0: info: NTSC tuner detected [43594.363011] cx18-0: Simultaneous Digital and Analog TV capture supported [43594.542552] IRQ 10/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs [43594.551681] tuner 6-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) [43594.554867] cs5345 5-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [43594.557430] tuner-simple 6-0061: creating new instance [43594.557436] tuner-simple 6-0061: type set to 50 (TCL 2002N) [43594.558186] cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total) [43594.558268] cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total) [43594.558310] cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total) [43594.558351] cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total) [43594.558389] cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total) [43594.558570] cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total) [43594.558732] cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB) [43594.558738] DVB: registering new adapter (cx18) [43594.594104] cx18 :00:0c.0: firmware: requesting v4l-cx23418-cpu.fw [43594.607124] cx18-0: Mismatch at offset 0 OK. That's bad. From messages previous to this, we can obviously access CX23418 registers. This Mismatch at offset 0 message indicates that writes or reads to the memory chip on the HVR-1600 via the PCI bus and the CX23418 are failing. Possible causes are: 1. Repeated PCI bus errors when trying to write or write to the CX23418 memory. 2. A new memory chip is is use on the HVR-1600 and the DRR memory configuration parameters in the HVR-1600 entry in cx18-cards.c are wrong. 3. Writes to CX23418 registers to configure the DDR memory parameters failed. 4. Some other device driver or device DMA engine is errantly writing into CX23418 memory space. Some things you can you do: 1. Pull *all* your PCI cards out of your machine, blow the dust out of the PCI slots, reseat all the cards and try again. This should somewhat mitigate PCI signal problems due to dust and oxidation. 2. In the file cx18-driver.h change the value of #define CX18_MAX_MMIO_WR_RETRIES 10 up from 10 to 20 (or whatever) to increase the number of retries when writing to the CX23418 over the PCI bus. Recompile and install the cx18 driver and test again. 3. If you still have /dev/video* device nodes after modprobe, even though the firmware load failed; compile the v4l-dbg in the v4l-dvb tree and run these commands as root: # v4l2-dbg -d /dev/video1 -S host0: cx23418revision 0x0101 host1: cx23418_843 revision 0x8430 i2c 0x4c: cs5345 revision 0x # v4l2-dbg -d /dev/video1 -c host0 --list-registers=min=0x2c8,max=0x2c80057 ioctl: VIDIOC_DBG_G_REGISTER 00 04 08 0C 10 14 18 1C 02c8: 0001 0003 030c 44220e82 0008 0010 02c80020: 0003 00df1154 000bdef6 0007 02c80040: 0005 These are the registers that hold the DRR ram configuration. These are the values for my HVR-1600. Also # v4l2-dbg -d /dev/video0 -c host0
cx18: Reprise of YUV frame alignment improvements
OK, here's my second attempt at getting rid of cx18 YUV frame alignment and tearing issues. http://linuxtv.org/hg/~awalls/cx18-yuv2 This change primarily implements full scatter-gather buffer handling between the cx18 driver and the CX23418 firmware. That in turn allows me to set the MDL size to have exactly one YUV frame per MDL transfer from the encoder to eliminate frame alignment issues, while using very small buffers that should not have anyone's machine go into a panic. (I also tweaked the VBI transfer size while I was at it.) I'm pretty happy with the results. I can run this set of streams simultaneously from one HVR-1600 and have witnessed no new cx18 driver issues on my machine: YUV: mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc PCM: aplay -f dat /dev/video24 VBI: ~/build/zvbi-0.2.30/test/osc -2 MPEG: mplayer /dev/video0 -cache 8192 ATSC: mplayer dvb://WTTG\ DT -cache 8192 (ALSA or my soundcard couldn't mix together 3 streams of audio out to my speakers though. Only 2 streams, PCM and MPEG audio, were audible). The cx18 default YUV buffer size is now 3 * 33.75 kB = 3 full HM12 macroblock sets that cover 32 screen lines for each macroblock set. A full NTSC frame requires 15 * 33.75 kB and a full PAL frame requires 18 * 33.75 kB which is why I picked 3 * 33.75 kB. I don't anticipate anyone having problems with this new default YUV buffer size of about ~102 kB, since the current default YUV buffer size is 128 kB. (BTW the cx18 driver restricts YUV captures to sizes which are a multiple of 32 lines in height. I believe the reasoning is that the software HM12 decoders may not gracefully handle a partial macroblock set when not a multiple of 32 lines. This changeset is robust enough to handle lifting that restriction, if someone has a smart HM12 decoder that can handle partial macroblocks sensibly.) Could folks give this cx18 code a test to make sure their primary use cases didn't break? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Hauppauge HVR-1600 cx18 loading problem
-- Forwarded message -- From: John Nuszkowski john.nuszkow...@gmail.com Date: Wed, Nov 11, 2009 at 12:13 AM Subject: Re: Hauppauge HVR-1600 cx18 loading problem To: Andy Walls awa...@radix.net See my comments below. On Tue, Nov 10, 2009 at 8:03 PM, Andy Walls awa...@radix.net wrote: On Tue, 2009-11-10 at 12:13 -0500, John Nuszkowski wrote: My new Hauppauge HVR-1600 does not load the firmware. The driver was built using the source from over the weekend. I am using mythbuntu. Below is a modprobe cx18 debug=511 command Any help would greatly be appreciated. [43594.063182] cx18: Start initialization, version 1.2.0 [43594.063306] cx18-0: Initializing card 0 [43594.063312] cx18-0: Autodetected Hauppauge card [43594.063447] cx18-0: info: base addr: 0xdc00 [43594.063450] cx18-0: info: Enabling pci device [43594.063478] cx18 :00:0c.0: PCI INT A - Link[LNKA] - GSI 10 (level, low) - IRQ 10 [43594.063493] cx18-0: info: cx23418 (rev 0) at 00:0c.0, irq: 10, latency: 64, memory: 0xdc00 [43594.063498] cx18-0: info: attempting ioremap at 0xdc00 len 0x0400 [43594.065656] cx18-0: cx23418 revision 0101 (B) [43594.246946] cx18-0: info: GPIO initial dir: cffe/ out: 3001/ [43594.246970] cx18-0: info: activating i2c... [43594.246973] cx18-0: i2c: i2c init [43594.362969] tveeprom 5-0050: Hauppauge model 74041, rev C6B2, serial# 6380357 [43594.362976] tveeprom 5-0050: MAC address is 00-0D-FE-61-5B-45 [43594.362981] tveeprom 5-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) [43594.362987] tveeprom 5-0050: TV standards NTSC(M) (eeprom 0x08) [43594.362991] tveeprom 5-0050: audio processor is CX23418 (idx 38) [43594.362995] tveeprom 5-0050: decoder processor is CX23418 (idx 31) [43594.363000] tveeprom 5-0050: has no radio, has IR receiver, has IR transmitter [43594.363004] cx18-0: Autodetected Hauppauge HVR-1600 [43594.363008] cx18-0: info: NTSC tuner detected [43594.363011] cx18-0: Simultaneous Digital and Analog TV capture supported [43594.542552] IRQ 10/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs [43594.551681] tuner 6-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) [43594.554867] cs5345 5-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [43594.557430] tuner-simple 6-0061: creating new instance [43594.557436] tuner-simple 6-0061: type set to 50 (TCL 2002N) [43594.558186] cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total) [43594.558268] cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total) [43594.558310] cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total) [43594.558351] cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total) [43594.558389] cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total) [43594.558570] cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total) [43594.558732] cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB) [43594.558738] DVB: registering new adapter (cx18) [43594.594104] cx18 :00:0c.0: firmware: requesting v4l-cx23418-cpu.fw [43594.607124] cx18-0: Mismatch at offset 0 OK. That's bad. From messages previous to this, we can obviously access CX23418 registers. This Mismatch at offset 0 message indicates that writes or reads to the memory chip on the HVR-1600 via the PCI bus and the CX23418 are failing. Possible causes are: 1. Repeated PCI bus errors when trying to write or write to the CX23418 memory. 2. A new memory chip is is use on the HVR-1600 and the DRR memory configuration parameters in the HVR-1600 entry in cx18-cards.c are wrong. 3. Writes to CX23418 registers to configure the DDR memory parameters failed. 4. Some other device driver or device DMA engine is errantly writing into CX23418 memory space. Some things you can you do: 1. Pull *all* your PCI cards out of your machine, blow the dust out of the PCI slots, reseat all the cards and try again. This should somewhat mitigate PCI signal problems due to dust and oxidation. Nothing changed. I also moved the card to another PCI slot. 2. In the file cx18-driver.h change the value of #define CX18_MAX_MMIO_WR_RETRIES 10 up from 10 to 20 (or whatever) to increase the number of retries when writing to the CX23418 over the PCI bus. Recompile and install the cx18 driver and test again. Same result. 3. If you still have /dev/video* device nodes after modprobe, even though the firmware load failed; compile the v4l-dbg in the v4l-dvb tree and run these commands as root: # v4l2-dbg -d /dev/video1 -S host0: cx23418 revision 0x0101 host1: cx23418_843 revision 0x8430 i2c 0x4c: cs5345 revision 0x # ./v4l2-dbg -D Failed to open /dev/video0: No such device or address # ls -al /dev/video* crw-rw+ 1 root video 81, 0 2009-11-10 21:52 /dev/video0 crw-rw+ 1 root
Re: [RFC] Global video buffers pool / Samsung SoC's
Hi Guennadi and others, first of all sorry for breaking the thread, but I am new to this list and could not find the message-id of the original mails nor a .mbox format archive for the list :( As I was one of the people giving comments to Guennadi's talk at ELCE, let me give some feedback here, too. I'm currently helping the Samsung System LSI Linux kernel team with bringing their various ports for their ARM SoCs mainline. So far we have excluded much of the multimedia related parts due to the complexity and lack of kernel infrastructure. Let me briefly describe the SoCs in question: They have an ARM9, ARM11 or Cortex-A8 core and multiple video input and output paths, such as * camera interface * 2d acceleration engine * 3d acceleration engine * post-processor (colorspace conversion, scaling, rotating) * LCM output for classic digital RGB+sync interfaces * TV scaler * TV encoder * HDMI interface (simple serial-HDMI with DMA from/to system memory) * Transport Stream interface (MPEG-transport stream input with PID filter which can DMA to system memory * MIPI-HSI LCM output device * Multi-Function codec for H.264 and other stuff * Hardware JPEG codec. plus even some more that I might have missed. One of the issues is that, at least in many current and upcoming products, all those integrated peripherals can only use physically contiguous memory. For the classic output path (e.g. Xorg+EXA+XAA+3D), that is fine. The framebuffer driver can simply allocate some large chunk of physical system memory at boot time, map that into userspace and be happy. This includes things like Xvideo support in the Xserver. Also, HDMI output and TV output can be handled inside X or switch to a new KMS model. However, the input side looks quite different, On the one hand, we have the camera driver, but possibly HDMI input and transport stream input, are less easy. also, given the plethora of such subsytems in a device, you definitely don't want to have one static big boot-time allocation for each of those devices. You don't want to waste that much memory all the time just in case at some time you start an application that actually needs this. Also, it is unlikely that all of the subsystems will operate at the same time. So having an in-kernel allocator for physically contiguous memory is something that is needed to properly support this hardware. At boot time you allocate one big pool, from which you then on-demand allocate and free physically contiguous buffers, even at much later time. Furthermore, think of something like the JPEG codec acceleration, which you also want to use zero-copy from userspace. So userpsace (like libjpeg for decode, or a camera application for encode)would also need to be able to allocate such a buffer inside the kernel for input and output data of the codec, mmap it, put its jpeg data into it and then run the actual codec. How would that relate to the proposed global video buffers pool? Well, I think before thinking strictly about video buffers for camera chips, we have to think much more generically! Also, has anyone investigated if GEM or TTM could be used in unmodified or modified form for this? After all, they are intended to allocate (and possibly map) video buffers... Regards, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) -- 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: [RFC] Video events, version 2.2
On Saturday 24 October 2009 23:56:24 Sakari Ailus wrote:
Ivan T. Ivanov wrote:
Hi Sakari,
Hi,
On Fri, 2009-10-23 at 13:18 +0300, Sakari Ailus wrote:
[clip]
struct v4l2_event {
__u32 count;
__u32 type;
__u32 sequence;
struct timeval timestamp;
Can we use 'struct timespec' here. This will force actual
implementation to use high-resolution source if possible,
and remove hundreds gettimeofday() in user space, which
should be used for event synchronization, with more
power friendly clock_getres(CLOCK_MONOTONIC).
Good point. I originally picked timeval since it was used in
v4l2_buffer. The spec tells to use gettimeofday() for system time but
clock skewing is causes problems in video encoding.
clock_getres(CLOCK_MONOTONIC) is free of clock skewing and thus should
be more suitable for this kind of use.
I also propose to use timespec instead of timeval.
Hi Sakari,
What is that status of the event API? It is my impression that it is pretty
much finished. Sakari, can you make a final 2.3 RFC? Then Guru can take over
and start the implementation.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] V4L: adding digital video timings APIs
On Thursday 05 November 2009 13:56:29 Hans Verkuil wrote: On Friday 23 October 2009 22:44:34 Karicheri, Muralidharan wrote: Hans, following IOCTLS :- - verify the new v4l2_input capabilities flag added - Enumerate available presets using VIDIOC_ENUM_DV_PRESETS - Set one of the supported preset using VIDIOC_S_DV_PRESET - Get current preset using VIDIOC_G_DV_PRESET - Detect current preset using VIDIOC_QUERY_DV_PRESET - Using stub functions in tvp7002, verify VIDIOC_S_DV_TIMINGS and VIDIOC_G_DV_TIMINGS ioctls are received at the sub device. TODOs : - Test it on a 64bit platform - I need help here since I don't have the platform. - Add documentation (Can someone tell me which file to modify in the kernel tree?). Use the spec in media-spec/v4l. [MK] Where can I access this? Is this part of kernel tree (I couldn't find it under Documentation/video4linux/ under the kernel tree? Is it just updating a text file or I need to have some tool installed to access this documentation and update it. This has been moved around quite a bit lately. It is now in linux/Documentation/DocBook/v4l. You build it using 'make media-spec'. Please also add support to v4l2-ctl.cpp in v4l2-apps/util! That's handy for testing. [MK] Are you referring to the following repository for this? http://linuxtv.org/hg/~dougsland/tool/file/5b884b36bbab Is there a way I can do a git clone for this? Both the doc and the v4l2-ctl.cpp utility are in the master hg repository (linuxtv.org/hg/v4l-dvb). The utility can be found here: v4l2-apps/util. Build it using 'make apps'. The patches of the timings API, docs and utils should all be done against the master hg tree since that is that latest and greatest tree. Setting the input/output capabilities should be done in v4l2-ioctl.c rather than in the drivers. All the info you need to set these bits is available in the core after all. [MK] Could you explain this to me? In my prototype, I had tvp5146 that implements S_STD and tvp7002 that implements S_PRESET. Since bridge driver has all the knowledge about the sub devices and their capabilities, it can set the flag for each of the input that it supports (currently I am setting this flag in the board setup file that describes all the inputs using v4l2_input structure). So it is a matter of setting relevant cap flag in this file for each of the input based on what the sub device supports. I am not sure how core can figure this out? The problem is that we don't want to go through all drivers in order to set the input/output capability flags. However, v4l2_ioctl.c can easily check whether the v4l2_ioctl_ops struct has set vidioc_s_std, vidioc_s_dv_preset and/or vidioc_s_dv_timings and fill in the caps accordingly. If this is done before the vidioc_enum_input/output is called, then the driver can override what v4l2_ioctl.c did if that is needed. I also noticed that not all new ioctls are part of video_ops. Aren't they all required? [MK] All new ioctls are supported in video_ops. I am not sure what you are referring to. For sub device ops, only few are required since bridge device can handle the rest. OK. Regards, Hans Hi Murali, What is the status of this? It would be great if we can get this in for 2.6.33. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
Hi Guennadi,
OK, I've looked at this again. See my comments below.
On Friday 30 October 2009 15:01:27 Guennadi Liakhovetski wrote:
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, the API will be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/Makefile|2 +-
drivers/media/video/v4l2-imagebus.c | 218
+++
include/media/v4l2-imagebus.h | 84 ++
include/media/v4l2-subdev.h | 10 ++-
4 files changed, 312 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/v4l2-imagebus.c
create mode 100644 include/media/v4l2-imagebus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..62d8907 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o
omap2cam-objs:= omap24xxcam.o omap24xxcam-dma.o
-videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o
v4l2-imagebus.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-imagebus.c
b/drivers/media/video/v4l2-imagebus.c
new file mode 100644
index 000..e0a3a83
--- /dev/null
+++ b/drivers/media/video/v4l2-imagebus.c
@@ -0,0 +1,218 @@
+/*
+ * Image Bus API
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-imagebus.h
+
+static const struct v4l2_imgbus_pixelfmt imgbus_fmt[] = {
+ [V4L2_IMGBUS_FMT_YUYV] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = YUYV,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_YVYU] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = YVYU,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_UYVY] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = UYVY,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ .name = VYUY,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_8] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .name = VYUY in SMPTE170M,
+ .bits_per_sample= 8,
+ .packing= V4L2_IMGBUS_PACKING_2X8_PADHI,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_VYUY_SMPTE170M_16] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .colorspace = V4L2_COLORSPACE_SMPTE170M,
+ .name = VYUY in SMPTE170M, 16bit,
+ .bits_per_sample= 16,
+ .packing= V4L2_IMGBUS_PACKING_NONE,
+ .order = V4L2_IMGBUS_ORDER_LE,
+ }, [V4L2_IMGBUS_FMT_RGB555] = {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .colorspace = V4L2_COLORSPACE_SRGB,
