Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)

2009-05-18 Thread tomloh...@gmail.com

hermann pitton a écrit :

Hi,

Am Sonntag, den 17.05.2009, 15:52 +0200 schrieb tomloh...@gmail.com:
  

hermann pitton a écrit :


Hi Anders,

Am Freitag, den 15.05.2009, 11:18 +0200 schrieb Anders Eriksson:
  
  

Success!

I've tracked down the offending change. switch_addr takes on the wrong value
and setting the LNA fails. Here's a i2c dump:

saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c xfer:  20 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  84 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  86 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  94 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  96 
saa7133[0]: i2c xfer:  96 00 
saa7133[0]: i2c xfer:  97 =01 =01 =00 =11 =01 =04 =01 =85 
saa7133[0]: i2c xfer:  96 1f 
saa7133[0]: i2c xfer:  97 =89 
tda8290_probe: tda8290 detected @ 1-004b
tuner' 1-004b: tda829x detected
tuner' 1-004b: Setting mode_mask to 0x0e
tuner' 1-004b: chip found @ 0x96 (saa7133[0])
tuner' 1-004b: tuner 0x4b: Tuner type absent
tuner' i2c attach [addr=0x4b,client=(tuner unset)]
tuner' 1-004b: Calling set_type_addr for type=54, addr=0xff, mode=0x04, 
config=0x01
tuner' 1-004b: set addr for type -1
tuner' 1-004b: defining GPIO callback
saa7133[0]: i2c xfer:  96 1f 
saa7133[0]: i2c xfer:  97 =89 
tda8290_probe: tda8290 detected @ 1-004b
saa7133[0]: i2c xfer:  96 2f 
saa7133[0]: i2c xfer:  97 =00 
saa7133[0]: i2c xfer:  96 21 c0 
saa7133[0]: i2c xfer:  c1 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  c3 =88 
saa7133[0]: i2c xfer:  c5 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  c7 ERROR: NO_DEVICE
saa7133[0]: i2c xfer:  96 21 00 
tda829x 1-004b: setting tuner address to 61
saa7133[0]: i2c xfer:  96 21 c0 
saa7133[0]: i2c xfer:  c3 =08 
tda827x: tda827x_attach:
tda827x: type set to Philips TDA827X
saa7133[0]: i2c xfer:  c3 =08 
tda827x: tda827xa tuner found
tda827x: tda827x_init:
tda827x: tda827xa_sleep:
saa7133[0]: i2c xfer:  c2 30 90 
saa7133[0]: i2c xfer:  96 21 00 
tda829x 1-004b: type set to tda8290+75a
saa7133[0]: i2c xfer:  96 21 c0 
saa7133[0]: i2c xfer:  c2 00 00 00 00 dc 05 8b 0c 04 20 ff 00 00 4b 
saa7133[0]: i2c xfer:  96 21 00 
saa7133[0]: i2c xfer:  96 20 01 
saa7133[0]: i2c xfer:  96 30 6f 
tuner' 1-004b: type set to tda8290+75a
tuner' 1-004b: tv freq set to 400.00
tda829x 1-004b: setting tda829x to system xx
tda829x 1-004b: tda827xa config is 0x01
saa7133[0]: i2c xfer:  96 01 00 
saa7133[0]: i2c xfer:  96 02 00 
saa7133[0]: i2c xfer:  96 00 00 
saa7133[0]: i2c xfer:  96 01 90 
saa7133[0]: i2c xfer:  96 28 14 
saa7133[0]: i2c xfer:  96 0f 88 
saa7133[0]: i2c xfer:  96 05 04 
saa7133[0]: i2c xfer:  96 0d 47 
saa7133[0]: i2c xfer:  96 21 c0 
tda827x: setting tda827x to system xx
tda827x: setting LNA to high gain
saa7133[0]: i2c xfer:  96 22 00 
^ This address is c2 in all kernels = 
5823b3a63c7661272ea7fef7635955e2a50d17eb


saa7133[0]: i2c xfer:  c2 00 32 f8 00 16 3b bb 1c 04 20 00 
saa7133[0]: i2c xfer:  c2 90 ff e0 00 99 
saa7133[0]: i2c xfer:  c2 a0 c0 
saa7133[0]: i2c xfer:  c2 30 10 
saa7133[0]: i2c xfer:  c3 =49 =a4 
tda827x: AGC2 gain is: 10
   ^ The gain reported on good kernels is 3 

Looking at the source, the switch_addr to use in the later kernels is somehow 
autodetected. How that's done, I've yet to fully understand, but somehow it 
comes up with the wrong address.


This patch (which obviously needs improvement) hardwires the address back to 
its original value, and works for 2.6.30-rc5.


diff --git a/drivers/media/common/tuners/tda8290.c 
b/drivers/media/common/tuners/tda8290.c
index 064d14c..498cc7b 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
 
dvb_attach(tda827x_attach, fe, priv-tda827x_addr,

   priv-i2c_props.adap, priv-cfg);
+   tuner_info(ANDERS: setting switch_addr. was 0x%02x, new 
0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr);
priv-cfg.switch_addr = priv-i2c_props.addr;
+   priv-cfg.switch_addr = 0xc2 / 2;
+   tuner_info(ANDERS: new 0x%02x\n,priv-cfg.switch_addr);
+
}
if (fe-ops.tuner_ops.init)
fe-ops.tuner_ops.init(fe);


Could you please help me out and shed some light on what the proper fix is for 
setting switch_addr? 


Thanks,
/Anders




thanks a lot for all your time and energy you did spend on this.

I suggest we start collecting photographs of different LNA circuits on
the wiki.

For now, Tom offered his support already off list, I think we should
start about the question, if that early Hauppauge HVR 1110 has such an
LNA type one at all, since this caused to not look at it further, as it
seemed to be without problems.

Tom, I know you carefully worked on it, but can you reassure that this
LNA config one is really needed on your device?

  
  


Re: [PATCH] [0905_10] Siano - perform clean multi-modules build

2009-05-18 Thread Mauro Carvalho Chehab
Em Thu, 14 May 2009 12:26:18 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com escreveu:

 
 # HG changeset patch
 # User Uri Shkolnik u...@siano-ms.com
 # Date 1242323350 -10800
 # Node ID f93a86c6f9785cb60e015e811ddfca6850135887
 # Parent  0018ed9bbca31e76a17ead56e2e953c325c7cf3f
 [0905_10] Siano - perform clean multi-modules build
 
 From: Uri Shkolnik u...@siano-ms.com
 
 Clean up the multi dynamic module build, so no warning/errors
 will occur either with clean kernel git or Siano's repository.
 
 Priority: normal
 
 Signed-off-by: Uri Shkolnik u...@siano-ms.com
 
 diff -r 0018ed9bbca3 -r f93a86c6f978 linux/drivers/media/dvb/siano/Kconfig
 --- a/linux/drivers/media/dvb/siano/Kconfig   Tue May 12 16:13:13 2009 +
 +++ b/linux/drivers/media/dvb/siano/Kconfig   Thu May 14 20:49:10 2009 +0300
 @@ -2,25 +2,74 @@
  # Siano Mobile Silicon Digital TV device configuration
  #
  
 -config DVB_SIANO_SMS1XXX
 - tristate Siano SMS1XXX USB dongle support
 - depends on DVB_CORE  USB
 +config SMS_SIANO_MDTV

Please start with DVB for all DVB config options. The same comment is valid
also to the SMS suboptions bellow.

 + tristate Siano SMS1xxx based MDTV receiver
 + default m
   ---help---
 -   Choose Y here if you have a USB dongle with a SMS1XXX chipset.
 + Choose Y or M here if you have MDTV receiver with a Siano chipset.
  
 -   To compile this driver as a module, choose M here: the
 -   module will be called sms1xxx.
 + To compile this driver as a module, choose M here
 + (The modules will be called smsmdtv).
  
 -config DVB_SIANO_SMS1XXX_SMS_IDS
 - bool Enable support for Siano Mobile Silicon default USB IDs
 - depends on DVB_SIANO_SMS1XXX
 - default y
 + Note: All dependents, if selected, will be part of this module.
 +
 + Further documentation on this driver can be found on the WWW at 
 http://www.siano-ms.com/

Please don't use more than 80 characters per line.

 +
 +if SMS_SIANO_MDTV
 +menu Siano module components
 +
 +# Kernel sub systems support
 +config SMS_DVB3_SUBSYS
 + tristate DVB v.3 Subsystem support
 + depends on DVB_CORE
 + default m if DVB_CORE
   ---help---
 -   Choose Y here if you have a USB dongle with a SMS1XXX chipset
 -   that uses Siano Mobile Silicon's default usb vid:pid.
 + Choose if you would like to have DVB v.3 kernel sub-system support.
  
 -   Choose N here if you would prefer to use Siano's external driver.
 +#config SMS_DVB5_S2API_SUBSYS
 +#tristate DVB v.5 (S2 API) Subsystem support
 +#default n
 +#---help---
 +#Choose if you would like to have DVB v.5 (S2 API) kernel sub-system 
 support.
 +#
 +#config SMS_HOSTLIB_SUBSYS
 +#tristate Host Library Subsystem support
 +#default n
 +#---help---
 +#Choose if you would like to have Siano's host library kernel sub-system 
 support.
 +#
 +#if SMS_HOSTLIB_SUBSYS
 +#
 +#config SMS_NET_SUBSYS
 +#tristate Siano Network Adapter
 +#depends on SMS_HOSTLIB_SUBSYS
 +#default n
 +#---help---
 +#Choose if you would like to have Siano's network adapter support.
 +#endif # SMS_HOSTLIB_SUBSYS

Don't add something commented above. Also, please be sure that, before adding
those Kconfig items, that the driver will support compilation with all
alternatives.
  
 -   Further documentation on this driver can be found on the WWW at
 -   http://www.siano-ms.com/.
 +# Hardware interfaces support
  
 +config SMS_USB_DRV
 + tristate USB interface support
 + depends on USB
 + default m if USB
 + ---help---
 + Choose if you would like to have Siano's support for USB interface
 +
 +config SMS_SDIO_DRV
 + tristate SDIO interface support
 + depends on MMC
 + default m if MMC
 + ---help---
 + Choose if you would like to have Siano's support for SDIO interface
 +
 +#config SMS_SPI_PXA310_DRV
 +#tristate PXA 310 SPI interface support
 +#depends on ARM  ARCH_PXA  MACH_ZYLONITE  PXA_SSP  SPI
 +#default m if ARM  ARCH_PXA  MACH_ZYLONITE  PXA_SSP  SPI
 +#---help---
 +#Choose if you would like to have Siano's support for PXA 310 SPI 
 interface

Idem.

 +
 +endmenu
 +endif # SMS_SIANO_MDTV
 diff -r 0018ed9bbca3 -r f93a86c6f978 linux/drivers/media/dvb/siano/Makefile
 --- a/linux/drivers/media/dvb/siano/Makefile  Tue May 12 16:13:13 2009 +
 +++ b/linux/drivers/media/dvb/siano/Makefile  Thu May 14 20:49:10 2009 +0300
 @@ -1,8 +1,9 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
 -sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
 +smsmdtv-objs := smscoreapi.o sms-cards.o smsendian.o
  
 -obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
 -obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
 -obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsdvb.o
 +obj-$(CONFIG_SMS_SIANO_MDTV) += smsmdtv.o
 +obj-$(CONFIG_SMS_USB_DRV) += smsusb.o
 +obj-$(CONFIG_SMS_DVB3_SUBSYS) += smsdvb.o
 +#obj-$(CONFIG_SMS_SDIO_DRV) += smssdio.o

Please, don't add a commented line here. Just submit a Kconfig addition for

Re: [PATCH]saa7134-video.c: poll method lose race condition

2009-05-18 Thread Guennadi Liakhovetski
On Mon, 18 May 2009, figo.zhang wrote:

 saa7134-video.c: poll method lose race condition
 
 
 Signed-off-by: Figo.zhang figo.zh...@kolorific.com

Hi,

I am not sure why you decide to cc me on your sa7a34 patches. Those are 
not the kind of devices I'm working with, so, don't think I'll be able to 
help with your patches.

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] [0905_14] Siano: USB - move the device id table to the cards module

2009-05-18 Thread Mauro Carvalho Chehab
Em Thu, 14 May 2009 12:29:35 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com escreveu:

 
 # HG changeset patch
 # User Uri Shkolnik u...@siano-ms.com
 # Date 1242325466 -10800
 # Node ID fe5ecbb828340406923d06b4ea93a210aafb5c7e
 # Parent  5a6de44c39c9198bc1af79f5901dc769690885de
 [0905_14] Siano: USB - move the device id table to the cards module
 
 From: Uri Shkolnik u...@siano-ms.com
 
 The card modules is the component which handles various targets,
 so the IDs table should reside within it.

The idea of moving it to sms-cards.c is interesting, however, I don't think
this will work fine, since having the usb probing code at one module and the
table on another will break for udev.

Also, by applying this patch, module loader would be broken:

WARNING: smsusb_id_table [/home/v4l/master/v4l/smsusb.ko] undefined!

I can see a few alternatives:

1) keep as-is;
2) move usb init code to sms-cards;
3) break sms-cards into smaller files, like sms-cards-usb (for usb devices);
4) having the table declared as static into some header file.

Due to that, I'll have to skip a few patches that are ok (the ones that are
just adding newer devices at the table).

Cheers,
Mauro.

 
 Priority: normal
 
 Signed-off-by: Uri Shkolnik u...@siano-ms.com
 
 diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/sms-cards.c
 --- a/linux/drivers/media/dvb/siano/sms-cards.c   Thu May 14 21:14:46 
 2009 +0300
 +++ b/linux/drivers/media/dvb/siano/sms-cards.c   Thu May 14 21:24:26 
 2009 +0300
 @@ -18,6 +18,51 @@
   */
  
  #include sms-cards.h
 +
 +struct usb_device_id smsusb_id_table[] = {
 + { USB_DEVICE(0x187f, 0x0010),
 + .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
 + { USB_DEVICE(0x187f, 0x0100),
 + .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
 + { USB_DEVICE(0x187f, 0x0200),
 + .driver_info = SMS1XXX_BOARD_SIANO_NOVA_A },
 + { USB_DEVICE(0x187f, 0x0201),
 + .driver_info = SMS1XXX_BOARD_SIANO_NOVA_B },
 + { USB_DEVICE(0x187f, 0x0300),
 + .driver_info = SMS1XXX_BOARD_SIANO_VEGA },
 + { USB_DEVICE(0x2040, 0x1700),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT },
 + { USB_DEVICE(0x2040, 0x1800),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A },
 + { USB_DEVICE(0x2040, 0x1801),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B },
 + { USB_DEVICE(0x2040, 0x2000),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
 + { USB_DEVICE(0x2040, 0x2009),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2 },
 + { USB_DEVICE(0x2040, 0x200a),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
 + { USB_DEVICE(0x2040, 0x2010),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
 + { USB_DEVICE(0x2040, 0x2011),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
 + { USB_DEVICE(0x2040, 0x2019),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
 + { USB_DEVICE(0x2040, 0x5500),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { USB_DEVICE(0x2040, 0x5510),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { USB_DEVICE(0x2040, 0x5520),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { USB_DEVICE(0x2040, 0x5530),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { USB_DEVICE(0x2040, 0x5580),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { USB_DEVICE(0x2040, 0x5590),
 + .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 + { } /* Terminating entry */
 +};
 +MODULE_DEVICE_TABLE(usb, smsusb_id_table);
  
  static int sms_dbg;
  module_param_named(cards_dbg, sms_dbg, int, 0644);
 diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/sms-cards.h
 --- a/linux/drivers/media/dvb/siano/sms-cards.h   Thu May 14 21:14:46 
 2009 +0300
 +++ b/linux/drivers/media/dvb/siano/sms-cards.h   Thu May 14 21:24:26 
 2009 +0300
 @@ -45,6 +45,8 @@ struct sms_board {
  
  struct sms_board *sms_get_board(int id);
  
 +extern struct usb_device_id smsusb_id_table[];
 +
  int sms_board_setup(struct smscore_device_t *coredev);
  
  #define SMS_LED_OFF 0
 diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/smsusb.c
 --- a/linux/drivers/media/dvb/siano/smsusb.c  Thu May 14 21:14:46 2009 +0300
 +++ b/linux/drivers/media/dvb/siano/smsusb.c  Thu May 14 21:24:26 2009 +0300
 @@ -488,53 +488,6 @@ static int smsusb_resume(struct usb_inte
   return 0;
  }
  
 -struct usb_device_id smsusb_id_table[] = {
 -#ifdef CONFIG_DVB_SIANO_SMS1XXX_SMS_IDS
 - { USB_DEVICE(0x187f, 0x0010),
 - .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
 - { USB_DEVICE(0x187f, 0x0100),
 - .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
 - { USB_DEVICE(0x187f, 0x0200),
 - .driver_info = 

Re: [PATCH]saa7134-video.c: poll method lose race condition

2009-05-18 Thread figo.zhang
On Mon, 2009-05-18 at 08:28 +0200, Guennadi Liakhovetski wrote:
 Guennadi

hi,Guennadi,

I am sorry that it is my mistake.

Figo.zhang

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


Re: V4L2 - Capturing uncompressed data

2009-05-18 Thread Guillaume

  It depends on the camera.
 
 ...and the driver. I don't know much about various _web_cameras and their 
 drivers, but I could well imagine, that you're asking for an unsupported 
 YUV variation, whereas some other format would be supported. Why don't you 
 use VIDIOC_ENUM_FMT to list all supported formats? Or even look in the 
 driver source - it's open
 


Hi,
Thanks for your answer. I didn't try ENUM_FMT but I tried to set every available
format of V4L2 (that we can found in the videodev2.h), but the only one
possible is the compressed JPEG Format.

You said to look in the driver source, but where exactly do I have to look for ?

Thank you for your time,

Regards,
Guillaume.



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


Re: [PATCH] [0905_23] Siano: gpio - use new implementation

2009-05-18 Thread Mauro Carvalho Chehab
Em Sun, 17 May 2009 01:57:45 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com escreveu:

 
 # HG changeset patch
 # User Uri Shkolnik u...@siano-ms.com
 # Date 1242331325 -10800
 # Node ID 415ca02f74b960c02ddfa7ee719cf87726d97490
 # Parent  8b645aa2ab13f22b8d4dcd8e6353fce2c976cd34
 [0905_23] Siano: gpio - use new implementation
 
 From: Uri Shkolnik u...@siano-ms.com
 
 Start using the corrected gpio implementation

Hmm...

WARNING: smscore_configure_gpio [/home/v4l/master/v4l/sms1xxx.ko] undefined!
WARNING: smscore_set_gpio [/home/v4l/master/v4l/sms1xxx.ko] undefined!

Those functions weren't defined on any module. It seems that you forgot to
submit a previous patch.

Also, since Hauppauge complained about the gpio changes, I'd like to have
Michael's ack, especially if the patch affects the behavior of the existing
Hauppauge supported boards.

Cheers,
Mauro.


 
 Priority: normal
 
 Signed-off-by: Uri Shkolnik u...@siano-ms.com
 
 diff -r 8b645aa2ab13 -r 415ca02f74b9 linux/drivers/media/dvb/siano/sms-cards.c
 --- a/linux/drivers/media/dvb/siano/sms-cards.c   Thu May 14 22:28:38 
 2009 +0300
 +++ b/linux/drivers/media/dvb/siano/sms-cards.c   Thu May 14 23:02:05 
 2009 +0300
 @@ -17,6 +17,7 @@
   *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
   */
  
 +#include smscoreapi.h
  #include sms-cards.h
  #include smsir.h
  
 @@ -155,6 +156,174 @@ struct sms_board *sms_get_board(int id)
  }
  EXPORT_SYMBOL_GPL(sms_get_board);
  
 +static inline void sms_gpio_assign_11xx_default_led_config(
 + struct smscore_gpio_config *pGpioConfig) {
 + pGpioConfig-Direction = SMS_GPIO_DIRECTION_OUTPUT;
 + pGpioConfig-InputCharacteristics =
 + SMS_GPIO_INPUTCHARACTERISTICS_NORMAL;
 + pGpioConfig-OutputDriving = SMS_GPIO_OUTPUTDRIVING_4mA;
 + pGpioConfig-OutputSlewRate = SMS_GPIO_OUTPUTSLEWRATE_0_45_V_NS;
 + pGpioConfig-PullUpDown = SMS_GPIO_PULLUPDOWN_NONE;
 +}
 +
 +int sms_board_event(struct smscore_device_t *coredev,
 + enum SMS_BOARD_EVENTS gevent) {
 + int board_id = smscore_get_board_id(coredev);
 + struct sms_board *board = sms_get_board(board_id);
 + struct smscore_gpio_config MyGpioConfig;
 +
 + sms_gpio_assign_11xx_default_led_config(MyGpioConfig);
 +
 + switch (gevent) {
 + case BOARD_EVENT_POWER_INIT: /* including hotplug */
 + switch (board_id) {
 + case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
 + /* set I/O and turn off all LEDs */
 + smscore_gpio_configure(coredev,
 + board-board_cfg.leds_power,
 + MyGpioConfig);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.leds_power, 0);
 + smscore_gpio_configure(coredev, board-board_cfg.led0,
 + MyGpioConfig);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.led0, 0);
 + smscore_gpio_configure(coredev, board-board_cfg.led1,
 + MyGpioConfig);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.led1, 0);
 + break;
 + case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
 + case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
 + /* set I/O and turn off LNA */
 + smscore_gpio_configure(coredev,
 + board-board_cfg.foreign_lna0_ctrl,
 + MyGpioConfig);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.foreign_lna0_ctrl,
 + 0);
 + break;
 + }
 + break; /* BOARD_EVENT_BIND */
 +
 + case BOARD_EVENT_POWER_SUSPEND:
 + switch (board_id) {
 + case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.leds_power, 0);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.led0, 0);
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.led1, 0);
 + break;
 + case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
 + case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
 + smscore_gpio_set_level(coredev,
 + board-board_cfg.foreign_lna0_ctrl,
 + 0);
 + break;
 + }
 + break; /* BOARD_EVENT_POWER_SUSPEND */
 +
 + case BOARD_EVENT_POWER_RESUME:
 + switch (board_id) {
 + case 

Re: [PATCH 0/8] ir-kbd-i2c conversion to the new i2c binding model (v3)

2009-05-18 Thread Jean Delvare
On Sun, 17 May 2009 16:55:54 -0500 (CDT), Mike Isely wrote:
 On Wednesday 13 of May 2009 at 21:45:59, Jean Delvare wrote:
  Here comes an update of my conversion of ir-kbd-i2c to the new i2c
  binding model. I've split it into 8 pieces for easier review. Firstly
  there is 1 preliminary patch:
  (...)

 I tried the all-in-one patch here on a PVR-USB2 24xxx model (slightly 
 older v4l-dvb repo and 2.6.27.13 vanilla kernel) and it worked fine.  
 I'll add an acked-by to the corresponding (trivial) pvrusb2 patch that 
 you've posted.

Thanks for the testing Mike.

Mauro, I think it's time to add these patches to the v4l-dvb repository
so that they get broader testing.

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


Re: V4L2 - Capturing uncompressed data

2009-05-18 Thread Guillaume
Guillaume Kowaio at gmail.com writes:


I just tried the ENUM_FMT, and there is only 1 format, 
the JPEG one.

But I don't understand one thing. The webcam displays 
compressed Jpeg data. OK.
But before that compression, the data aren't in 
uncompressed data ? 
It's the driver or something which is doing that 
compression directly during the capture, but there 
really are no chance to get that uncompressed 
data before compression in JPEG ?

--
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] cx23885: support for card Mygica X8506 DMB-TH

2009-05-18 Thread David Wong
This patch add cx23885 support for card Mygica X8506 DMB-TH.
It should work on Magic-Pro ProHDTV Extreme as well, as they are
same hardware with different branding.

Cheers,
David T.L. Wong
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c	Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c	Mon May 18 15:53:25 2009 +0800
@@ -198,6 +198,10 @@
 		.name		= Hauppauge WinTV-HVR1210,
 		.portc		= CX23885_MPEG_DVB,
 	},
+	[CX23885_BOARD_MYGICA_X8506] = {
+		.name		= Mygica X8506 DMB-TH,
+		.portb		= CX23885_MPEG_DVB,
+	},
 };
 const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
 
@@ -317,6 +321,10 @@
 		.subvendor = 0x0070,
 		.subdevice = 0x2295,
 		.card  = CX23885_BOARD_HAUPPAUGE_HVR1210,
+	}, {
+		.subvendor = 0x14f1,
+		.subdevice = 0x8651,
+		.card  = CX23885_BOARD_MYGICA_X8506,
 	},
 };
 const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -707,6 +715,15 @@
 		mdelay(20);
 		cx23885_gpio_set(dev, GPIO_9);
 		break;
+	case CX23885_BOARD_MYGICA_X8506:
+		/* GPIO-1 reset XC5000 */
+		/* GPIO-2 reset LGS8GL5 */
+		cx_set(GP0_IO, 0x0006);
+		cx_clear(GP0_IO, 0x0006);
+		mdelay(100);
+		cx_set(GP0_IO, 0x00060006);
+		mdelay(100);
+		break;
 	}
 }
 
@@ -810,6 +827,11 @@
 		ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
 		ts2-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
 		break;
+	case CX23885_BOARD_MYGICA_X8506:
+		ts1-gen_ctrl_val  = 0x5; /* Parallel */
+		ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
+		ts1-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+		break;
 	case CX23885_BOARD_HAUPPAUGE_HVR1250:
 	case CX23885_BOARD_HAUPPAUGE_HVR1500:
 	case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c	Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c	Mon May 18 15:53:25 2009 +0800
@@ -50,6 +50,7 @@
 #include lnbh24.h
 #include cx24116.h
 #include cimax2.h
+#include lgs8gxx.h
 #include netup-eeprom.h
 #include netup-init.h
 #include lgdt3305.h
@@ -417,10 +418,29 @@
 	.demod_address = 0x05,
 };
 
+static struct lgs8gxx_config mygica_x8506_lgs8gl5_config = {
+	.prod = LGS8GXX_PROD_LGS8GL5,
+	.demod_address = 0x19,
+	.serial_ts = 0,
+	.ts_clk_pol = 1,
+	.ts_clk_gated = 1,
+	.if_clk_freq = 30400, /* 30.4 MHz */
+	.if_freq = 5380, /* 5.38 MHz */
+	.if_neg_center = 1,
+	.ext_adc = 0,
+	.adc_signed = 0,
+	.if_neg_edge = 0,
+};
+
+static struct xc5000_config mygica_x8506_xc5000_config = {
+	.i2c_address = 0x61,
+	.if_khz = 5380,
+};
+
 static int dvb_register(struct cx23885_tsport *port)
 {
 	struct cx23885_dev *dev = port-dev;
-	struct cx23885_i2c *i2c_bus = NULL;
+	struct cx23885_i2c *i2c_bus = NULL, *i2c_bus2 = NULL;
 	struct videobuf_dvb_frontend *fe0;
 	int ret;
 
@@ -742,6 +762,19 @@
 			break;
 		}
 		break;
+	case CX23885_BOARD_MYGICA_X8506:
+		i2c_bus = dev-i2c_bus[0];
+		i2c_bus2 = dev-i2c_bus[1];
+		fe0-dvb.frontend = dvb_attach(lgs8gxx_attach,
+			mygica_x8506_lgs8gl5_config,
+			i2c_bus-i2c_adap);
+		if (fe0-dvb.frontend != NULL) {
+			dvb_attach(xc5000_attach,
+fe0-dvb.frontend,
+i2c_bus2-i2c_adap,
+mygica_x8506_xc5000_config);
+		}
+		break;
 	default:
 		printk(KERN_INFO %s: The frontend of your DVB/ATSC card 
 			 isn't supported yet\n,
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h	Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885.h	Mon May 18 15:53:25 2009 +0800
@@ -76,6 +76,7 @@
 #define CX23885_BOARD_HAUPPAUGE_HVR127519
 #define CX23885_BOARD_HAUPPAUGE_HVR125520
 #define CX23885_BOARD_HAUPPAUGE_HVR121021
+#define CX23885_BOARD_MYGICA_X8506 22
 
 #define GPIO_0 0x0001
 #define GPIO_1 0x0002


Re: [PATCH] cx23885: support for card Mygica X8506 DMB-TH

2009-05-18 Thread David Wong
Sign-off-by: David T.L. Wong davidtlw...@gmail.com

On Mon, May 18, 2009 at 4:25 PM, David Wong davidtlw...@gmail.com wrote:
 This patch add cx23885 support for card Mygica X8506 DMB-TH.
 It should work on Magic-Pro ProHDTV Extreme as well, as they are
 same hardware with different branding.

 Cheers,
 David T.L. Wong

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


SNR Signal Strength an d BER

2009-05-18 Thread Mike Booth
I have the good fortune to be the 'lucky' owner of an stb0899/stb6100 based 
DVB card. 

Whilst the performance of the card is fine, at least as good as the two other 
s1 TT cards I have, I find it really frustrating that I can't use it in the 
way that I can the other two.


I use them, together with the femon and rotor plugins, to tune up my roof 
mounted dishes. with the s1 cards I can see that I am getting closer from the 
displays, but with the s2.. nothing.

I have been keeping my eye on the list for ages hoping that there will be some 
advancement in this area and although there was quite some discussion in 
March about the right way to interpret these stats., that dried up at the end 
of March with nothing further since.

I am only a User having no development skills so can't help in that area
but I do know that I want measurements that get bigger as dish alignment gets 
better. I really don't give a knack what units are used.

I don't want to start world war 3 ( or even another interminable and seemingly 
fruitless discussion ) but can someone in the development team tell me what 
is being done, if anything, to incorporate SNR SS and BER in STB0899/STB6100 
drivers. Lets face it these drivers have been around for quite some time and 
my guess would be that Technotrend cards represent a fair proportion of the 
total out there.

Regards


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: V4L2 - Capturing uncompressed data

2009-05-18 Thread Laurent Pinchart
Hi Guillaume,

On Monday 18 May 2009 09:32:53 Guillaume wrote:
 Guillaume Kowaio at gmail.com writes:


 I just tried the ENUM_FMT, and there is only 1 format, the JPEG one.

 But I don't understand one thing. The webcam displays compressed Jpeg data.
 OK.
 But before that compression, the data aren't in uncompressed data ?
 It's the driver or something which is doing that compression directly during
 the capture, but there really are no chance to get that uncompressed data
 before compression in JPEG ?

The video stream is compressed directly by the webcam and sent to the host in 
compressed form.

Best regards,

Laurent Pinchart

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


Re: V4L2 - Capturing uncompressed data

2009-05-18 Thread Guillaume
Laurent Pinchart laurent.pinchart at skynet.be writes:


 The video stream is compressed directly by the webcam and sent to the host in 
 compressed form.
 
 Best regards,
 
 Laurent Pinchart

I spoke with my supervisor. He'll try to get a camera 
which allow uncompressed format.
In the meantime, and in order to do stop-motion 
in the application, I need to get the best quality possible 
of the webcam in one 'shot' (not video, just picture).
Is there any way to get the value of compression of the jpeg
by the V4L2 in order to do a software extrapolation after.

For instance, with some webcams (1.3 millions pixels), 
you can capture a 640*480 resolution in video mode
but some allow pictures in 800*600 by extrapolation.

So in order to do that extrapolation, I need the value
of compression of the JPEG use by V4L2. Is it always the same,
or it depends on the camera ? And can v4l2 get and modify this value ?


--
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: SNR Signal Strength an d BER

2009-05-18 Thread Frank Scherthan
Mike Booth schrieb:
 I am only a User having no development skills so can't help in that area
 but I do know that I want measurements that get bigger as dish alignment gets 
 better. I really don't give a knack what units are used.

Just want to say, that I want SNR and BER, too.

I don't care what is displayed, as long as MORE means BETTER and LESS
means WORSE.
That is enough to set up my dish...


Frank

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


xc5000 users: new firmware required!

2009-05-18 Thread Devin Heitmueller
The new xc5000 code was merged this morning, which requires users to
update their firmware.  If you updated to the latest v4l-dvb and your
card stopped working, please download the updated firmware from this
location, and install into the same directory as your previous version
(typically /lib/firmware).

http://www.kernellabs.com/firmware/xc5000/

Thanks,

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


Hauppauge Nova-TD-500 vs. T-500

2009-05-18 Thread Thierry Lelegard
Hello,

Like many others, I have some problems with the Hauppauge Nova-TD-500.

I have been running a Fedora system with one Hauppauge Nova-T-500
(-T-, with one input connector, not -TD-) quite successfully for 2 years.
I just built another Fedora system and ordered two T-500 but I actually
received two TD-500 (the one with two input connectors).

So, I now have another Fedora box with two Hauppauge Nova-TD-500
and it does not work quite well.

The two systems (the first one with one T-500 and the second one with
two TD-500) are running the same O/S version, same drivers, same firmware:

- Fedora 10, up-to-date as of 2009-05-17
- Kernel 2.6.27.21-170.2.56.fc10.i686
- Latest V4L-DVB mercurial tree, same date
- Firmware dvb-usb-dib0700-1.20.fw

You will find below some outputs of dmesg, lspci, etc for the two
systems.

I use custom signal monitoring applications, no TV watching apps.
The same application is used in both systems, same antenna input
(roof antenna and wall socket, not the small antenna that comes
with the cards). The application continuously reads the complete
transport stream for analysis. From time to time, it tunes to
some frequency, then another, etc.

With the two TD-500, the 4 adapters are created under /dev/dvb. Using
them works more or less. As far as I tested now, I do not have any
reported error, no error message. But the input is not good: many
packets are corrupted. This does not happen all the time. Sometimes,
the input is reasonably correct (a few packets seems incorrect)
and sometimes it is a mess (most packets are incorrect, the result
of the analysis report many non-existing PIDs, weird content, etc).

I guess that most of you will say most probably an application pb...
But the same application is working fine with:

1) Linux + Hauppauge Nova-T-500
2) Linux + Hauppauge Nova-T Stick
3) Linux + Pinnacle PCTV stick 72e
4) Windows + the two above sticks
4) Windows + Terratec Cinergy T USB XE Rev 2 (not supported on Linux)

Of course, on Windows, the input module is a custom DirectShow capture
filter instead of Linux DVB API but the rest of the application is identical.

Another weird behaviour: After running the monitoring application,
ioctl (frontend_fd, FE_GET_INFO, ...) returns No such device errno.
Example:

1) Run tool to get dvb device info, ie. ioctl FE_GET_INFO, right
   after system boot:

/dev/dvb/adapter0 (DiBcom 7000PC, DVB-T)

  Status:

  Bit error rate . 2,097,151 (0%)
  Signal/noise ratio . 0 (0%)
  Signal strength  0 (0%)
  Uncorrected blocks . 0
  Frequencies:
Current .. 0 Hz
Min . 45,000,000 Hz
Max  860,000,000 Hz
Step  62,500 Hz
Tolerance  0 Hz
  Spectral inversion .. auto
  Bandwidth .. 8-MHz
  FEC (high priority) .. 1/2
  FEC (low priority) ... 1/2
  Constellation ... QPSK
  Transmission mode . 2K
  Guard interval .. 1/32
  Hierarchy ... none

2) Run monitoring application. OK, with corrupted packets.
3) Run previous tool doing ioctl FE_GET_INFO:
error getting info on /dev/dvb/adapter0/frontend0: No such device
Note: this error is reported by ioctl, opening the device is OK.
4) # ls -l /dev/dvb/adapter0/frontend0
crw-rw+ 1 tlelegard video 212, 3 2009-05-18 15:59 
/dev/dvb/adapter0/frontend0
5) Run monitoring application. OK, with corrupted packets.


Is there any new development regarding TD-500 ?
Any test I could make ?

Thanks in advance for your assistance.
-Thierry


-
dmesg - one T-500
-

# dmesg | grep -i -e dvb -e dib
dib0700: loaded with support for 9 different device-types
dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to 
load a firmware
firmware: requesting dvb-usb-dib0700-1.20.fw
dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
dib0700: firmware started successfully.
dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T)
DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)...
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T)
DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)...
dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected.
usbcore: registered new interface driver 

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

2009-05-18 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:Mon May 18 19:00:07 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11824:315bc4b65b4f
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-rc4-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-rc4-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-rc4-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-rc4-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-rc4-m32r: OK
linux-2.6.22.19-mips: ERRORS
linux-2.6.26-mips: ERRORS
linux-2.6.27-mips: ERRORS
linux-2.6.28-mips: ERRORS
linux-2.6.29.1-mips: ERRORS
linux-2.6.30-rc4-mips: ERRORS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-rc4-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: 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-rc4-x86_64: WARNINGS
sparse (linux-2.6.29.1): OK
sparse (linux-2.6.30-rc4): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

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


Re: [PATCH]saa7134-video.c: poll method lose race condition

2009-05-18 Thread Oldřich Jedlička
Hi Figo Zhang,

On Monday 18 of May 2009 at 04:13:13, figo.zhang wrote:
 saa7134-video.c: poll method lose race condition


 Signed-off-by: Figo.zhang figo.zh...@kolorific.com
 ---
 drivers/media/video/saa7134/saa7134-video.c |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

 diff --git a/drivers/media/video/saa7134/saa7134-video.c
 b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..95733df 100644
 --- a/drivers/media/video/saa7134/saa7134-video.c
 +++ b/drivers/media/video/saa7134/saa7134-video.c
 @@ -1423,11 +1423,13 @@ video_poll(struct file *file, struct
 poll_table_struct *wait) {
   struct saa7134_fh *fh = file-private_data;
   struct videobuf_buffer *buf = NULL;
 + unsigned int rc = 0;

   if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type)
   return videobuf_poll_stream(file, fh-vbi, wait);

   if (res_check(fh,RESOURCE_VIDEO)) {
 + mutex_lock(fh-cap.vb_lock);
   if (!list_empty(fh-cap.stream))
   buf = list_entry(fh-cap.stream.next, struct 
 videobuf_buffer, stream);
   } else {
 @@ -1446,13 +1448,14 @@ video_poll(struct file *file, struct
 poll_table_struct *wait) }

   if (!buf)
 - return POLLERR;
 + rc = POLLERR;

Just one note (I don't know the future and meaning of this patch). The line 
above will change the meaning of the buf==NULL check. It will not return 
immediately, but call poll_wait with buf-done instead - NULL pointer access.

Cheers,
Oldrich.


   poll_wait(file, buf-done, wait);
   if (buf-state == VIDEOBUF_DONE ||
   buf-state == VIDEOBUF_ERROR)
 - return POLLIN|POLLRDNORM;
 - return 0;
 + rc = POLLIN|POLLRDNORM;
 + mutex_unlock(fh-cap.vb_lock);
 + return rc;

  err:
   mutex_unlock(fh-cap.vb_lock);


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


[DVB] compiling av7110 firmware into driver fails

2009-05-18 Thread Klaus Schmidinger
I always compile the current av7110 firmware into my driver,
so that I can have different driver/firmware versions to test
with. This used to work by doing

CONFIG_DVB_AV7110_FIRMWARE=y
CONFIG_DVB_AV7110_FIRMWARE_FILE=/home/kls/vdr/firmware/FW.current

in the v4l/.config file (where FW.current is a symlink to the
current firmware version).

With driver version c29ce3e2fc6a (2009-04-25) this still worked,
but with 0018ed9bbca3 (2009-05-16) it doesn't work any more.
Am I doing something wrong, or has this been broken?

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


no tuning with an hvr-1700

2009-05-18 Thread Guillaume Laurès

Hello all,

I can't find digital channels with an hvr-1700.
dvb-scan -a2  /usr/share/dvb/dvb-t/fr-Tours outputs no channel info,  
only some tuning failed messages. Two hvr-3000 in the same box work  
flawlessly (both dvb-t and dvb-s).


I run v4l-sources (last saturday's snapshot), on a 2.6.28-gentoo-r5  
x64 host.
The card is recognized as /dev/dvb/adapter2 and firmwares are loaded.  
I also tried with the hvr-1700 alone and got the same result.
Here is some dmesg output with debugging enabled, this shows activity  
from modprobe and dvb-scan.


May 18 22:00:02 hesa3 cx23885 driver version 0.0.2 loaded
May 18 22:00:02 hesa3 cx23885 :04:00.0: PCI INT A - Link[LN2A] -  
GSI 18 (level, low) - IRQ 18
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() Memory  
configured for PCIe bridge type 885

May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_init_tsport(portno=2)
May 18 22:00:02 hesa3 CORE cx23885[0]: subsystem: 0070:8101, board:  
Hauppauge WinTV-HVR1700 [card=8,autodetected]

May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_pci_quirks()
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() tuner_type =  
0x0 tuner_addr = 0x0
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() radio_type =  
0x0 radio_addr = 0x0

May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_reset()
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Configuring channel [VID A]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch2]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Configuring channel [TS1 B]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch4]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch5]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Configuring channel [TS2 C]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch7]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch8]
May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup()  
Erasing channel [ch9]
May 18 22:00:02 hesa3 tveeprom 7-0050: Hauppauge model 81519, rev  
B2E9, serial# 6177447

May 18 22:00:02 hesa3 tveeprom 7-0050: MAC address is 00-0D-FE-5E-42-A7
May 18 22:00:02 hesa3 tveeprom 7-0050: tuner model is Philips  
18271_8295 (idx 149, type 54)
May 18 22:00:02 hesa3 tveeprom 7-0050: TV standards PAL(B/G) PAL(I)  
SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
May 18 22:00:02 hesa3 tveeprom 7-0050: audio processor is CX23885 (idx  
39)
May 18 22:00:02 hesa3 tveeprom 7-0050: decoder processor is CX23885  
(idx 33)

May 18 22:00:02 hesa3 tveeprom 7-0050: has no radio
May 18 22:00:02 hesa3 cx23885[0]: hauppauge eeprom: model=81519
May 18 22:00:02 hesa3 cx25840 9-0044: cx25  0-21 found @ 0x88  
(cx23885[0])
May 18 22:00:02 hesa3 cx25840 9-0044: firmware: requesting v4l-cx23885- 
avcore-01.fw
May 18 22:00:03 hesa3 cx25840 9-0044: loaded v4l-cx23885-avcore-01.fw  
firmware (16382 bytes)

May 18 22:00:03 hesa3 cx23885_dvb_register() allocating 1 frontend(s)
May 18 22:00:03 hesa3 cx23885[0]: cx23885 based dvb card
May 18 22:00:03 hesa3 tda829x 8-0042: type set to tda8295
May 18 22:00:03 hesa3 tda18271 8-0060: creating new instance
May 18 22:00:03 hesa3 TDA18271HD/C1 detected @ 8-0060
May 18 22:00:05 hesa3 DVB: registering new adapter (cx23885[0])
May 18 22:00:05 hesa3 DVB: registering adapter 2 frontend 0 (NXP  
TDA10048HN DVB-T)...
May 18 22:00:05 hesa3 cx23885_dev_checkrevision() Hardware revision =  
0xb0
May 18 22:00:05 hesa3 cx23885[0]/0: found at :04:00.0, rev: 2,  
irq: 18, latency: 0, mmio: 0xfe80

May 18 22:00:05 hesa3 cx23885 :04:00.0: setting latency timer to 64
-- dvbscan starts here
May 18 22:01:55 hesa3 tda10048_firmware_upload: waiting for firmware  
upload (dvb-fe-tda10048-1.0.fw)...
May 18 22:01:55 hesa3 cx23885 :04:00.0: firmware: requesting dvb- 
fe-tda10048-1.0.fw
May 18 22:01:55 hesa3 tda10048_firmware_upload: firmware read 24878  
bytes.

May 18 22:01:55 hesa3 tda10048_firmware_upload: firmware uploading
May 18 22:01:58 hesa3 tda10048_firmware_upload: firmware uploaded

Any hints ?

Cheers

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


ads tech mini tv usb 0631:a371 lost cause or????

2009-05-18 Thread Robert Martin
Ive been trying to get an ADS tech mini tv usb working with linux does
anybody on the list know if this device works at all by any means
under linux.  Please note yes i have FGI i need current info
as a reference im running kubuntu 9.04 and have a copy of WinXP pro
dual booting the same machine.

-- 
Robert L Martin
--
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


LifeView LV3H still brick - some patches

2009-05-18 Thread Adam Pribyl
It's more than a year I was triing to help with this hybrid PCI card to 
get it working 
(http://lists-archives.org/video4linux/21688-cx88-xc3028-tests-are-required-was-when-xc3028-xc2028-will-be-supported.html).
We've got stuck at firmware extraction, which was somehow troublesome, but 
it was probably not the main problem.


The difference to date is that card is identified under linux as Geniatech 
X8000-MT DVBT which is perfectly fine, as this is OEM Geniatech, but the 
card is still dead with all those Incorrect readback of firmware 
version.


Some time ago lifeview itself posted on their pages a package 
they claim is a linux driver for Fedora Core 6 only.

http://www.notonlytv.net/download/driver/lv3hlv3afedora.rar
Acctually it is a modified snapshot of experimental v4l mercurial repo 
from 7. Apr 2007.


What I did is I compared this package with repo from 7.4.2007 and there 
seem to be - at least for my unexperienced eyes - some useful things done. 
See attached diff.


My question is - did someone already took a look at it? Make those changes 
sense? Or.. are they already incorporated upstream? Are they completely 
outdated/useless now?


Thanks for anybody spending a minute looking at it.


Adam Pribyl


patch2.diff.gz
Description: Binary data


Re: no tuning with an hvr-1700

2009-05-18 Thread Steven Toth

Guillaume Laurès wrote:

Hello all,

I can't find digital channels with an hvr-1700.
dvb-scan -a2  /usr/share/dvb/dvb-t/fr-Tours outputs no channel info, 
only some tuning failed messages. Two hvr-3000 in the same box work 
flawlessly (both dvb-t and dvb-s).


I run v4l-sources (last saturday's snapshot), on a 2.6.28-gentoo-r5 x64 
host.
The card is recognized as /dev/dvb/adapter2 and firmwares are loaded. I 
also tried with the hvr-1700 alone and got the same result.
Here is some dmesg output with debugging enabled, this shows activity 
from modprobe and dvb-scan.



...




Any hints ?


Clone this tree and try again:

http://kernellabs.com/hg/~stoth/tda10048-merge

Better, or not?

--
Steven Toth - 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: no tuning with an hvr-1700

2009-05-18 Thread Guillaume Laurès


Le 18 mai 09 à 23:35, Steven Toth a écrit :


Clone this tree and try again:

http://kernellabs.com/hg/~stoth/tda10048-merge

Better, or not?


Unfortunately not :-(
dmesg is exactly the same.


Thanks,

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


Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)

2009-05-18 Thread hermann pitton
Hi,

[snip]
 
  From: Benoit Istin beis...@gmail.com
 
  There are several months my hvr1110 stop working.
  This is very simple to fix, for my card revision at least, by setting a
  missing field to the hauppauge_hvr_1110_config.

 Hello
 
 I see,
 what i don't remember is, when searching for good parameters for this 
 card (1110), AGC and Co was not necessary...
 
 correct me if i'm wrong :
 
 patch from Anders impacts cards with .tuner_config=1
 what i can do :
 
 step 1 :
 see if we really need .tuner_config = 1  on  hvr_1110_config otherwise 
 change to .tuner_config = 0
 
 step 2 :
 if needed, apply the patch from Anders and look if it's  better or not 
 both on analogic and dvb
 
 step 3 : report this results
 
 
 others ideas ?

Seems I can't find any details about Benoit's eventually different card
version in the mail archives. 

If it turns out we have revisions with LNA and without, we might try to
provide a separate entry for the LNA version. Usually on Hauppauge cards
we find means doing so.

 PS : i need times because my multimedia box is on production and i 
 prefer test this on another pc, you know : why change when all is good ?

Thanks for your time and no need for hurry.

If you keep your old media modules folder, you just can put it back in
place later again and depmod -a and you are done. Do make rmmod and
delete the new media modules folder previously and you should be 100%
back.

Cheers,
Hermann




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


[PATCH] media: one kconfig controls them all

2009-05-18 Thread Randy Dunlap
From: Randy Dunlap randy.dun...@oracle.com

Add a kconfig symbol that allows someone to disable all
multimedia config options at one time.

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 drivers/media/Kconfig |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

--- lnx-2630-rc3.orig/drivers/media/Kconfig
+++ lnx-2630-rc3/drivers/media/Kconfig
@@ -2,8 +2,14 @@
 # Multimedia device configuration
 #
 
-menu Multimedia devices
+menuconfig MEDIA_SUPPORT
+   tristate Multimedia support
depends on HAS_IOMEM
+   help
+ If you want to use Video for Linux, DVB for Linux, or DAB adapters,
+ enable this option and other options below.
+
+if MEDIA_SUPPORT
 
 comment Multimedia core support
 
@@ -136,4 +142,4 @@ config USB_DABUSB
  module will be called dabusb.
 endif # DAB
 
-endmenu
+endif # MEDIA_SUPPORT
--
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 v2]saa7134-video.c: poll method lose race condition for capture video

2009-05-18 Thread figo.zhang
saa7134-video.c: poll method lose race condition for capture video.

In v2, when buf == NULL, it will goto err, return  PULLERR
immediately.

Signed-off-by: Figo.zhang figo.zh...@kolorific.com
---  
drivers/media/video/saa7134/saa7134-video.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-video.c 
b/drivers/media/video/saa7134/saa7134-video.c
index 493cad9..b1c2dbd 100644
--- a/drivers/media/video/saa7134/saa7134-video.c
+++ b/drivers/media/video/saa7134/saa7134-video.c
@@ -1423,11 +1423,13 @@ video_poll(struct file *file, struct poll_table_struct 
*wait)
 {
struct saa7134_fh *fh = file-private_data;
struct videobuf_buffer *buf = NULL;
+   unsigned int rc = 0;
 
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type)
return videobuf_poll_stream(file, fh-vbi, wait);
 
if (res_check(fh,RESOURCE_VIDEO)) {
+   mutex_lock(fh-cap.vb_lock);
if (!list_empty(fh-cap.stream))
buf = list_entry(fh-cap.stream.next, struct 
videobuf_buffer, stream);
} else {
@@ -1446,13 +1448,14 @@ video_poll(struct file *file, struct poll_table_struct 
*wait)
}
 
if (!buf)
-   return POLLERR;
+   goto err;
 
poll_wait(file, buf-done, wait);
if (buf-state == VIDEOBUF_DONE ||
buf-state == VIDEOBUF_ERROR)
-   return POLLIN|POLLRDNORM;
-   return 0;
+   rc =  POLLIN|POLLRDNORM;
+   mutex_unlock(fh-cap.vb_lock);
+   return rc;
 
 err:
mutex_unlock(fh-cap.vb_lock);


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


how to get the firmware dvb-usb-dw3101.fw

2009-05-18 Thread netwolf
I have a usb dvb-c box. But where to get the firmware?
I search by google ,but no result
 

__ Information from ESET Smart Security, version of virus signature
database 4085 (20090519) __

The message was checked by ESET Smart Security.

http://www.eset.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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)

2009-05-18 Thread hermann pitton

Am Dienstag, den 19.05.2009, 01:04 +0200 schrieb hermann pitton:
 Hi,
 
 [snip]
  
   From: Benoit Istin beis...@gmail.com
  
   There are several months my hvr1110 stop working.
   This is very simple to fix, for my card revision at least, by setting a
   missing field to the hauppauge_hvr_1110_config.
 
  Hello
  
  I see,
  what i don't remember is, when searching for good parameters for this 
  card (1110), AGC and Co was not necessary...
  
  correct me if i'm wrong :
  
  patch from Anders impacts cards with .tuner_config=1
  what i can do :
  
  step 1 :
  see if we really need .tuner_config = 1  on  hvr_1110_config otherwise 
  change to .tuner_config = 0
  
  step 2 :
  if needed, apply the patch from Anders and look if it's  better or not 
  both on analogic and dvb
  
  step 3 : report this results
  
  
  others ideas ?
 
 Seems I can't find any details about Benoit's eventually different card
 version in the mail archives. 
 
 If it turns out we have revisions with LNA and without, we might try to
 provide a separate entry for the LNA version. Usually on Hauppauge cards
 we find means doing so.
 
  PS : i need times because my multimedia box is on production and i 
  prefer test this on another pc, you know : why change when all is good ?
 
 Thanks for your time and no need for hurry.
 
 If you keep your old media modules folder, you just can put it back in
 place later again and depmod -a and you are done. Do make rmmod and
 delete the new media modules folder previously and you should be 100%
 back.
 (

Guys,

please.

It looks like this still can go on for some while.

I don't have the time and have zero income from all of this.

Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do
confirm that this bug is assigned to them? (PCTV and Hauppauge)

Or do you prefer to have it further drifting over the lists and call
Hartmut and me for it?

Cheers,
Hermann






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


Re: [PATCH 00/10 v2] soc-camera conversions

2009-05-18 Thread Paul Mundt
On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote:
 this is the next round of soc-camera conversions. Run-tested on i.MX31, 
 PXA270, SH7722, compile-tested only for i.MX1. It should have been a 
 straight-forward port of the previous version to a more current tree, 
 but then I started converting soc_camera_platform, and things became a bit 
 more complex... As a bonus, now soc-camera can handle not only i2c 
 subdevices, and we can even drop the CONFIG_I2C dependency again. I'll 
 also upload a comlpete stack somewhere a bit later, for example for those, 
 wishing to test it on i.MX31, otherwise the series will not apply cleanly. 
 
 I'd like to push the first 8 of them asap, 9 and 10 will still have to be 
 reworked
 
 Paul, I put you on cc on all patches, because, unfortunately, several of 
 them affect arch/sh. But I'll mention it explicitly in each such patch.
 
Looks ok to me, there shouldn't be any problems with taking these all
through the v4l tree. Feel free to add my Acked-by if you like. I guess
we will find out in -next if there are any conflicts or not :-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)

2009-05-18 Thread Devin Heitmueller
On Mon, May 18, 2009 at 10:45 PM, hermann pitton
hermann-pit...@arcor.de wrote:
 Guys,

 please.

 It looks like this still can go on for some while.

 I don't have the time and have zero income from all of this.

 Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do
 confirm that this bug is assigned to them? (PCTV and Hauppauge)

 Or do you prefer to have it further drifting over the lists and call
 Hartmut and me for it?

 Cheers,
 Hermann

Hello Hermann,

I believe it makes sense for me to clarify this point:  Kernel Labs is
not affiliated with Hauppauge or PCTV in any way.  We have not
received any money from either company for Linux support for their
products.

One of Kernel Lab's long-term goals is indeed to find a way to provide
some form of commercial support for devices such as this.

It is probably fair to say that the three of us tend to focus on
products by those vendors because of easy access to sample hardware,
not because of any commercial arrangement.

That said, Kernel Labs is about as responsible for fixing the problem
as you are.  ;-)

Cheers,

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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)

2009-05-18 Thread hermann pitton
Hi Devin,

[snip]
 
 That said, Kernel Labs is about as responsible for fixing the problem
 as you are.  ;-)

tell me more stories.

But OK, heads up then I hope.

Cheers,
Hermann


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


RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver

2009-05-18 Thread Aguirre Rodriguez, Sergio Alberto
Hi Nate,

I have 1 input regarding your question:

From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On 
Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R; 
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver

Hello Hardik,

Reviewing your driver, I found something made me curious.


On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:

snip

 +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
 + * called. This is used to setup buffers and return size and count of
 + * buffers allocated. After the call to this buffer, videobuf layer will
 + * setup buffer queue depending on the size and count of buffers
 + */
 +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int 
 *count,
 + unsigned int *size)
 +{
 +   struct omap_vout_device *vout = q-priv_data;
 +   int startindex = 0, i, j;
 +   u32 phy_addr = 0, virt_addr = 0;
 +
 +   if (!vout)
 +   return -EINVAL;
 +
 +   if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
 +   return -EINVAL;
 +
 +   startindex = (vout-vid == OMAP_VIDEO1) ?
 +   video1_numbuffers : video2_numbuffers;
 +   if (V4L2_MEMORY_MMAP == vout-memory  *count  startindex)
 +   *count = startindex;
 +
 +   if ((rotation_enabled(vout-rotation))  *count  4)
 +   *count = 4;
 +



This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?


Cheers,

Nate


We did a very similar thing on omap3 camera driver, not exactly by the number 
of buffers requested, but more about checking if the bytesize of the total 
requested buffers was superior to the MMU fixed sized page table size 
capabilities to map that size, then we were limiting the number of buffers 
accordingly (for keeping the page table size fixed).

According to the v4l2 spec, changing the count value should be valid, and it is 
the userspace app responsability to check the value again, to confirm how many 
of the requested buffers are actually available.

Regards,
Sergio--
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/3] OMAP2/3 V4L2 Display Driver

2009-05-18 Thread Dongsoo, Nathaniel Kim
Hi Sergio,

Thank you for your explanation . I learned much from that.
Cheers,

Nate

On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
 Hi Nate,

 I have 1 input regarding your question:

From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] 
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh 
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver

Hello Hardik,

Reviewing your driver, I found something made me curious.


On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:

 snip

 +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
 + * called. This is used to setup buffers and return size and count of
 + * buffers allocated. After the call to this buffer, videobuf layer will
 + * setup buffer queue depending on the size and count of buffers
 + */
 +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int 
 *count,
 +                         unsigned int *size)
 +{
 +       struct omap_vout_device *vout = q-priv_data;
 +       int startindex = 0, i, j;
 +       u32 phy_addr = 0, virt_addr = 0;
 +
 +       if (!vout)
 +               return -EINVAL;
 +
 +       if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
 +               return -EINVAL;
 +
 +       startindex = (vout-vid == OMAP_VIDEO1) ?
 +               video1_numbuffers : video2_numbuffers;
 +       if (V4L2_MEMORY_MMAP == vout-memory  *count  startindex)
 +               *count = startindex;
 +
 +       if ((rotation_enabled(vout-rotation))  *count  4)
 +               *count = 4;
 +



This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?


Cheers,

Nate


 We did a very similar thing on omap3 camera driver, not exactly by the number 
 of buffers requested, but more about checking if the bytesize of the total 
 requested buffers was superior to the MMU fixed sized page table size 
 capabilities to map that size, then we were limiting the number of buffers 
 accordingly (for keeping the page table size fixed).

 According to the v4l2 spec, changing the count value should be valid, and it 
 is the userspace app responsability to check the value again, to confirm how 
 many of the requested buffers are actually available.

 Regards,
 Sergio



-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver

2009-05-18 Thread Shah, Hardik
Hi Nate,


 -Original Message-
 From: Aguirre Rodriguez, Sergio Alberto
 Sent: Tuesday, May 19, 2009 10:52 AM
 To: Dongsoo, Nathaniel Kim; Shah, Hardik
 Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
 Hiremath, Vaibhav
 Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
 
 Hi Nate,
 
 I have 1 input regarding your question:
 
 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
 On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
 Sent: Tuesday, May 19, 2009 7:53 AM
 To: Shah, Hardik
 Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
 R; Hiremath, Vaibhav
 Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
 
 Hello Hardik,
 
 Reviewing your driver, I found something made me curious.
 
 
 On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
 
 snip
 
  +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
  + * called. This is used to setup buffers and return size and count of
  + * buffers allocated. After the call to this buffer, videobuf layer will
  + * setup buffer queue depending on the size and count of buffers
  + */
  +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
 *count,
  + unsigned int *size)
  +{
  +   struct omap_vout_device *vout = q-priv_data;
  +   int startindex = 0, i, j;
  +   u32 phy_addr = 0, virt_addr = 0;
  +
  +   if (!vout)
  +   return -EINVAL;
  +
  +   if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
  +   return -EINVAL;
  +
  +   startindex = (vout-vid == OMAP_VIDEO1) ?
  +   video1_numbuffers : video2_numbuffers;
  +   if (V4L2_MEMORY_MMAP == vout-memory  *count  startindex)
  +   *count = startindex;
  +
  +   if ((rotation_enabled(vout-rotation))  *count  4)
  +   *count = 4;
  +
 
 
 
 This seems to be weird to me. If user requests multiple buffers more
 than 4, user cannot recognize that the number of buffers requested is
 forced to change into 4. I'm not sure whether this could be serious or
 not, but it is obvious that user can have doubt about why if user have
 no information about the OMAP H/W.
 Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of 
contexts are available. So maximum number of buffers is fixed to 4 when 
rotation is enabled.

Thanks,
Hardik 
 
 
 Cheers,
 
 Nate
 
 
 We did a very similar thing on omap3 camera driver, not exactly by the number
 of buffers requested, but more about checking if the bytesize of the total
 requested buffers was superior to the MMU fixed sized page table size
 capabilities to map that size, then we were limiting the number of buffers
 accordingly (for keeping the page table size fixed).
 
 According to the v4l2 spec, changing the count value should be valid, and it
 is the userspace app responsability to check the value again, to confirm how
 many of the requested buffers are actually available.
 
 Regards,
 Sergio
--
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/3] OMAP2/3 V4L2 Display Driver

2009-05-18 Thread Dongsoo, Nathaniel Kim
Hi Hardik,

According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,

Nate


On Tue, May 19, 2009 at 2:28 PM, Shah, Hardik hardik.s...@ti.com wrote:
 Hi Nate,


 -Original Message-
 From: Aguirre Rodriguez, Sergio Alberto
 Sent: Tuesday, May 19, 2009 10:52 AM
 To: Dongsoo, Nathaniel Kim; Shah, Hardik
 Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh 
 R;
 Hiremath, Vaibhav
 Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver

 Hi Nate,

 I have 1 input regarding your question:

 From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
 On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
 Sent: Tuesday, May 19, 2009 7:53 AM
 To: Shah, Hardik
 Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
 R; Hiremath, Vaibhav
 Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
 
 Hello Hardik,
 
 Reviewing your driver, I found something made me curious.
 
 
 On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:

 snip

  +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
  + * called. This is used to setup buffers and return size and count of
  + * buffers allocated. After the call to this buffer, videobuf layer will
  + * setup buffer queue depending on the size and count of buffers
  + */
  +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
 *count,
  +                         unsigned int *size)
  +{
  +       struct omap_vout_device *vout = q-priv_data;
  +       int startindex = 0, i, j;
  +       u32 phy_addr = 0, virt_addr = 0;
  +
  +       if (!vout)
  +               return -EINVAL;
  +
  +       if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
  +               return -EINVAL;
  +
  +       startindex = (vout-vid == OMAP_VIDEO1) ?
  +               video1_numbuffers : video2_numbuffers;
  +       if (V4L2_MEMORY_MMAP == vout-memory  *count  startindex)
  +               *count = startindex;
  +
  +       if ((rotation_enabled(vout-rotation))  *count  4)
  +               *count = 4;
  +
 
 
 
 This seems to be weird to me. If user requests multiple buffers more
 than 4, user cannot recognize that the number of buffers requested is
 forced to change into 4. I'm not sure whether this could be serious or
 not, but it is obvious that user can have doubt about why if user have
 no information about the OMAP H/W.
 Is it really necessary to be configured to 4?
 [Shah, Hardik] Rotation requires the VRFB contexts and limited number of 
 contexts are available. So maximum number of buffers is fixed to 4 when 
 rotation is enabled.

 Thanks,
 Hardik
 
 
 Cheers,
 
 Nate
 

 We did a very similar thing on omap3 camera driver, not exactly by the number
 of buffers requested, but more about checking if the bytesize of the total
 requested buffers was superior to the MMU fixed sized page table size
 capabilities to map that size, then we were limiting the number of buffers
 accordingly (for keeping the page table size fixed).

 According to the v4l2 spec, changing the count value should be valid, and it
 is the userspace app responsability to check the value again, to confirm how
 many of the requested buffers are actually available.

 Regards,
 Sergio




-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.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