Re: [PATCH 1/3 v2] ezx: Add camera support for A780 and A910 EZX phones

2009-11-10 Thread Antonio Ospite
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

2009-11-10 Thread Guennadi Liakhovetski
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

2009-11-10 Thread Michael Trimarchi

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

2009-11-10 Thread Roman Gaufman
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

2009-11-10 Thread Domenico Andreoli
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

2009-11-10 Thread Roman Gaufman
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

2009-11-10 Thread Antonio Ospite
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

2009-11-10 Thread Domenico Andreoli
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

2009-11-10 Thread Laurent Pinchart
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

2009-11-10 Thread Roman Gaufman
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

2009-11-10 Thread Roman Gaufman
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:
 

Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats

2009-11-10 Thread Laurent Pinchart
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 ?

  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. 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.

-- 
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: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client API optional

2009-11-10 Thread Laurent Pinchart
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.

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.

-- 
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] Davinci VPFE Capture: Add support for Control ioctls

2009-11-10 Thread hvaibhav
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

2009-11-10 Thread Guennadi Liakhovetski
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

2009-11-10 Thread Michael Krufky
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

2009-11-10 Thread Guennadi Liakhovetski
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

2009-11-10 Thread Guennadi Liakhovetski
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

2009-11-10 Thread hvaibhav
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

2009-11-10 Thread Philipp Wiesner
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

2009-11-10 Thread Domenico Andreoli
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

2009-11-10 Thread Eric Miao
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

2009-11-10 Thread Devin Heitmueller
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

2009-11-10 Thread Domenico Andreoli
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 Thread Valerio Bontempi
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

2009-11-10 Thread Devin Heitmueller
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

2009-11-10 Thread Randy Dunlap
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 ?

2009-11-10 Thread Philipp Wiesner
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 Thread Roman Gaufman
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

2009-11-10 Thread Michael Trimarchi

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

2009-11-10 Thread Randy Dunlap
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

2009-11-10 Thread John Nuszkowski
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

2009-11-10 Thread Domenico Andreoli
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

2009-11-10 Thread Hans Verkuil
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

2009-11-10 Thread Santiago Nunez-Corrales

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

2009-11-10 Thread Hans Verkuil
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

2009-11-10 Thread Mauro Carvalho Chehab
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.

2009-11-10 Thread Pete Eberlein
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.

2009-11-10 Thread Pete Eberlein
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

2009-11-10 Thread Pete Eberlein
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

2009-11-10 Thread Pete Eberlein
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

2009-11-10 Thread Pete Eberlein
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

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

Results of the daily build of v4l-dvb:

date: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 ?

2009-11-10 Thread Laurent Pinchart
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

2009-11-10 Thread Santiago Nunez-Corrales

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

2009-11-10 Thread santiago . nunez
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

2009-11-10 Thread santiago . nunez
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

2009-11-10 Thread santiago . nunez
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

2009-11-10 Thread santiago . nunez
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

2009-11-10 Thread Karicheri, Muralidharan
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

2009-11-10 Thread Laurent Pinchart
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

2009-11-10 Thread Andy Walls
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

2009-11-10 Thread Andy Walls
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

2009-11-10 Thread John Nuszkowski
-- 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

2009-11-10 Thread Harald Welte
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

2009-11-10 Thread Hans Verkuil
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

2009-11-10 Thread Hans Verkuil
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

2009-11-10 Thread Hans Verkuil
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,