Re: [PATCH/RFC v3 01/11] v4l: Move the media/v4l2-mediabus.h header to include/linux

2010-10-06 Thread Laurent Pinchart
Hi Guennadi,

On Tuesday 05 October 2010 17:30:21 Guennadi Liakhovetski wrote:
 On Tue, 5 Oct 2010, Sakari Ailus wrote:
  Laurent Pinchart wrote:
   The header defines the v4l2_mbus_framefmt structure which will be used
   by the V4L2 subdevs userspace API.
   
   Change the type of the v4l2_mbus_framefmt::code field to __u32, as enum
   sizes can differ between different ABIs on the same architectures.
   
   Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

[snip]

   +/**
   + * struct v4l2_mbus_framefmt - frame format on the media bus
   + * @width:   frame width
   + * @height:  frame height
   + * @code:data format code
   + * @field:   used interlacing type
   + * @colorspace:  colorspace of the data
   + */
   +struct v4l2_mbus_framefmt {
   + __u32   width;
   + __u32   height;
   + __u32   code;
   + enum v4l2_field field;
   + enum v4l2_colorspacecolorspace;
   +};
  
  I think this struct would benefit from some reserved fields since it's
  part of the user space interface.
 
 IIUC, this struct is not going to be used in ioctl()s, that's what struct
 v4l2_subdev_mbus_code_enum is for. But in this case - why don't we make
 the code field above of type enum v4l2_mbus_pixelcode?

The v4l2_mbus_framefmt structure isn't used directly as an ioctl argument, but 
it's embedded in the v4l2_subdev_format structure, used as an ioctl argument, 
so its size matters.

The v4l2_subdev_format structure has reserved fields right after the 
v4l2_mbus_framefmt member so there's some room for expansion. As for the 
enums, I've reused the ones already in use in the V4L2 API, but I can replace 
them with __u32.

-- 
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] V4L: sh_mobile_ceu_camera: use default .get_parm() and .set_parm() operations

2010-10-06 Thread Guennadi Liakhovetski
No need to duplicate default .get_parm() and .set_parm() operations.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/sh_mobile_ceu_camera.c |   18 --
 1 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index 0b029bd..fdaadde 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -1789,22 +1789,6 @@ static void sh_mobile_ceu_init_videobuf(struct 
videobuf_queue *q,
   icd);
 }
 
-static int sh_mobile_ceu_get_parm(struct soc_camera_device *icd,
- struct v4l2_streamparm *parm)
-{
-   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-
-   return v4l2_subdev_call(sd, video, g_parm, parm);
-}
-
-static int sh_mobile_ceu_set_parm(struct soc_camera_device *icd,
- struct v4l2_streamparm *parm)
-{
-   struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-
-   return v4l2_subdev_call(sd, video, s_parm, parm);
-}
-
 static int sh_mobile_ceu_get_ctrl(struct soc_camera_device *icd,
  struct v4l2_control *ctrl)
 {
@@ -1866,8 +1850,6 @@ static struct soc_camera_host_ops sh_mobile_ceu_host_ops 
= {
.try_fmt= sh_mobile_ceu_try_fmt,
.set_ctrl   = sh_mobile_ceu_set_ctrl,
.get_ctrl   = sh_mobile_ceu_get_ctrl,
-   .set_parm   = sh_mobile_ceu_set_parm,
-   .get_parm   = sh_mobile_ceu_get_parm,
.reqbufs= sh_mobile_ceu_reqbufs,
.poll   = sh_mobile_ceu_poll,
.querycap   = sh_mobile_ceu_querycap,
-- 
1.7.1

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


Re: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-06 Thread Dejan Rodiger
Hi Giorgio,


 Dejan,

 I have the exact same card:

 # sudo lpci -vnn
 02:07.0 Multimedia controller [0480]: Philips Semiconductors 
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
        Subsystem: ASUSTeK Computer Inc. Device [1043:4876]
        Flags: bus master, medium devsel, latency 64, IRQ 20
        Memory at fbfff800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: saa7134
        Kernel modules: saa7134

 and I can confirm you that it's autodetected and works very well (both the
 analog and the digital part) on 2.6.35.
 2.6.32 has a problem with dvb-t reception, but I have reported it and 
 hopefully
 it will be fixed soon upstream: 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23604

 If you want to test the analog part, install MPlayer and run the following 
 command:

 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:chanlist=europe-west

This is working OK. I have also experimented more with tvtime and both
versions work, but I have to do little more fine tuning and then I
have better picture. So I will probably have to manually find exact
stations frequencies and enter them in mythtv. But I first have to
figure how and where to enter them.


 and then press 'k' or 'h' to select previous/next channel (after you switch
 channel, wait some seconds until the card tunes, for some channels I need
 5 seconds here, for others about 1 second). Now, with some patience, explore
 all the channels and you should be able to find your local tv stations.
 Also, you might need to adjust mplayer options, like norm= or chanlist=
 (you could try chanlist=europe-east).

 The command line above doesn't grab audio though, so you won't hear a thing.
 If you want to hear the audio you need to make sure saa7134-alsa is loaded
 and run something like:

 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:immediatemode=0:chanlist=europe-west

saa7134-alsa is loaded automatically, but I am unable to get any sound
from mplayer or tvtime. I see on google, that I am not the only one.
I have also noticed that about 8-10% of the frames are lost.


 (make sure you select the right alsa device in adevice=)

 The wiki has a good page about MPlayer:

 http://www.linuxtv.org/wiki/index.php/MPlayer

 and of course the MPlayer man page explain all the options too.

 These pages are also useful (but some things might be a bit outdated):

 http://www.linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid
 http://www.linuxtv.org/wiki/index.php/Saa7134-alsa

 I hope this can help you and others reading this ML.

 Regards,
 Giorgio Vazzana

 Thanks
 --
 Dejan Rodiger
--
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/PATCH v2 4/6] ARM: OMAP3: Update Camera ISP definitions for OMAP3630

2010-10-06 Thread Laurent Pinchart
Hi Sergio,

On Tuesday 05 October 2010 18:09:42 Aguirre, Sergio wrote:
 On Tuesday, October 05, 2010 8:19 AM Laurent Pinchart wrote:
  
  From: Tuukka Toivonen tuukka.o.toivo...@nokia.com
  
  Add new/changed base address definitions and resources for
  OMAP3630 ISP.
  
  The OMAP3430 CSI2PHY block is same as the OMAP3630 CSIPHY2
  block. But the later name is chosen as it gives more symmetry
  to the names.
 
 This patch needs to go through linux-omap ML.

Sure. I'll send it (as well as the next patch) to the linux-omap mailing list 
after the first review round of the OMAP3 ISP driver.

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


[GIT PATCHES FOR 2.6.37] Use modaliases to load I2C modules

2010-10-06 Thread Laurent Pinchart
Hi Mauro,

The following changes since commit c8dd732fd119ce6d562d5fa82a10bbe75a376575:

  V4L/DVB: gspca - sonixj: Have 0c45:6130 handled by sonixj instead of sn9c102
  (2010-10-01 18:14:35 -0300)

are available in the git repository at:
  git://linuxtv.org/pinchartl/uvcvideo.git i2c-module-name

The patches have been posted to the list, and acked for pvrusb2, soc-camera
and sh_vou.

Laurent Pinchart (16):
  v4l: Load I2C modules based on modalias
  v4l: Remove hardcoded module names passed to v4l2_i2c_new_subdev*
  go7007: Add MODULE_DEVICE_TABLE to the go7007 I2C modules
  go7007: Fix the TW2804 I2C type name
  go7007: Don't use module names to load I2C modules
  zoran: Don't use module names to load I2C modules
  pvrusb2: Don't use module names to load I2C modules
  sh_vou: Don't use module names to load I2C modules
  radio-si4713: Don't use module names to load I2C modules
  soc_camera: Don't use module names to load I2C modules
  vpfe_capture: Don't use module names to load I2C modules
  vpif_display: Don't use module names to load I2C modules
  vpif_capture: Don't use module names to load I2C modules
  ivtv: Don't use module names to load I2C modules
  cx18: Don't use module names to load I2C modules
  v4l: Remove module_name argument to the v4l2_i2c_new_subdev* functions

 arch/arm/mach-mx3/mach-pcm037.c   |2 -
 arch/arm/mach-mx3/mx31moboard-marxbot.c   |1 -
 arch/arm/mach-mx3/mx31moboard-smartbot.c  |1 -
 arch/arm/mach-pxa/em-x270.c   |1 -
 arch/arm/mach-pxa/ezx.c   |2 -
 arch/arm/mach-pxa/mioa701.c   |1 -
 arch/arm/mach-pxa/pcm990-baseboard.c  |2 -
 arch/sh/boards/mach-ap325rxa/setup.c  |1 -
 arch/sh/boards/mach-ecovec24/setup.c  |4 --
 arch/sh/boards/mach-kfr2r09/setup.c   |1 -
 arch/sh/boards/mach-migor/setup.c |2 -
 arch/sh/boards/mach-se/7724/setup.c   |1 -
 drivers/media/radio/radio-si4713.c|2 +-
 drivers/media/video/au0828/au0828-cards.c |4 +-
 drivers/media/video/bt8xx/bttv-cards.c|   22 +-
 drivers/media/video/cafe_ccic.c   |2 +-
 drivers/media/video/cx18/cx18-i2c.c   |   23 ++-
 drivers/media/video/cx231xx/cx231xx-cards.c   |4 +-
 drivers/media/video/cx23885/cx23885-cards.c   |2 +-
 drivers/media/video/cx23885/cx23885-video.c   |4 +-
 drivers/media/video/cx88/cx88-cards.c |9 ++--
 drivers/media/video/cx88/cx88-video.c |7 +--
 drivers/media/video/davinci/vpfe_capture.c|1 -
 drivers/media/video/davinci/vpif_capture.c|1 -
 drivers/media/video/davinci/vpif_display.c|2 +-
 drivers/media/video/em28xx/em28xx-cards.c |   18 
 drivers/media/video/fsl-viu.c |2 +-
 drivers/media/video/ivtv/ivtv-i2c.c   |   50 +
 drivers/media/video/mxb.c |   12 +++---
 drivers/media/video/pvrusb2/pvrusb2-hdw.c |   13 +-
 drivers/media/video/saa7134/saa7134-cards.c   |8 ++--
 drivers/media/video/saa7134/saa7134-core.c|4 +-
 drivers/media/video/sh_vou.c  |2 +-
 drivers/media/video/soc_camera.c  |2 +-
 drivers/media/video/usbvision/usbvision-i2c.c |6 +-
 drivers/media/video/v4l2-common.c |   13 ++
 drivers/media/video/vino.c|4 +-
 drivers/media/video/zoran/zoran.h |2 -
 drivers/media/video/zoran/zoran_card.c|   24 +--
 drivers/staging/go7007/go7007-driver.c|   43 +
 drivers/staging/go7007/go7007-usb.c   |2 +-
 drivers/staging/go7007/wis-ov7640.c   |1 +
 drivers/staging/go7007/wis-saa7113.c  |1 +
 drivers/staging/go7007/wis-saa7115.c  |1 +
 drivers/staging/go7007/wis-sony-tuner.c   |1 +
 drivers/staging/go7007/wis-tw2804.c   |1 +
 drivers/staging/go7007/wis-tw9903.c   |1 +
 drivers/staging/go7007/wis-uda1342.c  |1 +
 drivers/staging/tm6000/tm6000-cards.c |4 +-
 include/media/sh_vou.h|1 -
 include/media/v4l2-common.h   |   16 +++-
 51 files changed, 101 insertions(+), 234 deletions(-)

-- 
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 04/14] uvcvideo: Constify the uvc_entity_match_guid arguments

2010-10-06 Thread Laurent Pinchart
They're not modified by the function, make them const.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index bce29fd..d8dc1e1 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -727,7 +727,8 @@ static const __u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
 static const __u8 uvc_media_transport_input_guid[16] =
UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
 
-static int uvc_entity_match_guid(struct uvc_entity *entity, __u8 guid[16])
+static int uvc_entity_match_guid(const struct uvc_entity *entity,
+   const __u8 guid[16])
 {
switch (UVC_ENTITY_TYPE(entity)) {
case UVC_ITT_CAMERA:
-- 
1.7.2.2

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


[PATCH 01/14] uvcvideo: Fix support for Medion Akoya All-in-one PC integrated webcam

2010-10-06 Thread Laurent Pinchart
The camera requires the STREAM_NO_FID quirk. Add a corresponding entry
in the device IDs list.

Cc: stable.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_driver.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index 28ed5b4..a4bdbac 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -2092,6 +2092,15 @@ static struct usb_device_id uvc_ids[] = {
  .bInterfaceProtocol   = 0,
  .driver_info  = UVC_QUIRK_PROBE_MINMAX
| UVC_QUIRK_PROBE_DEF },
+   /* IMC Networks (Medion Akoya) */
+   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
+   | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x13d3,
+ .idProduct= 0x5103,
+ .bInterfaceClass  = USB_CLASS_VIDEO,
+ .bInterfaceSubClass   = 1,
+ .bInterfaceProtocol   = 0,
+ .driver_info  = UVC_QUIRK_STREAM_NO_FID },
/* Syntek (HP Spartan) */
{ .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
-- 
1.7.2.2

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


[PATCH 00/14] uvcvideo patches for 2.6.37

2010-10-06 Thread Laurent Pinchart
Hi everybody,

Here's a bunch of uvcvideo patches for 2.6.37, including bug fixes (the first 2
patches should already be queued for 2.6.36), buggy camera workarounds, locking
fixes and core driver changes.

I will send a pull request on Friday.

Laurent Pinchart (13):
  uvcvideo: Fix support for Medion Akoya All-in-one PC integrated
webcam
  uvcvideo: Restrict frame rates for Chicony CNF7129 webcam
  uvcvideo: Blacklist more controls for Hercules Dualpix Exchange
  uvcvideo: Constify the uvc_entity_match_guid arguments
  uvcvideo: Print query name in uvc_query_ctrl()
  uvcvideo: Update e-mail address and copyright notices
  uvcvideo: Set bandwidth to at least 1024 with the FIX_BANDWIDTH quirk
  uvcvideo: Generate discontinuous sequence numbers when frames are
lost
  uvcvideo: Hardcode the index/selector relationship for XU controls
  uvcvideo: Embed uvc_control_info inside struct uvc_control
  uvcvideo: Delay initialization of XU controls
  uvcvideo: Fix bogus XU controls information
  uvcvideo: Fix uvc_query_v4l2_ctrl() and uvc_xu_ctrl_query() locking

Martin Rubli (1):
  uvcvideo: Remove sysadmin requirements for UVCIOC_CTRL_MAP

 drivers/media/video/uvc/uvc_ctrl.c   |  712 --
 drivers/media/video/uvc/uvc_driver.c |   42 ++-
 drivers/media/video/uvc/uvc_isight.c |2 +-
 drivers/media/video/uvc/uvc_queue.c  |   11 +-
 drivers/media/video/uvc/uvc_status.c |4 +-
 drivers/media/video/uvc/uvc_v4l2.c   |   56 +--
 drivers/media/video/uvc/uvc_video.c  |   52 +++-
 drivers/media/video/uvc/uvcvideo.h   |   41 +--
 8 files changed, 528 insertions(+), 392 deletions(-)

-- 
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 03/14] uvcvideo: Blacklist more controls for Hercules Dualpix Exchange

2010-10-06 Thread Laurent Pinchart
The Hercules Dualpix Exchange (06f8:3005) camera expose an absolute zoom
that is not implemented. Blacklist it.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c |   36 
 1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index a350fad..bce29fd 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1499,26 +1499,46 @@ end:
 static void
 uvc_ctrl_prune_entity(struct uvc_device *dev, struct uvc_entity *entity)
 {
-   static const struct {
+   struct uvc_ctrl_blacklist {
struct usb_device_id id;
u8 index;
-   } blacklist[] = {
+   };
+
+   static const struct uvc_ctrl_blacklist processing_blacklist[] = {
{ { USB_DEVICE(0x13d3, 0x509b) }, 9 }, /* Gain */
{ { USB_DEVICE(0x1c4f, 0x3000) }, 6 }, /* WB Temperature */
{ { USB_DEVICE(0x5986, 0x0241) }, 2 }, /* Hue */
};
+   static const struct uvc_ctrl_blacklist camera_blacklist[] = {
+   { { USB_DEVICE(0x06f8, 0x3005) }, 9 }, /* Zoom, Absolute */
+   };
 
-   u8 *controls;
+   const struct uvc_ctrl_blacklist *blacklist;
unsigned int size;
+   unsigned int count;
unsigned int i;
+   u8 *controls;
 
-   if (UVC_ENTITY_TYPE(entity) != UVC_VC_PROCESSING_UNIT)
-   return;
+   switch (UVC_ENTITY_TYPE(entity)) {
+   case UVC_VC_PROCESSING_UNIT:
+   blacklist = processing_blacklist;
+   count = ARRAY_SIZE(processing_blacklist);
+   controls = entity-processing.bmControls;
+   size = entity-processing.bControlSize;
+   break;
+
+   case UVC_ITT_CAMERA:
+   blacklist = camera_blacklist;
+   count = ARRAY_SIZE(camera_blacklist);
+   controls = entity-camera.bmControls;
+   size = entity-camera.bControlSize;
+   break;
 
-   controls = entity-processing.bmControls;
-   size = entity-processing.bControlSize;
+   default:
+   return;
+   }
 
-   for (i = 0; i  ARRAY_SIZE(blacklist); ++i) {
+   for (i = 0; i  count; ++i) {
if (!usb_match_one_id(dev-intf, blacklist[i].id))
continue;
 
-- 
1.7.2.2

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


[PATCH 05/14] uvcvideo: Print query name in uvc_query_ctrl()

2010-10-06 Thread Laurent Pinchart
Instead of printing the query hex value in error messages, print its
name to make the messages more readable.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_video.c |   30 +++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_video.c 
b/drivers/media/video/uvc/uvc_video.c
index e27cf0d..ef55877 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -45,6 +45,30 @@ static int __uvc_query_ctrl(struct uvc_device *dev, __u8 
query, __u8 unit,
unit  8 | intfnum, data, size, timeout);
 }
 
+static const char *uvc_query_name(__u8 query)
+{
+   switch (query) {
+   case UVC_SET_CUR:
+   return SET_CUR;
+   case UVC_GET_CUR:
+   return GET_CUR;
+   case UVC_GET_MIN:
+   return GET_MIN;
+   case UVC_GET_MAX:
+   return GET_MAX;
+   case UVC_GET_RES:
+   return GET_RES;
+   case UVC_GET_LEN:
+   return GET_LEN;
+   case UVC_GET_INFO:
+   return GET_INFO;
+   case UVC_GET_DEF:
+   return GET_DEF;
+   default:
+   return invalid;
+   }
+}
+
 int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8 unit,
__u8 intfnum, __u8 cs, void *data, __u16 size)
 {
@@ -53,9 +77,9 @@ int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8 
unit,
ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
UVC_CTRL_CONTROL_TIMEOUT);
if (ret != size) {
-   uvc_printk(KERN_ERR, Failed to query (%u) UVC control %u 
-   (unit %u) : %d (exp. %u).\n, query, cs, unit, ret,
-   size);
+   uvc_printk(KERN_ERR, Failed to query (%s) UVC control %u on 
+   unit %u: %d (exp. %u).\n, uvc_query_name(query), cs,
+   unit, ret, size);
return -EIO;
}
 
-- 
1.7.2.2

--
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 02/14] uvcvideo: Restrict frame rates for Chicony CNF7129 webcam

2010-10-06 Thread Laurent Pinchart
At all frame rates except 30fps and 5fps the camera produces very dark
pictures. Auto-exposure is probably disabled by the camera at all frame
rates except 30fps, making them pretty unusable.

Work around the problem by introducing a new RESTRICT_FRAME_RATE quirk
that disables all the frame rates except the default one.

Cc: stable.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_driver.c |   15 +++
 drivers/media/video/uvc/uvcvideo.h   |1 +
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index a4bdbac..93d78f6 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -486,6 +486,12 @@ static int uvc_parse_format(struct uvc_device *dev,
max(frame-dwFrameInterval[0],
frame-dwDefaultFrameInterval));
 
+   if (dev-quirks  UVC_QUIRK_RESTRICT_FRAME_RATE) {
+   frame-bFrameIntervalType = 1;
+   frame-dwFrameInterval[0] =
+   frame-dwDefaultFrameInterval;
+   }
+
uvc_trace(UVC_TRACE_DESCR, - %ux%u (%u.%u fps)\n,
frame-wWidth, frame-wHeight,
1000/frame-dwDefaultFrameInterval,
@@ -2027,6 +2033,15 @@ static struct usb_device_id uvc_ids[] = {
  .bInterfaceClass  = USB_CLASS_VENDOR_SPEC,
  .bInterfaceSubClass   = 1,
  .bInterfaceProtocol   = 0 },
+   /* Chicony CNF7129 (Asus EEE 100HE) */
+   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
+   | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x04f2,
+ .idProduct= 0xb071,
+ .bInterfaceClass  = USB_CLASS_VIDEO,
+ .bInterfaceSubClass   = 1,
+ .bInterfaceProtocol   = 0,
+ .driver_info  = UVC_QUIRK_RESTRICT_FRAME_RATE },
/* Alcor Micro AU3820 (Future Boy PC USB Webcam) */
{ .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
diff --git a/drivers/media/video/uvc/uvcvideo.h 
b/drivers/media/video/uvc/uvcvideo.h
index bdacf3b..892e0e5 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -182,6 +182,7 @@ struct uvc_xu_control {
 #define UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020
 #define UVC_QUIRK_FIX_BANDWIDTH0x0080
 #define UVC_QUIRK_PROBE_DEF0x0100
+#define UVC_QUIRK_RESTRICT_FRAME_RATE  0x0200
 
 /* Format flags */
 #define UVC_FMT_FLAG_COMPRESSED0x0001
-- 
1.7.2.2

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


[PATCH 08/14] uvcvideo: Generate discontinuous sequence numbers when frames are lost

2010-10-06 Thread Laurent Pinchart
Increase the sequence number of the v4l2_buffer structure regardless of
any buffer states, so that discontinuous sequence numbers allow
applications to detect lost video frames.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_queue.c |7 +--
 drivers/media/video/uvc/uvc_video.c |9 +
 drivers/media/video/uvc/uvcvideo.h  |2 +-
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_queue.c 
b/drivers/media/video/uvc/uvc_queue.c
index d27a315..ed6d544 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -135,7 +135,6 @@ int uvc_alloc_buffers(struct uvc_video_queue *queue, 
unsigned int nbuffers,
queue-buffer[i].buf.m.offset = i * bufsize;
queue-buffer[i].buf.length = buflength;
queue-buffer[i].buf.type = queue-type;
-   queue-buffer[i].buf.sequence = 0;
queue-buffer[i].buf.field = V4L2_FIELD_NONE;
queue-buffer[i].buf.memory = V4L2_MEMORY_MMAP;
queue-buffer[i].buf.flags = 0;
@@ -410,8 +409,7 @@ done:
  * state can be properly initialized before buffers are accessed from the
  * interrupt handler.
  *
- * Enabling the video queue initializes parameters (such as sequence number,
- * sync pattern, ...). If the queue is already enabled, return -EBUSY.
+ * Enabling the video queue returns -EBUSY if the queue is already enabled.
  *
  * Disabling the video queue cancels the queue and removes all buffers from
  * the main queue.
@@ -430,7 +428,6 @@ int uvc_queue_enable(struct uvc_video_queue *queue, int 
enable)
ret = -EBUSY;
goto done;
}
-   queue-sequence = 0;
queue-flags |= UVC_QUEUE_STREAMING;
queue-buf_used = 0;
} else {
@@ -510,8 +507,6 @@ struct uvc_buffer *uvc_queue_next_buffer(struct 
uvc_video_queue *queue,
nextbuf = NULL;
spin_unlock_irqrestore(queue-irqlock, flags);
 
-   buf-buf.sequence = queue-sequence++;
-
wake_up(buf-wait);
return nextbuf;
 }
diff --git a/drivers/media/video/uvc/uvc_video.c 
b/drivers/media/video/uvc/uvc_video.c
index 5a2022c..39d4e70 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -427,6 +427,12 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
 
fid = data[1]  UVC_STREAM_FID;
 
+   /* Increase the sequence number regardless of any buffer states, so
+* that discontinuous sequence numbers always indicate lost frames.
+*/
+   if (stream-last_fid != fid)
+   stream-sequence++;
+
/* Store the payload FID bit and return immediately when the buffer is
 * NULL.
 */
@@ -460,6 +466,7 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
else
ktime_get_real_ts(ts);
 
+   buf-buf.sequence = stream-sequence;
buf-buf.timestamp.tv_sec = ts.tv_sec;
buf-buf.timestamp.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
 
@@ -721,6 +728,7 @@ static void uvc_video_encode_bulk(struct urb *urb, struct 
uvc_streaming *stream,
if (buf-buf.bytesused == stream-queue.buf_used) {
stream-queue.buf_used = 0;
buf-state = UVC_BUF_STATE_READY;
+   buf-buf.sequence = stream-sequence++;
uvc_queue_next_buffer(stream-queue, buf);
stream-last_fid ^= UVC_STREAM_FID;
}
@@ -979,6 +987,7 @@ static int uvc_init_video(struct uvc_streaming *stream, 
gfp_t gfp_flags)
unsigned int i;
int ret;
 
+   stream-sequence = 0;
stream-last_fid = -1;
stream-bulk.header_size = 0;
stream-bulk.skip_payload = 0;
diff --git a/drivers/media/video/uvc/uvcvideo.h 
b/drivers/media/video/uvc/uvcvideo.h
index 892e0e5..f890133 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -392,7 +392,6 @@ struct uvc_video_queue {
 
void *mem;
unsigned int flags;
-   __u32 sequence;
 
unsigned int count;
unsigned int buf_size;
@@ -458,6 +457,7 @@ struct uvc_streaming {
dma_addr_t urb_dma[UVC_URBS];
unsigned int urb_size;
 
+   __u32 sequence;
__u8 last_fid;
 };
 
-- 
1.7.2.2

--
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 10/14] uvcvideo: Remove sysadmin requirements for UVCIOC_CTRL_MAP

2010-10-06 Thread Laurent Pinchart
From: Martin Rubli martin_ru...@logitech.com

This patch removes the sysadmin requirements for UVCIOC_CTRL_MAP (and the stub
implementation of UVCIOC_CTRL_ADD). This requirement no longer makes sense with
the new XU control access mechanisms since XU controls can be accessed without
adding control mappings first.

A maximum number (currently 1024) of control mappings per device is enforced to
avoid excess memory consumption caused by careless user space applications.

Signed-off-by: Martin Rubli martin_ru...@logitech.com
---
 drivers/media/video/uvc/uvc_ctrl.c   |   14 ++
 drivers/media/video/uvc/uvc_driver.c |1 +
 drivers/media/video/uvc/uvc_v4l2.c   |6 --
 drivers/media/video/uvc/uvcvideo.h   |4 
 4 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index 2c81b7f..531a3e1 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1435,6 +1435,7 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
struct uvc_entity *entity;
struct uvc_control *ctrl;
int found = 0;
+   int ret;
 
if (mapping-id  ~V4L2_CTRL_ID_MASK) {
uvc_trace(UVC_TRACE_CONTROL, Can't add mapping '%s', control 
@@ -1478,7 +1479,20 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
}
}
 
+   /* Prevent excess memory consumption */
+   if (atomic_inc_return(dev-nmappings)  UVC_MAX_CONTROL_MAPPINGS) {
+   atomic_dec(dev-nmappings);
+   uvc_trace(UVC_TRACE_CONTROL, Can't add mapping '%s', maximum 
+   mappings count (%u) exceeded.\n, mapping-name,
+   UVC_MAX_CONTROL_MAPPINGS);
+   ret = -ENOMEM;
+   goto done;
+   }
+
ret = __uvc_ctrl_add_mapping(dev, ctrl, mapping);
+   if (ret  0)
+   atomic_dec(dev-nmappings);
+
 done:
mutex_unlock(chain-ctrl_mutex);
return ret;
diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index 71efda7..a1e9dfb 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1760,6 +1760,7 @@ static int uvc_probe(struct usb_interface *intf,
INIT_LIST_HEAD(dev-streams);
atomic_set(dev-nstreams, 0);
atomic_set(dev-users, 0);
+   atomic_set(dev-nmappings, 0);
 
dev-udev = usb_get_dev(udev);
dev-intf = usb_get_intf(intf);
diff --git a/drivers/media/video/uvc/uvc_v4l2.c 
b/drivers/media/video/uvc/uvc_v4l2.c
index 4a51048..6d15de9 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1025,16 +1025,10 @@ static long uvc_v4l2_do_ioctl(struct file *file, 
unsigned int cmd, void *arg)
/* Dynamic controls. */
case UVCIOC_CTRL_ADD:
/* Legacy ioctl, kept for API compatibility reasons */
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
-
return -EEXIST;
 
case UVCIOC_CTRL_MAP_OLD:
case UVCIOC_CTRL_MAP:
-   if (!capable(CAP_SYS_ADMIN))
-   return -EPERM;
-
return uvc_ioctl_ctrl_map(chain, arg,
  cmd == UVCIOC_CTRL_MAP_OLD);
 
diff --git a/drivers/media/video/uvc/uvcvideo.h 
b/drivers/media/video/uvc/uvcvideo.h
index 34637fb..39e9e36 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -172,6 +172,9 @@ struct uvc_xu_control {
 #define UVC_CTRL_CONTROL_TIMEOUT   300
 #define UVC_CTRL_STREAMING_TIMEOUT 5000
 
+/* Maximum allowed number of control mappings per device */
+#define UVC_MAX_CONTROL_MAPPINGS   1024
+
 /* Devices quirks */
 #define UVC_QUIRK_STATUS_INTERVAL  0x0001
 #define UVC_QUIRK_PROBE_MINMAX 0x0002
@@ -472,6 +475,7 @@ struct uvc_device {
 
enum uvc_device_state state;
atomic_t users;
+   atomic_t nmappings;
 
/* Video control interface */
__u16 uvc_version;
-- 
1.7.2.2

--
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 09/14] uvcvideo: Hardcode the index/selector relationship for XU controls

2010-10-06 Thread Laurent Pinchart
Devices advertise XU controls using a bitmask, in which each bit
corresponds to a control. The control selector, used to query the
control, isn't available in the USB descriptors.

All known UVC devices use control selectors equal to the control bit
index plus one. Hardcode that relationship in the driver, making the
UVCIOC_CTRL_ADD ioctl obsolete. All necessary information about XU
controls can be obtained by the driver at enumeration time.

The UVCIOC_CTRL_ADD ioctl is still supported for compatibility reasons,
but now always returns -EEXIST.

Finally, control mappings are now on a per-device basis and no longer
global.

As this changes the userspace interface, bump the driver version number
to 1.0.0 (it was about time).

Signed-off-by: Martin Rubli martin_ru...@logitech.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c   |  433 +-
 drivers/media/video/uvc/uvc_driver.c |   10 -
 drivers/media/video/uvc/uvc_v4l2.c   |   46 +---
 drivers/media/video/uvc/uvcvideo.h   |   21 +--
 4 files changed, 240 insertions(+), 270 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index e7acf55..2c81b7f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1294,201 +1294,193 @@ int uvc_ctrl_resume_device(struct uvc_device *dev)
  * Control and mapping handling
  */
 
-static int uvc_ctrl_add_ctrl(struct uvc_device *dev,
-   struct uvc_control_info *info)
+/*
+ * Query control information (size and flags) for XU controls.
+ */
+static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
+   const struct uvc_control *ctrl, struct uvc_control_info *info)
 {
-   struct uvc_entity *entity;
-   struct uvc_control *ctrl = NULL;
-   int ret = 0, found = 0;
-   unsigned int i;
-   u8 *uvc_info;
-   u8 *uvc_data;
+   u8 *data;
+   int ret;
 
-   list_for_each_entry(entity, dev-entities, list) {
-   if (!uvc_entity_match_guid(entity, info-entity))
-   continue;
+   data = kmalloc(2, GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
 
-   for (i = 0; i  entity-ncontrols; ++i) {
-   ctrl = entity-controls[i];
-   if (ctrl-index == info-index) {
-   found = 1;
-   break;
-   }
-   }
+   memcpy(info-entity, ctrl-entity-extension.guidExtensionCode,
+  sizeof(info-entity));
+   info-index = ctrl-index;
+   info-selector = ctrl-index + 1;
 
-   if (found)
-   break;
+   /* Query and verify the control length (GET_LEN) */
+   ret = uvc_query_ctrl(dev, UVC_GET_LEN, ctrl-entity-id, dev-intfnum,
+info-selector, data, 2);
+   if (ret  0) {
+   uvc_trace(UVC_TRACE_CONTROL,
+ GET_LEN failed on control %pUl/%u (%d).\n,
+  info-entity, info-selector, ret);
+   goto done;
}
 
-   if (!found)
-   return 0;
+   info-size = le16_to_cpup((__le16 *)data);
 
-   uvc_data = kmalloc(info-size * UVC_CTRL_DATA_LAST + 1, GFP_KERNEL);
-   if (uvc_data == NULL)
-   return -ENOMEM;
+   /* Query the control information (GET_INFO) */
+   ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl-entity-id, dev-intfnum,
+info-selector, data, 1);
+   if (ret  0) {
+   uvc_trace(UVC_TRACE_CONTROL,
+ GET_INFO failed on control %pUl/%u (%d).\n,
+ info-entity, info-selector, ret);
+   goto done;
+   }
 
-   uvc_info = uvc_data + info-size * UVC_CTRL_DATA_LAST;
+   info-flags = UVC_CONTROL_GET_MIN | UVC_CONTROL_GET_MAX
+   | UVC_CONTROL_GET_RES | UVC_CONTROL_GET_DEF
+   | (data[0]  UVC_CONTROL_CAP_GET ? UVC_CONTROL_GET_CUR : 0)
+   | (data[0]  UVC_CONTROL_CAP_SET ? UVC_CONTROL_SET_CUR : 0)
+   | (data[0]  UVC_CONTROL_CAP_AUTOUPDATE ?
+  UVC_CONTROL_AUTO_UPDATE : 0);
 
-   if (UVC_ENTITY_TYPE(entity) == UVC_VC_EXTENSION_UNIT) {
-   /* Check if the device control information and length match
-* the user supplied information.
-*/
-   ret = uvc_query_ctrl(dev, UVC_GET_LEN, ctrl-entity-id,
-dev-intfnum, info-selector, uvc_data, 2);
-   if (ret  0) {
-   uvc_trace(UVC_TRACE_CONTROL,
-   GET_LEN failed on control %pUl/%u (%d).\n,
-   info-entity, info-selector, ret);
-   goto done;
-   }
+   uvc_trace(UVC_TRACE_CONTROL, XU control %pUl/%u queried: 

[PATCH 13/14] uvcvideo: Fix bogus XU controls information

2010-10-06 Thread Laurent Pinchart
XU control information is supposed to be entirely discoverable using
standard UVC queries. As some devices report bogus information (such as
reporting a read-only control as being read-write), add a fixup table
for XU controls.

This table can also be used to selectively disable requests supposed to
be supported by all XU controls (GET_MIN, GET_MAX, GET_DEF, GET_RES) but
not correctly (or at all) supported by the device.

The table currently disables GET_CUR on the Logitech motor control XU
pan/tilt controls.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c |   41 
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index a0c9d58..0d310c4 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1164,6 +1164,45 @@ int uvc_ctrl_set(struct uvc_video_chain *chain,
  * Dynamic controls
  */
 
+static void uvc_ctrl_fixup_xu_info(struct uvc_device *dev,
+   const struct uvc_control *ctrl, struct uvc_control_info *info)
+{
+   struct uvc_ctrl_fixup {
+   struct usb_device_id id;
+   u8 entity;
+   u8 selector;
+   u8 flags;
+   };
+
+   static const struct uvc_ctrl_fixup fixups[] = {
+   { { USB_DEVICE(0x046d, 0x08c2) }, 9, 1,
+   UVC_CONTROL_GET_MIN | UVC_CONTROL_GET_MAX |
+   UVC_CONTROL_GET_DEF | UVC_CONTROL_SET_CUR |
+   UVC_CONTROL_AUTO_UPDATE },
+   { { USB_DEVICE(0x046d, 0x08cc) }, 9, 1,
+   UVC_CONTROL_GET_MIN | UVC_CONTROL_GET_MAX |
+   UVC_CONTROL_GET_DEF | UVC_CONTROL_SET_CUR |
+   UVC_CONTROL_AUTO_UPDATE },
+   { { USB_DEVICE(0x046d, 0x0994) }, 9, 1,
+   UVC_CONTROL_GET_MIN | UVC_CONTROL_GET_MAX |
+   UVC_CONTROL_GET_DEF | UVC_CONTROL_SET_CUR |
+   UVC_CONTROL_AUTO_UPDATE },
+   };
+
+   unsigned int i;
+
+   for (i = 0; i  ARRAY_SIZE(fixups); ++i) {
+   if (!usb_match_one_id(dev-intf, fixups[i].id))
+   continue;
+
+   if (fixups[i].entity == ctrl-entity-id 
+   fixups[i].selector == info-selector) {
+   info-flags = fixups[i].flags;
+   return;
+   }
+   }
+}
+
 /*
  * Query control information (size and flags) for XU controls.
  */
@@ -1211,6 +1250,8 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
| (data[0]  UVC_CONTROL_CAP_AUTOUPDATE ?
   UVC_CONTROL_AUTO_UPDATE : 0);
 
+   uvc_ctrl_fixup_xu_info(dev, ctrl, info);
+
uvc_trace(UVC_TRACE_CONTROL, XU control %pUl/%u queried: len %u, 
  flags { get %u set %u auto %u }.\n,
  info-entity, info-selector, info-size,
-- 
1.7.2.2

--
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 12/14] uvcvideo: Delay initialization of XU controls

2010-10-06 Thread Laurent Pinchart
XU controls initialization requires querying the device for control
information. As some buggy UVC devices will crash when queried
repeatedly in a tight loop, delay XU controls initialization until first
use.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c |  194 
 1 files changed, 107 insertions(+), 87 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index 97a2395..a0c9d58 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1164,6 +1164,90 @@ int uvc_ctrl_set(struct uvc_video_chain *chain,
  * Dynamic controls
  */
 
+/*
+ * Query control information (size and flags) for XU controls.
+ */
+static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
+   const struct uvc_control *ctrl, struct uvc_control_info *info)
+{
+   u8 *data;
+   int ret;
+
+   data = kmalloc(2, GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   memcpy(info-entity, ctrl-entity-extension.guidExtensionCode,
+  sizeof(info-entity));
+   info-index = ctrl-index;
+   info-selector = ctrl-index + 1;
+
+   /* Query and verify the control length (GET_LEN) */
+   ret = uvc_query_ctrl(dev, UVC_GET_LEN, ctrl-entity-id, dev-intfnum,
+info-selector, data, 2);
+   if (ret  0) {
+   uvc_trace(UVC_TRACE_CONTROL,
+ GET_LEN failed on control %pUl/%u (%d).\n,
+  info-entity, info-selector, ret);
+   goto done;
+   }
+
+   info-size = le16_to_cpup((__le16 *)data);
+
+   /* Query the control information (GET_INFO) */
+   ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl-entity-id, dev-intfnum,
+info-selector, data, 1);
+   if (ret  0) {
+   uvc_trace(UVC_TRACE_CONTROL,
+ GET_INFO failed on control %pUl/%u (%d).\n,
+ info-entity, info-selector, ret);
+   goto done;
+   }
+
+   info-flags = UVC_CONTROL_GET_MIN | UVC_CONTROL_GET_MAX
+   | UVC_CONTROL_GET_RES | UVC_CONTROL_GET_DEF
+   | (data[0]  UVC_CONTROL_CAP_GET ? UVC_CONTROL_GET_CUR : 0)
+   | (data[0]  UVC_CONTROL_CAP_SET ? UVC_CONTROL_SET_CUR : 0)
+   | (data[0]  UVC_CONTROL_CAP_AUTOUPDATE ?
+  UVC_CONTROL_AUTO_UPDATE : 0);
+
+   uvc_trace(UVC_TRACE_CONTROL, XU control %pUl/%u queried: len %u, 
+ flags { get %u set %u auto %u }.\n,
+ info-entity, info-selector, info-size,
+ (info-flags  UVC_CONTROL_GET_CUR) ? 1 : 0,
+ (info-flags  UVC_CONTROL_SET_CUR) ? 1 : 0,
+ (info-flags  UVC_CONTROL_AUTO_UPDATE) ? 1 : 0);
+
+done:
+   kfree(data);
+   return ret;
+}
+
+static int uvc_ctrl_add_info(struct uvc_device *dev, struct uvc_control *ctrl,
+   const struct uvc_control_info *info);
+
+static int uvc_ctrl_init_xu_ctrl(struct uvc_device *dev,
+   struct uvc_control *ctrl)
+{
+   struct uvc_control_info info;
+   int ret;
+
+   if (ctrl-initialized)
+   return 0;
+
+   ret = uvc_ctrl_fill_xu_info(dev, ctrl, info);
+   if (ret  0)
+   return ret;
+
+   ret = uvc_ctrl_add_info(dev, ctrl, info);
+   if (ret  0)
+   uvc_trace(UVC_TRACE_CONTROL, Failed to initialize control 
+ %pUl/%u on device %s entity %u\n, info.entity,
+ info.selector, dev-udev-devpath, ctrl-entity-id);
+
+   return ret;
+}
+
 int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
struct uvc_xu_control *xctrl, int set)
 {
@@ -1186,13 +1270,10 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
return -EINVAL;
}
 
-   /* Find the control. */
+   /* Find the control and perform delayed initialization if needed. */
for (i = 0; i  entity-ncontrols; ++i) {
ctrl = entity-controls[i];
-   if (!ctrl-initialized)
-   continue;
-
-   if (ctrl-info.selector == xctrl-selector) {
+   if (ctrl-index == xctrl-selector - 1) {
found = 1;
break;
}
@@ -1204,6 +1285,10 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
return -EINVAL;
}
 
+   ret = uvc_ctrl_init_xu_ctrl(chain-dev, ctrl);
+   if (ret  0)
+   return -ENOENT;
+
/* Validate control data size. */
if (ctrl-info.size != xctrl-size)
return -EINVAL;
@@ -1295,65 +1380,6 @@ int uvc_ctrl_resume_device(struct uvc_device *dev)
  */
 
 /*
- * Query control information (size and flags) for XU controls.
- */
-static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
-   const 

[PATCH 07/14] uvcvideo: Set bandwidth to at least 1024 with the FIX_BANDWIDTH quirk

2010-10-06 Thread Laurent Pinchart
The bandwidth estimate computed with the FIX_BANDIWDTH quirk is too low
for many cameras. Don't use maximum packet sizes lower than 1024 bytes
to try and work around the problem. According to measurements done on
two different camera models, the value is high enough to get most
resolutions working while not preventing two simultaneous VGA streams at
15 fps.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_video.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_video.c 
b/drivers/media/video/uvc/uvc_video.c
index ee5e233..5a2022c 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -138,6 +138,15 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming 
*stream,
bandwidth /= 8;
bandwidth += 12;
 
+   /* The bandwidth estimate is too low for many cameras. Don't use
+* maximum packet sizes lower than 1024 bytes to try and work
+* around the problem. According to measurements done on two
+* different camera models, the value is high enough to get most
+* resolutions working while not preventing two simultaneous
+* VGA streams at 15 fps.
+*/
+   bandwidth = max_t(u32, bandwidth, 1024);
+
ctrl-dwMaxPayloadTransferSize = bandwidth;
}
 }
-- 
1.7.2.2

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


[PATCH 06/14] uvcvideo: Update e-mail address and copyright notices

2010-10-06 Thread Laurent Pinchart
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/uvc/uvc_ctrl.c   |4 ++--
 drivers/media/video/uvc/uvc_driver.c |7 ---
 drivers/media/video/uvc/uvc_isight.c |2 +-
 drivers/media/video/uvc/uvc_queue.c  |4 ++--
 drivers/media/video/uvc/uvc_status.c |4 ++--
 drivers/media/video/uvc/uvc_v4l2.c   |4 ++--
 drivers/media/video/uvc/uvc_video.c  |4 ++--
 7 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index d8dc1e1..e7acf55 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_ctrl.c  --  USB Video Class driver - Controls
  *
- *  Copyright (C) 2005-2009
- *  Laurent Pinchart (laurent.pinch...@skynet.be)
+ *  Copyright (C) 2005-2010
+ *  Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
  *  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
diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index 93d78f6..dc035c0 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_driver.c  --  USB Video Class driver
  *
- *  Copyright (C) 2005-2009
- *  Laurent Pinchart (laurent.pinch...@skynet.be)
+ *  Copyright (C) 2005-2010
+ *  Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
  *  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
@@ -38,7 +38,8 @@
 
 #include uvcvideo.h
 
-#define DRIVER_AUTHOR  Laurent Pinchart laurent.pinch...@skynet.be
+#define DRIVER_AUTHOR  Laurent Pinchart  \
+   laurent.pinch...@ideasonboard.com
 #define DRIVER_DESCUSB Video Class driver
 #ifndef DRIVER_VERSION
 #define DRIVER_VERSION v0.1.0
diff --git a/drivers/media/video/uvc/uvc_isight.c 
b/drivers/media/video/uvc/uvc_isight.c
index a9285b5..74bbe8f 100644
--- a/drivers/media/video/uvc/uvc_isight.c
+++ b/drivers/media/video/uvc/uvc_isight.c
@@ -4,7 +4,7 @@
  * Copyright (C) 2006-2007
  * Ivan N. Zlatev cont...@i-nz.net
  * Copyright (C) 2008-2009
- * Laurent Pinchart laurent.pinch...@skynet.be
+ * Laurent Pinchart laurent.pinch...@ideasonboard.com
  *
  *  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
diff --git a/drivers/media/video/uvc/uvc_queue.c 
b/drivers/media/video/uvc/uvc_queue.c
index e9928a4..d27a315 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_queue.c  --  USB Video Class driver - Buffers management
  *
- *  Copyright (C) 2005-2009
- *  Laurent Pinchart (laurent.pinch...@skynet.be)
+ *  Copyright (C) 2005-2010
+ *  Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
  *  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
diff --git a/drivers/media/video/uvc/uvc_status.c 
b/drivers/media/video/uvc/uvc_status.c
index 85019bd..b749277 100644
--- a/drivers/media/video/uvc/uvc_status.c
+++ b/drivers/media/video/uvc/uvc_status.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_status.c  --  USB Video Class driver - Status endpoint
  *
- *  Copyright (C) 2007-2009
- *  Laurent Pinchart (laurent.pinch...@skynet.be)
+ *  Copyright (C) 2005-2009
+ *  Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
  *  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
diff --git a/drivers/media/video/uvc/uvc_v4l2.c 
b/drivers/media/video/uvc/uvc_v4l2.c
index 86db326..8cecd1c 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_v4l2.c  --  USB Video Class driver - V4L2 API
  *
- *  Copyright (C) 2005-2009
- *  Laurent Pinchart (laurent.pinch...@skynet.be)
+ *  Copyright (C) 2005-2010
+ *  Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
  *  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
diff --git a/drivers/media/video/uvc/uvc_video.c 
b/drivers/media/video/uvc/uvc_video.c
index ef55877..ee5e233 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -1,8 +1,8 @@
 /*
  *  uvc_video.c  --  USB Video Class driver - Video handling
  *
- *  Copyright (C) 2005-2009
- *  Laurent Pinchart 

RE: [PATCH/RFC v3 03/11] v4l: Group media bus pixel codes by types and sort them alphabetically

2010-10-06 Thread Hiremath, Vaibhav
 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Tuesday, October 05, 2010 7:55 PM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [PATCH/RFC v3 03/11] v4l: Group media bus pixel codes by types
 and sort them alphabetically
 
 Adding new pixel codes at the end of the enumeration will soon create a
 mess, so group the pixel codes by type and sort them by bus_width, bits
 per component, samples per pixel and order of subsamples.
 
 As the codes are part of the kernel ABI their value can't change when a
 new code is inserted in the enumeration, so they are given an explicit
 numerical value. When inserting a new pixel code developers must use and
 update the next free value.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  include/linux/v4l2-mediabus.h |   61 +---
 
  1 files changed, 38 insertions(+), 23 deletions(-)
 
 diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
 index 75c2d55..53c81f2 100644
 --- a/include/linux/v4l2-mediabus.h
 +++ b/include/linux/v4l2-mediabus.h
 @@ -24,31 +24,46 @@
   * transferred first, BE means that the most significant bits are
 transferred
   * first, and PADHI and PADLO define which bits - low or high, in the
   * incomplete high byte, are filled with padding bits.
 + *
 + * The pixel codes are grouped by type, bus_width, bits per component,
 samples
 + * per pixel and order of subsamples. Numerical values are sorted using
 generic
 + * numerical sort order (8 thus comes before 10).
 + *
 + * As their value can't change when a new pixel code is inserted in the
 + * enumeration, the pixel codes are explicitly given a numerical value.
 The next
 + * free values for each category are listed below, update them when
 inserting
 + * new pixel codes.
   */
  enum v4l2_mbus_pixelcode {
 - V4L2_MBUS_FMT_FIXED = 1,
 - V4L2_MBUS_FMT_YUYV8_2X8,
 - V4L2_MBUS_FMT_YVYU8_2X8,
 - V4L2_MBUS_FMT_UYVY8_2X8,
 - V4L2_MBUS_FMT_VYUY8_2X8,
 - V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
 - V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
 - V4L2_MBUS_FMT_RGB565_2X8_LE,
 - V4L2_MBUS_FMT_RGB565_2X8_BE,
 - V4L2_MBUS_FMT_SBGGR8_1X8,
 - V4L2_MBUS_FMT_SBGGR10_1X10,
 - V4L2_MBUS_FMT_Y8_1X8,
 - V4L2_MBUS_FMT_Y10_1X10,
 - V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
 - V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
 - V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
 - V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
 - V4L2_MBUS_FMT_SGRBG8_1X8,
 - V4L2_MBUS_FMT_SBGGR12_1X12,
 - V4L2_MBUS_FMT_YUYV8_1_5X8,
 - V4L2_MBUS_FMT_YVYU8_1_5X8,
 - V4L2_MBUS_FMT_UYVY8_1_5X8,
 - V4L2_MBUS_FMT_VYUY8_1_5X8,
 + V4L2_MBUS_FMT_FIXED = 0x0001,
 +
 + /* RGB - next is 0x1005 */
[Hiremath, Vaibhav] Don't you think adding next is 0x is not required? Also 
while adding to this list someone has to modify here too.

Same applies to all such places.

Thanks,
Vaibhav
 + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1001,
 + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1002,
 + V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1003,
 + V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1004,
 +
 + /* YUV (including grey) - next is 0x200b */
 + V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
 + V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
 + V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
 + V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
 + V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
 + V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
 + V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
 + V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
 + V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
 + V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
 +
 + /* Bayer - next is 0x3009 */
 + V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
 + V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
 + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
 + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
 + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
 + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
 + V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
 + V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
  };
 
  /**
 --
 1.7.2.2
 
 --
 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


RE: [PATCH/RFC v3 04/11] v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
 Sent: Tuesday, October 05, 2010 7:55 PM
 To: linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: [PATCH/RFC v3 04/11] v4l: Add 8-bit YUYV on 16-bit bus and
 SGRBG10 media bus pixel codes
 
 Add the following media bus format code definitions:
 
 - V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer
 - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG Bayer
 - V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus
 - V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus
 - V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus
 - V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus
 
[Hiremath, Vaibhav] Laurent I may be wrong here, but I think above definition 
is confusing -

For me the above definition actually means, 16bits are coming on the bus for 
every cycle.

If you are referring to OMAP3 interface here then 8-16 bit conversion happens 
inside ISP-bridge, the interface from sensor-to-CCDC is still 8 bit 
(Technically it is 10, but we are using lane shifter to get 8 bits) and I 
believe sensor is also sending one component for every cycle (either UYVY or 
YUYV).

And I believe the bridge driver is not exported to user application so we 
should be using MBUS_FMT_UYVY8_2x8 and family.

Thanks,
Vaibhav

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  include/linux/v4l2-mediabus.h |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
 index 53c81f2..8987d4b 100644
 --- a/include/linux/v4l2-mediabus.h
 +++ b/include/linux/v4l2-mediabus.h
 @@ -43,7 +43,7 @@ enum v4l2_mbus_pixelcode {
   V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1003,
   V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1004,
 
 - /* YUV (including grey) - next is 0x200b */
 + /* YUV (including grey) - next is 0x200f */
   V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
   V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
   V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
 @@ -54,15 +54,21 @@ enum v4l2_mbus_pixelcode {
   V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
   V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
   V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
 + V4L2_MBUS_FMT_UYVY8_1X16 = 0x200b,
 + V4L2_MBUS_FMT_VYUY8_1X16 = 0x200c,
 + V4L2_MBUS_FMT_YUYV8_1X16 = 0x200d,
 + V4L2_MBUS_FMT_YVYU8_1X16 = 0x200e,
 
 - /* Bayer - next is 0x3009 */
 + /* Bayer - next is 0x300b */
   V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
   V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
 + V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
   V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
   V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
   V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
   V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
   V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
 + V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a,
   V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
  };
 
 --
 1.7.2.2
 
 --
 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


RE: [RFC/PATCH v2 5/6] omap3: Export omap3isp platform device structure

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
 Sent: Tuesday, October 05, 2010 9:40 PM
 To: Laurent Pinchart; linux-media@vger.kernel.org
 Cc: sakari.ai...@maxwell.research.nokia.com
 Subject: RE: [RFC/PATCH v2 5/6] omap3: Export omap3isp platform device
 structure
 
 Hi Laurent,
 
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
  Sent: Tuesday, October 05, 2010 8:19 AM
  To: linux-media@vger.kernel.org
  Cc: sakari.ai...@maxwell.research.nokia.com
  Subject: [RFC/PATCH v2 5/6] omap3: Export omap3isp platform device
  structure
 
  From: Stanimir Varbanov svarba...@mm-sol.com
 
  The omap3isp platform device requires platform data. As the data can be
  provided by a kernel module, the device can't be registered during arch
  initialization.
 
  Remove the omap3isp platform device registration from
  omap_init_camera(), and export the platform device structure to let
  board code register/unregister it.
 
 
 This patch needs to go through linux-omap ML.

[Hiremath, Vaibhav] Yes that's correct, all arch/arm/mach-omap2 and 
arch/arm/plat-omap/ changes supposed to get reviewed from linux-omap mailing 
list.

Thanks,
Vaibhav

 
 Regards,
 Sergio
 
  Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
   arch/arm/mach-omap2/devices.c |   18 --
   arch/arm/mach-omap2/devices.h |   17 +
   2 files changed, 33 insertions(+), 2 deletions(-)
   create mode 100644 arch/arm/mach-omap2/devices.h
 
  diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
 omap2/devices.c
  index ade8db0..f9bc507 100644
  --- a/arch/arm/mach-omap2/devices.c
  +++ b/arch/arm/mach-omap2/devices.c
  @@ -31,6 +31,8 @@
 
   #include mux.h
 
  +#include devices.h
  +
   #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 
   static struct resource cam_resources[] = {
  @@ -141,16 +143,28 @@ static struct resource omap3isp_resources[] = {
  }
   };
 
  -static struct platform_device omap3isp_device = {
  +static void omap3isp_release(struct device *dev)
  +{
  +   /* Zero the device structure to avoid re-initialization complaints
  from
  +* kobject when the device will be re-registered.
  +*/
  +   memset(dev, 0, sizeof(*dev));
  +   dev-release = omap3isp_release;
  +}
  +
  +struct platform_device omap3isp_device = {
  .name   = omap3isp,
  .id = -1,
  .num_resources  = ARRAY_SIZE(omap3isp_resources),
  .resource   = omap3isp_resources,
  +   .dev = {
  +   .release= omap3isp_release,
  +   },
   };
  +EXPORT_SYMBOL_GPL(omap3isp_device);
 
   static inline void omap_init_camera(void)
   {
  -   platform_device_register(omap3isp_device);
   }
   #else
   static inline void omap_init_camera(void)
  diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-
 omap2/devices.h
  new file mode 100644
  index 000..f312d49
  --- /dev/null
  +++ b/arch/arm/mach-omap2/devices.h
  @@ -0,0 +1,17 @@
  +/*
  + * arch/arm/mach-omap2/devices.h
  + *
  + * OMAP2 platform device setup/initialization
  + *
  + * 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.
  + */
  +
  +#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H
  +#define __ARCH_ARM_MACH_OMAP_DEVICES_H
  +
  +extern struct platform_device omap3isp_device;
  +
  +#endif
  --
  1.7.2.2
 
  --
  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
--
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 v3 03/11] v4l: Group media bus pixel codes by types and sort them alphabetically

2010-10-06 Thread Laurent Pinchart
Hi Vaibhav,

On Wednesday 06 October 2010 11:19:21 Hiremath, Vaibhav wrote:
 On Tuesday, October 05, 2010 7:55 PM Laurent Pinchart wrote:
  
  Adding new pixel codes at the end of the enumeration will soon create a
  mess, so group the pixel codes by type and sort them by bus_width, bits
  per component, samples per pixel and order of subsamples.
  
  As the codes are part of the kernel ABI their value can't change when a
  new code is inserted in the enumeration, so they are given an explicit
  numerical value. When inserting a new pixel code developers must use and
  update the next free value.
  
[snip]

  +   V4L2_MBUS_FMT_FIXED = 0x0001,
  +
  +   /* RGB - next is 0x1005 */
 
 Don't you think adding next is 0x is not required?
 Also while adding to this list someone has to modify here too.
 
 Same applies to all such places.

The idea is that formats will be ordered by name. When adding new formats, the 
numerical values will then become out of order. Keeping a comment with the 
next format value will avoid having to search through the enum for the last 
used value.

  +   V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1001,
  +   V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1002,
  +   V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1003,
  +   V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1004,
  +
  +   /* YUV (including grey) - next is 0x200b */
  +   V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
  +   V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
  +   V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
  +   V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
  +   V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
  +   V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
  +   V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
  +   V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
  +   V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
  +   V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
  +
  +   /* Bayer - next is 0x3009 */
  +   V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
  +   V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
  +   V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
  +   V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
  +   V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
  +   V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
  +   V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
  +   V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,

-- 
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 v3 04/11] v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes

2010-10-06 Thread Laurent Pinchart
Hi Vaibhav,

On Wednesday 06 October 2010 11:19:25 Hiremath, Vaibhav wrote:
 On Tuesday, October 05, 2010 7:55 PM Laurent Pinchart wrote:
  
  Add the following media bus format code definitions:
  
  - V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer
  - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG Bayer
  - V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus
  - V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus
  - V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus
  - V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus

The commit message should list V4L2_MBUS_FMT_*8_1X16 instead of 
V4L2_MBUS_FMT_*16_1X16, my bad.
 
 Laurent I may be wrong here, but I think above definition is confusing -
 
 For me the above definition actually means, 16bits are coming on the bus
 for every cycle.

That's correct.

 If you are referring to OMAP3 interface here then 8-16 bit conversion
 happens inside ISP-bridge, the interface from sensor-to-CCDC is still 8
 bit (Technically it is 10, but we are using lane shifter to get 8 bits)
 and I believe sensor is also sending one component for every cycle (either
 UYVY or YUYV).

That's correct as well.

 And I believe the bridge driver is not exported to user application so we
 should be using MBUS_FMT_UYVY8_2x8 and family.

The V4L2_MBUS_FMT_*8_1X16 formats are used for the preview - resizer link, 
not the sensor - CCDC link. For the later the V4L2_MBUS_FMT_*8_2X8 are used 
instead.

-- 
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 v3 03/11] v4l: Group media bus pixel codes by types and sort them alphabetically

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, October 06, 2010 3:43 PM
 To: Hiremath, Vaibhav
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [PATCH/RFC v3 03/11] v4l: Group media bus pixel codes by
 types and sort them alphabetically
 
 Hi Vaibhav,
 
 On Wednesday 06 October 2010 11:19:21 Hiremath, Vaibhav wrote:
  On Tuesday, October 05, 2010 7:55 PM Laurent Pinchart wrote:
  
   Adding new pixel codes at the end of the enumeration will soon create
 a
   mess, so group the pixel codes by type and sort them by bus_width,
 bits
   per component, samples per pixel and order of subsamples.
  
   As the codes are part of the kernel ABI their value can't change when
 a
   new code is inserted in the enumeration, so they are given an explicit
   numerical value. When inserting a new pixel code developers must use
 and
   update the next free value.
  
 [snip]
 
   + V4L2_MBUS_FMT_FIXED = 0x0001,
   +
   + /* RGB - next is 0x1005 */
 
  Don't you think adding next is 0x is not required?
  Also while adding to this list someone has to modify here too.
 
  Same applies to all such places.
 
 The idea is that formats will be ordered by name. When adding new formats,
 the
 numerical values will then become out of order. Keeping a comment with the
 next format value will avoid having to search through the enum for the
 last
 used value.
[Hiremath, Vaibhav] I understand your point, but still I think you have defined 
the format structure very well and should be very easy to understand that's it 
is following some protocol.

Thanks,
Vaibhav

 
   + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1001,
   + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1002,
   + V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1003,
   + V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1004,
   +
   + /* YUV (including grey) - next is 0x200b */
   + V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
   + V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
   + V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
   + V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
   + V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
   + V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
   + V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
   + V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
   + V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
   + V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
   +
   + /* Bayer - next is 0x3009 */
   + V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
   + V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
   + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
   + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
   + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
   + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
   + V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
   + V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
 
 --
 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 v3 04/11] v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, October 06, 2010 3:49 PM
 To: Hiremath, Vaibhav
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [PATCH/RFC v3 04/11] v4l: Add 8-bit YUYV on 16-bit bus and
 SGRBG10 media bus pixel codes
 
 Hi Vaibhav,
 
 On Wednesday 06 October 2010 11:19:25 Hiremath, Vaibhav wrote:
  On Tuesday, October 05, 2010 7:55 PM Laurent Pinchart wrote:
  
   Add the following media bus format code definitions:
  
   - V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer
   - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG
 Bayer
   - V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus
   - V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus
   - V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus
   - V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus
 
 The commit message should list V4L2_MBUS_FMT_*8_1X16 instead of
 V4L2_MBUS_FMT_*16_1X16, my bad.
 
  Laurent I may be wrong here, but I think above definition is confusing -
 
  For me the above definition actually means, 16bits are coming on the bus
  for every cycle.
 
 That's correct.
 
  If you are referring to OMAP3 interface here then 8-16 bit conversion
  happens inside ISP-bridge, the interface from sensor-to-CCDC is still 8
  bit (Technically it is 10, but we are using lane shifter to get 8 bits)
  and I believe sensor is also sending one component for every cycle
 (either
  UYVY or YUYV).
 
 That's correct as well.
 
  And I believe the bridge driver is not exported to user application so
 we
  should be using MBUS_FMT_UYVY8_2x8 and family.
 
 The V4L2_MBUS_FMT_*8_1X16 formats are used for the preview - resizer
 link,
 not the sensor - CCDC link. For the later the V4L2_MBUS_FMT_*8_2X8 are
 used
 instead.
 
[Hiremath, Vaibhav] Ok. Understood  agreed.

Thanks,
Vaibhav

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


gspca, audio and ov534: regression.

2010-10-06 Thread Antonio Ospite
Hi,

with 2.6.36-rc6 I can't use the ov534 gspca subdriver (with PS3 eye)
anymore, when I try to capture video in dmesg I get:
gspca: no transfer endpoint found

If I revert commit 35680ba I can make video capture work again but I
still don't get the audio device in pulseaudio, it shows up in alsamixer
but if I try to select it, on the console I get:
cannot load mixer controls: Invalid argument

I'll test with latest Jean-François tree, and if it still fails I'll try
to find a solution, but I wanted to report it quickly first, I hope we
fix this before 2.6.36.

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?


pgpXAx1oGhpGx.pgp
Description: PGP signature


[v4l/dvb] identification/ fixed registration order of DVB cards

2010-10-06 Thread Matthias Weber
Hello,

we are using two identical DVB cards (TT-budget S2-1600) in one system.

How can we assure that the same card always are assigned to the same device 
file /dev/dvb/adapter0 (/dev/dvb/adapter1 

respectively). 

Short example:
Is the card in the first PCI slot always /dev/dvb/adapter0
and the card in the second PCI slot always /dev/dvb/adapter1?

Is this (registration order or whatever it may be called) done in some drivers?
Or is it pure luck when booting the system?

If not implemented, what can be done to tell our own software to switch 
frontend handles or not to?

There might be a way through MAC addresses...
In ttpci-eeprom.c is a function called ttpci_eeprom_parse_mac()
which is used in budget_core.c ttpci_budget_init() function.
Can this somehow combined with PCI?

Any ideas what would be a smart and easy way?
Thanks!

Cheers
Matthias
-- 
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt freischalten! http://portal.gmx.net/de/go/maxdome
--
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: gspca, audio and ov534: regression.

2010-10-06 Thread Jean-Francois Moine
On Wed, 6 Oct 2010 12:33:21 +0200
Antonio Ospite osp...@studenti.unina.it wrote:

 with 2.6.36-rc6 I can't use the ov534 gspca subdriver (with PS3 eye)
 anymore, when I try to capture video in dmesg I get:
 gspca: no transfer endpoint found
 
 If I revert commit 35680ba I can make video capture work again but I
 still don't get the audio device in pulseaudio, it shows up in
 alsamixer but if I try to select it, on the console I get:
 cannot load mixer controls: Invalid argument
 
 I'll test with latest Jean-François tree, and if it still fails I'll
 try to find a solution, but I wanted to report it quickly first, I
 hope we fix this before 2.6.36.

Hi Antonio,

I think I see why the commit prevents the webcam to work: as it is
done, the choice of the alternate setting does not work with bulk
transfer. A simple fix could be to also check bulk transfer when
skipping an alt setting in the function get_ep().

About audio stream, I do not see how it can have been broken.

Might you send me the full USB information of your webcam?

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-06 Thread Giorgio
Hello Hermann,

2010/10/5 hermann pitton hermann-pit...@arcor.de:
 Hi Giorgio,

 Am Montag, den 04.10.2010, 18:11 +0200 schrieb Giorgio:
 On 04/10/2010 01:48, Dejan Rodiger wrote:
  Hi Hermann,
 
  I finally found the time to wire analog antena and I checked it with
  my TV if it is working correctly.
  Since I am using local cable provider which didn't upgrade their
  system in 10 years and they are still broadcast in analog, I had a
  problem off finding channel list, so in the end I tried tvtime-scanner
  and it found about 58 channels. But, out of this 58 most of them were
  not good (no signal). I was able to finetune few programs. My main
  programs (local Croatian TV stations) were not found. Maybe I need to
  finetune every found station.
 
  I also tried zapping which crashed my X.
 
  I am also lost in setting mythtv. I set analog tunner on /dev/video0.
  But I think I have a problem of setting the channel list for my local
  cable provider. Is it possible to scan whole list or something. If you
  have any reading recommendation to set this, I would be helpfull

 Dejan,

 I have the exact same card:

 # sudo lpci -vnn
 02:07.0 Multimedia controller [0480]: Philips Semiconductors 
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
       Subsystem: ASUSTeK Computer Inc. Device [1043:4876]
       Flags: bus master, medium devsel, latency 64, IRQ 20
       Memory at fbfff800 (32-bit, non-prefetchable) [size=2K]
       Capabilities: [40] Power Management version 2
       Kernel driver in use: saa7134
       Kernel modules: saa7134

 and I can confirm you that it's autodetected and works very well (both the
 analog and the digital part) on 2.6.35.
 2.6.32 has a problem with dvb-t reception, but I have reported it and 
 hopefully
 it will be fixed soon upstream: 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23604

 thanks for the report and pointing to the details again.

No problem :)

 We can see, that my testings on four different machines and Dmitri's
 tests have not been enough. Mauro had the Dual card=78 version from me
 too at least for analog TV testing.

 And, that was on hg with most backward compat as possible.

 How good are our chances, to run in such and similar troubles in the
 future, in fact staying only on latest -rc, rc-git and in best case on
 -next stuff previously?

Yes, I was quite disappointed to notice there was a regression in
2.6.30, .31 and .32 and that nobody had noticed it before (in my
experience saa7134 has always been one of the best driver on linux) so
I think it will be very important to test new code properly in the
future, at least before the code is widely used by distros. I am
willing to help with testing.

 It will all come down to the distros and such a bug fix might take just
 a year in the future regularly ...

I reported the bug on Ubuntu's Launchpad, but after the patch was
ready and users confirmed it solved the problem, the Ubuntu team
didn't backport the fix, so dvb-t reception is still broken, for
example, on Ubuntu Lucid 10.04 (which is a long term release, and will
be supported for 3 years)

 So, if the quality control was not even sufficient on hg, what will
 happen on latest -rc git stuff for that?

 Obviously zillions of people do much more prefer to crash around there
 than on hg ... ;)

 Likely, I only have to read the LKML daily ...

 Despite of that, we need a good analysis of course, and a way how to
 avoid such.

Maybe we can have some kind of test team? It would help to find
regressions before it's too late.

 Cheers,
 Hermann

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


Re: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-06 Thread Giorgio
2010/10/6 Dejan Rodiger dejan.rodi...@gmail.com:
 Hi Giorgio,


 Dejan,

 I have the exact same card:

 # sudo lpci -vnn
 02:07.0 Multimedia controller [0480]: Philips Semiconductors 
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
        Subsystem: ASUSTeK Computer Inc. Device [1043:4876]
        Flags: bus master, medium devsel, latency 64, IRQ 20
        Memory at fbfff800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: saa7134
        Kernel modules: saa7134

 and I can confirm you that it's autodetected and works very well (both the
 analog and the digital part) on 2.6.35.
 2.6.32 has a problem with dvb-t reception, but I have reported it and 
 hopefully
 it will be fixed soon upstream: 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23604

 If you want to test the analog part, install MPlayer and run the following 
 command:

 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:chanlist=europe-west

 This is working OK. I have also experimented more with tvtime and both
 versions work, but I have to do little more fine tuning and then I
 have better picture. So I will probably have to manually find exact
 stations frequencies and enter them in mythtv. But I first have to
 figure how and where to enter them.


 and then press 'k' or 'h' to select previous/next channel (after you switch
 channel, wait some seconds until the card tunes, for some channels I need
 5 seconds here, for others about 1 second). Now, with some patience, explore
 all the channels and you should be able to find your local tv stations.
 Also, you might need to adjust mplayer options, like norm= or chanlist=
 (you could try chanlist=europe-east).

 The command line above doesn't grab audio though, so you won't hear a thing.
 If you want to hear the audio you need to make sure saa7134-alsa is loaded
 and run something like:

 mplayer tv:// -tv 
 driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:immediatemode=0:chanlist=europe-west

 saa7134-alsa is loaded automatically, but I am unable to get any sound
 from mplayer or tvtime. I see on google, that I am not the only one.
 I have also noticed that about 8-10% of the frames are lost.

Hmm...things you can try:
1) Tell pulseaudio not to use the saa7134-alsa soundcard (click on
sound preferences (top panel, on the right, near the clock) and
disable saa7134 soundcard).
2) Run cat /proc/asound/card or arecord -l and make sure you're
using the right device on the MPlayer command line (the
adevice=hw.1,0 part).
3) Add audiorate=32000 like this:
mplayer tv:// -tv
driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:audiorate=32000:immediatemode=0:chanlist=europe-west
4) See if MPlayer reports any error with alsa/audio.

Lastly, I think tvtime only works with a patch audio cable (which is
cable that connects the tv-card audio out to the soundcard line
in). So you can try to start tvtime and then run:

arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -

this way you record from the saa7134 audio device and play it back to
your speakers.


 (make sure you select the right alsa device in adevice=)

 The wiki has a good page about MPlayer:

 http://www.linuxtv.org/wiki/index.php/MPlayer

 and of course the MPlayer man page explain all the options too.

 These pages are also useful (but some things might be a bit outdated):

 http://www.linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid
 http://www.linuxtv.org/wiki/index.php/Saa7134-alsa

 I hope this can help you and others reading this ML.

 Regards,
 Giorgio Vazzana

 Thanks
 --
 Dejan Rodiger


Cheers,
Giorgio Vazzana
--
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: xc5000 and switch RF input

2010-10-06 Thread Mauro Carvalho Chehab
Em 06-10-2010 16:52, Dmitri Belimov escreveu:
 Hi
 
 Our TV card Behold X7 has two different RF input. This RF inputs can switch 
 between
 different RF sources. 
 
 ANT 1 for analog and digital TV
 ANT 2 for FM radio
 
 The switch controlled by zl10353.
 
 How to I can control this switch?
 
 I found 2 way
 
 1. 
 Use tuner callback to saa1734. add some params like 
 XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h
 call tuner callback from xc5000_set_analog_params with new params about 
 switching.
 In this case inside saa7134 need know about zl10353 and configuration. I 
 don't understand how to do.
 The structure saa7134_dev hasn't pointer to the structure dvb_frontend. 
 Or use hardcoded i2c_addr and params.
 
 2.
 Direct call switch the switcher from the tuner code. In this case need know 
 TV card type. I think it is not so good idea.


Alternative 2 is not a good idea.

There's another alternative: just call some code at saa7134-video, when 
changing from TV or from video, 
for example, at s_freq. It may be hard to track when this happens, as the user 
may be using a program 
like kradio, that may keep the device open even while not using it.

This problem looks like one I'm currently having where both DVB and analog 
parts are trying to access
tda18271 tuner and mb86a20s demod at the same time. The same problem also 
happened on em28xx and cx231xx.
The solution there were to (ab)use of the device lock, but it is not perfect.

There's a better alternative that requires adding more glue at frontend.

I'll post soon an email with a proposal for that. It would also solve other 
problems that we're currently
experiencing.

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


[RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input

2010-10-06 Thread Mauro Carvalho Chehab
Em 06-10-2010 16:52, Dmitri Belimov escreveu:
 Hi
 
 Our TV card Behold X7 has two different RF input. This RF inputs can switch 
 between
 different RF sources. 
 
 ANT 1 for analog and digital TV
 ANT 2 for FM radio
 
 The switch controlled by zl10353.
 
 How to I can control this switch?
 
 I found 2 way
 
 1. 
 Use tuner callback to saa1734. add some params like 
 XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h
 call tuner callback from xc5000_set_analog_params with new params about 
 switching.
 In this case inside saa7134 need know about zl10353 and configuration. I 
 don't understand how to do.
 The structure saa7134_dev hasn't pointer to the structure dvb_frontend. 
 Or use hardcoded i2c_addr and params.
 
 2.
 Direct call switch the switcher from the tuner code. In this case need know 
 TV card type. I think it is not so good idea.

The issues between FM and TV mode is only a small part of a big problem that 
we're currently
facing: drivers that support multiple types of streams, like radio, analog TV 
and digital TV
need a way to avoid conflicts between different parts of the driver, and 
between a DVB and a
V4L call.

The long-term solution seems to implement a tuner/frontend resource reservation 
routine. This 
will solve other problems as well, like having both analog and digital parts of 
the driver 
trying to access the same resource at the same time.

While implementing both analog and ISDB-T support for a saa7134-based board, I 
got one issue
where analog tuner were trying to do RF callibration while the DVB demod were 
initialized.
As the access to the demod requires one I2C gate setup and the access to the 
tuner requires
another setup, both operations failed.

We had similar problems in em28xx and cx231xx. Both were partially solved with 
a lock, but still
if the user tries to open both DVB and V4L interfaces, it will likely have 
problems.

So, we really need to implement some type of resource locking that will 
properly setup I2C gates,
RF gates, etc, depending on the type of resource currently in use.

Basically, the idea would be to implement something like:

enum frontend_resource {
ANALOG_TV_TUNER,
DIGITAL_TV_TUNER,
FM_TUNER,
ANALOG_DEMOD,
DIGITAL_DEMOD,
};

And add a new callback at struct dvb_frontend_ops():

int (*set_resource)(struct dvb_frontend* fe, enum frontend_resource, 
bool reserve);

Those callbacks may replace i2c_gate_ctrl().

With those changes, when a driver needs to access, for example, a tuner at a 
dvb part of the driver,
it would do:

fe-ops.set_resource(fe, DIGITAL_TV_TUNER, true);
/* All i2c transactions and other operations needed at tuner */
fe-ops.set_resource(fe, DIGITAL_TV_TUNER, false);

In other words, it will basically replace the current occurrences of 
i2c_gate_ctrl(), providing
a clearer indication that the I2C change needed are to enable the access to the 
tuner.

The fun begins if other parts of the driver try to do different things on 
resources that
may be shared. They can now say that they want to access the demod with:

fe-ops.set_resource(fe, DIGITAL_DEMOD, true);

So, demods operations will be protected by:

fe-ops.set_resource(fe, DIGITAL_DEMOD, true);
/* All i2c transactions and other operations applied on demod */
fe-ops.set_resource(fe, DIGITAL_DEMOD, false);

It is up to driver callback to handle this call. If both DIGITAL_DEMOD and 
DIGITAL_TV_TUNER are
at the same i2c bus (e.g. there's no i2c gate), and if there's no risk for one 
I2C access to affect
the other, the callback can just return 0. Otherwise, it may return -EBUSY and 
let the caller wait
for the resource to be freed with:
wake_up(fe-ops.set_resource(fe, DIGITAL_DEMOD, true) == 0);
or
wake_up_interruptible(fe-ops.set_resource(fe, DIGITAL_DEMOD, true) == 
0);

This way, when the resource is freed, the digital demod logic may happen.

Comments?

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


RE: [PATCH v2 1/2] V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library

2010-10-06 Thread Hiremath, Vaibhav
 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 1/2] V4L/DVB: OMAP_VOUT: Create a seperate vrfb
 functions library

 Create omap_vout_vrfb.c and omap_vout_vrfb.h, these contain functions
 which
 omap_vout will call if the rotation type is set to VRFB rotation. It is
 essentialy the code in omap_vout which is used for vrfb specific tasks.

 Apart from this, some functions and preprocessor defines needed by the new
 vrfb function's have been moved around.

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c  |   32 +--
  drivers/media/video/omap/omap_vout_vrfb.c |  417
 +
  drivers/media/video/omap/omap_vout_vrfb.h |   40 +++
  drivers/media/video/omap/omap_voutdef.h   |   25 ++
  4 files changed, 490 insertions(+), 24 deletions(-)
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h

 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 4ed51b1..46bc642
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -56,7 +56,6 @@ MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
  MODULE_LICENSE(GPL);

 -
  /* Driver Configuration macros */
  #define VOUT_NAMEomap_vout

 @@ -65,28 +64,13 @@ enum omap_vout_channels {
   OMAP_VIDEO2,
  };

 -enum dma_channel_state {
 - DMA_CHAN_NOT_ALLOTED,
 - DMA_CHAN_ALLOTED,
 -};
 -
  #define QQVGA_WIDTH  160
  #define QQVGA_HEIGHT 120

 -/* Max Resolution supported by the driver */
 -#define VID_MAX_WIDTH1280/* Largest width */
 -#define VID_MAX_HEIGHT   720 /* Largest height */
 -
[Hiremath, Vaibhav] I wanted to get rid of this sometime, but as of now we can 
live with this.

I would suggest to move QQVGA_xxx macros to header file to keep consistency.

  /* Mimimum requirement is 2x2 for DSS */
  #define VID_MIN_WIDTH2
  #define VID_MIN_HEIGHT   2

 -/* 2048 x 2048 is max res supported by OMAP display controller */
 -#define MAX_PIXELS_PER_LINE 2048
 -
 -#define VRFB_TX_TIMEOUT 1000
 -#define VRFB_NUM_BUFS4
 -
  /* Max buffer size tobe allocated during init */
  #define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)

 @@ -96,8 +80,8 @@ static u32 video1_numbuffers = 3;
  static u32 video2_numbuffers = 3;
  static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
 -static u32 vid1_static_vrfb_alloc;
 -static u32 vid2_static_vrfb_alloc;
 +u32 vid1_static_vrfb_alloc;
 +u32 vid2_static_vrfb_alloc;
[Hiremath, Vaibhav] Don't make this variable extern; I think these variables 
are being used during init time only so you can pass it as function argument.

  static int debug;

  /* Module parameters */
 @@ -174,7 +158,7 @@ const static struct v4l2_fmtdesc omap_formats[] = {
  /*
   * Allocate buffers
   */
 -static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
 +unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
[Hiremath, Vaibhav] This function can be moved to omap_voutlib.c file since it 
is something generic and independent.

  {
   u32 order, size;
   unsigned long virt_addr, addr;
 @@ -198,7 +182,7 @@ static unsigned long omap_vout_alloc_buffer(u32
 buf_size, u32 *phys_addr)
  /*
   * Free buffers
   */
 -static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
 +void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
  {
[Hiremath, Vaibhav] same here.

   u32 order, size;
   unsigned long addr = virtaddr;
 @@ -371,7 +355,7 @@ static void omap_vout_release_vrfb(struct
 omap_vout_device *vout)
  /*
   * Return true if rotation is 90 or 270
   */
 -static inline int rotate_90_or_270(const struct omap_vout_device *vout)
 +int rotate_90_or_270(const struct omap_vout_device *vout)
  {
[Hiremath, Vaibhav] You can move this to header file keeping it inline.
   return (vout-rotation == dss_rotation_90_degree ||
   vout-rotation == dss_rotation_270_degree);
 @@ -380,7 +364,7 @@ static inline int rotate_90_or_270(const struct
 omap_vout_device *vout)
  /*
   * Return true if rotation is enabled
   */
 -static inline int rotation_enabled(const struct omap_vout_device *vout)
 +int rotation_enabled(const struct omap_vout_device *vout)
[Hiremath, Vaibhav] ditto here.

  {
   return vout-rotation || vout-mirror;
  }
 @@ -388,7 +372,7 @@ static inline int rotation_enabled(const struct
 omap_vout_device *vout)
  /*
   * Reverse the rotation degree if mirroring is enabled
   */
 -static inline int calc_rotation(const struct omap_vout_device *vout)
 +int calc_rotation(const struct 

[linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!

2010-10-06 Thread Paul Gover
I've a cheap USB DVB key that won't work with Kaffeine.
It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U).
It shows up on Kaffeine's Configure Television dialog,
but scanning for channels finds nothing,
and tuning using an old channel list gives Sorry - no available device found

I had Kaffeine working OK with a different USB TV key.

dvbscan produces WARNING: tuning failed!!! messages.

The key works on XP using KWorld's HyperMedia Center.
Rebooting from there to Linux with warm USB key shows it contains 4.95.0 
firmware.  
At one point, such a warm reboot enabled Kaffeine to show TV.
That was with one of the early KDE4 Kaffeine candidates,
and an older linux kernel (sorry, I forget which).

Now using kernel modules in Linux version 2.6.34-gentoo-r6.
Kaffeine 1.0, KDE 4.4.5.  linuxtv-dvb-apps 1.1.1.20080317
on an ASUS EeePC 1000HE (Intel Atom processor).

Diagnostic stuff

lsusb -v :

Bus 001 Device 023: ID 1b80:e396 Afatech 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x1b80 Afatech
  idProduct  0xe396 
  bcdDevice2.00
  iManufacturer   1 Afatech
  iProduct2 DVB-T 2
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

lsmod :

Module  Size  Used by
ppp_deflate 3156  0 
zlib_deflate   17980  1 ppp_deflate
zlib_inflate   14197  1 ppp_deflate
bsd_comp4568  0 
ppp_async   6283  1 
crc_ccitt   1023  1 ppp_async
ppp_generic14958  7 ppp_deflate,bsd_comp,ppp_async
slhc4431  1 ppp_generic
sr_mod 10825  0 
cdrom  29800  1 sr_mod
option 18224  1 
usbserial  24352  4 option
snd_seq_oss23625  0 
snd_seq_midi_event  4280  1 snd_seq_oss
snd_seq39723  4 snd_seq_oss,snd_seq_midi_event
snd_seq_device  4109  2 snd_seq_oss,snd_seq
snd_pcm_oss30331  0 
snd_mixer_oss  12481  1 snd_pcm_oss
snd_hda_codec_realtek   187652  1 
qt1010  4461  1 
snd_hda_intel  16732  2 
af9013 17817  1 
snd_hda_codec  42659  2 snd_hda_codec_realtek,snd_hda_intel
snd_pcm50564  3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
dvb_usb_af9015 24963  0 

Re: gspca, audio and ov534: regression.

2010-10-06 Thread Antonio Ospite
On Wed, 6 Oct 2010 13:48:55 +0200
Jean-Francois Moine moin...@free.fr wrote:

 On Wed, 6 Oct 2010 12:33:21 +0200
 Antonio Ospite osp...@studenti.unina.it wrote:
 
  with 2.6.36-rc6 I can't use the ov534 gspca subdriver (with PS3 eye)
  anymore, when I try to capture video in dmesg I get:
  gspca: no transfer endpoint found
  
  If I revert commit 35680ba I can make video capture work again but I
  still don't get the audio device in pulseaudio, it shows up in
  alsamixer but if I try to select it, on the console I get:
  cannot load mixer controls: Invalid argument
  
[...]
 
 I think I see why the commit prevents the webcam to work: as it is
 done, the choice of the alternate setting does not work with bulk
 transfer. A simple fix could be to also check bulk transfer when
 skipping an alt setting in the function get_ep().


Thanks, the following change fixes it, was this what you had in mind?

diff --git a/drivers/media/video/gspca/gspca.c 
b/drivers/media/video/gspca/gspca.c
index b984610..30e0b32 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -651,7 +651,7 @@ static struct usb_host_endpoint *get_ep(struct gspca_dev 
*gspca_dev)
   : USB_ENDPOINT_XFER_ISOC;
i = gspca_dev-alt; /* previous alt setting */
if (gspca_dev-cam.reverse_alts) {
-   if (gspca_dev-audio)
+   if (gspca_dev-audio  !gspca_dev-cam.bulk)
i++;
while (++i  gspca_dev-nbalt) {
ep = alt_xfer(intf-altsetting[i], xfer);
@@ -659,7 +659,7 @@ static struct usb_host_endpoint *get_ep(struct gspca_dev 
*gspca_dev)
break;
}
} else {
-   if (gspca_dev-audio)
+   if (gspca_dev-audio  !gspca_dev-cam.bulk)
i--;
while (--i = 0) {
ep = alt_xfer(intf-altsetting[i], xfer);


 About audio stream, I do not see how it can have been broken.


PS3 Eye audio is working with linux-2.6.33.7 it is broken in
linux-2.6.35.7 already, I'll try to further narrow down the interval.
Ah, alsamixer doesn't work even when the device is OK in pulseaudio...

 Might you send me the full USB information of your webcam?


You can find lsusb output attached.

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?


lsusb_pseye.log
Description: Binary data


pgpkUfYBytPEL.pgp
Description: PGP signature


RE: [PATCH v2 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB

2010-10-06 Thread Hiremath, Vaibhav
 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build
 without VRFB
 
 This lets omap_vout driver build and run without VRFB. It works along the
 lines of the following patch series:
 
 OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
 https://patchwork.kernel.org/patch/105371/
 
 Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb
 specific functions have been defined and placed in omap_vout_vrfb.c
 
 A variable rotation_type is introduced in omapvideo_info like the way in
 omapfb_info, this allows to call vrfb specific functions only if the
 rotation
 type is vrfb. When the rotation_type is set to SDMA, the S_CTRL ioctl
 prevents
 the user setting a non zero rotation value.
 
[Hiremath, Vaibhav] Lets make one stand here,

I think this series still doesn't support DMA based rotation, unlike Fbdev 
driver so I would say lets clearly state that we are not supporting sDMA based 
rotation here. So I don't see any reason why we need 

 Archit Taneja (2):
   V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library
   V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and
 sdram buffers
 
  drivers/media/video/omap/Kconfig  |1 -
  drivers/media/video/omap/Makefile |1 +
  drivers/media/video/omap/omap_vout.c  |  480 ++--
 -
  drivers/media/video/omap/omap_vout_vrfb.c |  417
 +
  drivers/media/video/omap/omap_vout_vrfb.h |   40 +++
  drivers/media/video/omap/omap_voutdef.h   |   26 ++
  6 files changed, 571 insertions(+), 394 deletions(-)
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
 --
 Version 2:
  - Don't try to enable SDRAM rotation , return an error if non zero
 rotation
is attempted when rotation_type is set to SDMA rotation.
 Version 1:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg21937.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


RE: [PATCH v2 2/2] V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram buffers

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 2/2] V4L/DVB: OMAP_VOUT: Use rotation_type to choose
 between vrfb and sdram buffers

 Add rotation_type member to omapvideo_info, this is initialized based on
 the value def_vrfb bootarg parameter, vrfb rotation is chosen by
 default.
 The rotation_type var is now used to choose between vrfb and non-vrfb
 calls.

 vrfb specific code in omap_vout has been removed and is present in
 omap_vout_vrfb.c

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/Kconfig|1 -
  drivers/media/video/omap/Makefile   |1 +
  drivers/media/video/omap/omap_vout.c|  448 ++
 -
  drivers/media/video/omap/omap_voutdef.h |1 +
  4 files changed, 81 insertions(+), 370 deletions(-)

 diff --git a/drivers/media/video/omap/Kconfig
 b/drivers/media/video/omap/Kconfig
 index e63233f..d554bfd
 --- a/drivers/media/video/omap/Kconfig
 +++ b/drivers/media/video/omap/Kconfig
 @@ -5,7 +5,6 @@ config VIDEO_OMAP2_VOUT
   select VIDEOBUF_DMA_CONTIG
   select OMAP2_DSS
   select OMAP2_VRAM
 - select OMAP2_VRFB
[Hiremath, Vaibhav] Don't remove it, select for OMAP3 family of devices.

   default n
   ---help---
 V4L2 Display driver support for OMAP2/3 based boards.
 diff --git a/drivers/media/video/omap/Makefile
 b/drivers/media/video/omap/Makefile
 index b287880..bc47569
 --- a/drivers/media/video/omap/Makefile
 +++ b/drivers/media/video/omap/Makefile
 @@ -5,3 +5,4 @@
  # OMAP2/3 Display driver
  omap-vout-y := omap_vout.o omap_voutlib.o
  obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
 +obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 46bc642..4d61ee0
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -51,6 +51,7 @@

  #include omap_voutlib.h
  #include omap_voutdef.h
 +#include omap_vout_vrfb.h

  MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
 @@ -82,6 +83,7 @@ static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  u32 vid1_static_vrfb_alloc;
  u32 vid2_static_vrfb_alloc;
 +static int def_vrfb = 1;
  static int debug;

  /* Module parameters */
 @@ -109,6 +111,10 @@ module_param(vid2_static_vrfb_alloc, bool, S_IRUGO);
  MODULE_PARM_DESC(vid2_static_vrfb_alloc,
   Static allocation of the VRFB buffer for video2 device);

 +module_param(def_vrfb, bool, S_IRUGO);
[Hiremath, Vaibhav] Till the time we don't come up with Tiler (for that matter 
any other way of rotating image) based rotation mechanism, I wouldn't want to 
change/introduce any new interface.

 +MODULE_PARM_DESC(def_vrfb,
 + decide if vrfb is used for rotation);
 +
  module_param(debug, bool, S_IRUGO);
  MODULE_PARM_DESC(debug, Debug level (0-1));

 @@ -199,41 +205,6 @@ void omap_vout_free_buffer(unsigned long virtaddr,
 u32 buf_size)
  }

  /*
 - * Function for allocating video buffers
 - */
 -static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
 - unsigned int *count, int startindex)
 -{
 - int i, j;
 -
 - for (i = 0; i  *count; i++) {
 - if (!vout-smsshado_virt_addr[i]) {
 - vout-smsshado_virt_addr[i] =
 - omap_vout_alloc_buffer(vout-smsshado_size,
 - vout-smsshado_phy_addr[i]);
 - }
 - if (!vout-smsshado_virt_addr[i]  startindex != -1) {
 - if (V4L2_MEMORY_MMAP == vout-memory  i = startindex)
 - break;
 - }
 - if (!vout-smsshado_virt_addr[i]) {
 - for (j = 0; j  i; j++) {
 - omap_vout_free_buffer(
 - vout-smsshado_virt_addr[j],
 - vout-smsshado_size);
 - vout-smsshado_virt_addr[j] = 0;
 - vout-smsshado_phy_addr[j] = 0;
 - }
 - *count = 0;
 - return -ENOMEM;
 - }
 - memset((void *) vout-smsshado_virt_addr[i], 0,
 - vout-smsshado_size);
 - }
 - return 0;
 -}
 -
 -/*
   * Try format
   */
  static int omap_vout_try_format(struct v4l2_pix_format *pix)
 @@ -326,33 +297,6 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
  }

  /*
 - * Wakes up the application once the DMA transfer to VRFB space is
 completed.
 - */
 -static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void
 *data)
 -{
 - struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
 -
 - 

Re: [RFC/PATCH v2 0/6] OMAP3 ISP driver

2010-10-06 Thread Laurent Pinchart
Hi Vaibhav,

On Wednesday 06 October 2010 11:56:23 Hiremath, Vaibhav wrote:
 On Tuesday, October 05, 2010 6:49 PM Laurent Pinchart wrote:
  
  Hi everybody,
  
  Here's the second version of the OMAP3 ISP driver, rebased on top of the
  latest media controller and sub-device API patches.
  
  As with the previous version, the V4L/DVB patches come from the upstream
  staging/v2.6.37 branch and won't be needed anymore when the driver will
  be rebased on top of 2.6.36.
  
  Patch 6/6 (the driver itself) is too big for vger, even in compressed
  form. You can find it at
  http://git.linuxtv.org/pinchartl/media.git?h=refs/heads/media-0004-
  omap3isp (sorry for the inconvenience). I'll try splitting up the patch in
  the next version for easier review.

[snip]

 Hi Laurent,
 
 I have some specific comment on this patch series, especially from
 re-usability point of view.
 
 I have made this comment earlier as well during Helsinki conference, I am
 not quite sure whether you remember this or not.

Yes I do. I haven't had time to take that into account yet to, as most of my 
time was spent consolidating this patch series to get the driver ready for 
submission.

 Let me introduce some SoC's here,
 
 OMAP3530/OMAP3730/OMAP3430/OMAP3630 -
 
 I am pretty sure that your patch addresses all the requirement and is being
 tested for this SoC family. Infact I am also working on this along side to
 validate it and add some feature support on top of other platforms, like
 OMAP3EVM, Beagle, BeagleXM, etc..

That's right, that's the chip family I'm working with. The driver has been 
tested (to various degrees) on the 3430, 3530 and 3630. I'm not aware of 
anyone using it on the 3730 (but there could be silent users).

 So I do not have any specific comments here,
 
 AM3517 -
 
 AM3517 is another SoC, inheriting most of the IP's/modules from OMAP3, but
 in case of Capture module it only uses CCDC front end module of the ISP.
 Another difference is the output data pins become 16-bit in this case,
 since it doesn't have any support for bridge/lane-shifter.
 
 I would want to re-use CCDC sub-device driver here, have you thought of
 this?

I've had a look at the AM3517 datasheet. The CCDC looks similar indeed 
(registers have identical addresses, that's a good start), but there's a major 
difference regarding memory management, as the AM3517 has no IOMMU. An 
alternative isp_video implementation would be needed. This isn't an easy task, 
but it's worth looking at how code could be reused.

 DM6446 (Davinci  Family)
 -
 Specifically I am will take DM6446 SoC here (which is near to OMAP), since
 it has almost same building blocks inside ISP, except all serial (MIPI
 CSI) interfaces.
 
 Also here I would want to re-use almost all the components like, CCDC,
 Resizer, Previewer, etc... Also DM355 (OR 365 I don't remember correctly)
 but one of them support 2 instance of resizer module.

Once again a bit difference is the lack of IOMMU. The rest looks pretty 
similar indeed.

 Here it might be easy to tweak the code in order to re-use but in case of
 AM3517 I am not sure how do we want to handle this.

Do you think we should start with the AM3517 or the DM6446 ? While the DM6446 
ISP is closer to the OMAP3 ISP, it's also more complex, so more code will need 
to be verified and modified.

 The intent is not to block this patch series, but to give some food to our
 brains and have healthy discussion here. We could add all this support on
 top of it, I am ok with this.

That's good, because I wasn't going to hold the OMAP3 ISP driver until it can 
support all other TI chips :-)

 I am also reviewing the patch series and comments are following this
 post...

Thanks.

-- 
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: [RFC/PATCH v2 0/6] OMAP3 ISP driver

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, October 06, 2010 7:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
 Subject: Re: [RFC/PATCH v2 0/6] OMAP3 ISP driver
 
 Hi Vaibhav,
 
 On Wednesday 06 October 2010 11:56:23 Hiremath, Vaibhav wrote:
  On Tuesday, October 05, 2010 6:49 PM Laurent Pinchart wrote:
  
   Hi everybody,
  
   Here's the second version of the OMAP3 ISP driver, rebased on top of
 the
   latest media controller and sub-device API patches.
  
   As with the previous version, the V4L/DVB patches come from the
 upstream
   staging/v2.6.37 branch and won't be needed anymore when the driver
 will
   be rebased on top of 2.6.36.
  
   Patch 6/6 (the driver itself) is too big for vger, even in compressed
   form. You can find it at
   http://git.linuxtv.org/pinchartl/media.git?h=refs/heads/media-0004-
   omap3isp (sorry for the inconvenience). I'll try splitting up the
 patch in
   the next version for easier review.
 
 [snip]
 
  Hi Laurent,
 
  I have some specific comment on this patch series, especially from
  re-usability point of view.
 
  I have made this comment earlier as well during Helsinki conference, I
 am
  not quite sure whether you remember this or not.
 
 Yes I do. I haven't had time to take that into account yet to, as most of
 my
 time was spent consolidating this patch series to get the driver ready for
 submission.
 
  Let me introduce some SoC's here,
 
  OMAP3530/OMAP3730/OMAP3430/OMAP3630 -
  
  I am pretty sure that your patch addresses all the requirement and is
 being
  tested for this SoC family. Infact I am also working on this along side
 to
  validate it and add some feature support on top of other platforms, like
  OMAP3EVM, Beagle, BeagleXM, etc..
 
 That's right, that's the chip family I'm working with. The driver has been
 tested (to various degrees) on the 3430, 3530 and 3630. I'm not aware of
 anyone using it on the 3730 (but there could be silent users).
 
  So I do not have any specific comments here,
[Hiremath, Vaibhav] You can consider me into this. We are using AM/DM3730 which 
is exactly same as OMAP3630.

Thanks,
Vaibhav

 
  AM3517 -
  
  AM3517 is another SoC, inheriting most of the IP's/modules from OMAP3,
 but
  in case of Capture module it only uses CCDC front end module of the ISP.
  Another difference is the output data pins become 16-bit in this case,
  since it doesn't have any support for bridge/lane-shifter.
 
  I would want to re-use CCDC sub-device driver here, have you thought of
  this?
 
 I've had a look at the AM3517 datasheet. The CCDC looks similar indeed
 (registers have identical addresses, that's a good start), but there's a
 major
 difference regarding memory management, as the AM3517 has no IOMMU. An
 alternative isp_video implementation would be needed. This isn't an easy
 task,
 but it's worth looking at how code could be reused.
 
  DM6446 (Davinci  Family)
  -
  Specifically I am will take DM6446 SoC here (which is near to OMAP),
 since
  it has almost same building blocks inside ISP, except all serial (MIPI
  CSI) interfaces.
 
  Also here I would want to re-use almost all the components like, CCDC,
  Resizer, Previewer, etc... Also DM355 (OR 365 I don't remember
 correctly)
  but one of them support 2 instance of resizer module.
 
 Once again a bit difference is the lack of IOMMU. The rest looks pretty
 similar indeed.
 
  Here it might be easy to tweak the code in order to re-use but in case
 of
  AM3517 I am not sure how do we want to handle this.
 
 Do you think we should start with the AM3517 or the DM6446 ? While the
 DM6446
 ISP is closer to the OMAP3 ISP, it's also more complex, so more code will
 need
 to be verified and modified.
 
  The intent is not to block this patch series, but to give some food to
 our
  brains and have healthy discussion here. We could add all this support
 on
  top of it, I am ok with this.
 
 That's good, because I wasn't going to hold the OMAP3 ISP driver until it
 can
 support all other TI chips :-)
 
  I am also reviewing the patch series and comments are following this
  post...
 
 Thanks.
 
 --
 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: gspca, audio and ov534: regression.

2010-10-06 Thread Antonio Ospite
On Wed, 6 Oct 2010 16:04:41 +0200
Antonio Ospite osp...@studenti.unina.it wrote:

 On Wed, 6 Oct 2010 13:48:55 +0200
 Jean-Francois Moine moin...@free.fr wrote:
 
  On Wed, 6 Oct 2010 12:33:21 +0200
  Antonio Ospite osp...@studenti.unina.it wrote:
  
   with 2.6.36-rc6 I can't use the ov534 gspca subdriver (with PS3 eye)
   anymore, when I try to capture video in dmesg I get:
   gspca: no transfer endpoint found
   
   If I revert commit 35680ba I can make video capture work again but I
   still don't get the audio device in pulseaudio, it shows up in
   alsamixer but if I try to select it, on the console I get:
   cannot load mixer controls: Invalid argument
   
[...]
  About audio stream, I do not see how it can have been broken.
 
 
 PS3 Eye audio is working with linux-2.6.33.7 it is broken in
 linux-2.6.35.7 already, I'll try to further narrow down the interval.
 Ah, alsamixer doesn't work even when the device is OK in pulseaudio...
 

I was wrong, the audio part works even in 2.6.36-rc6 but _only_ when
the webcam is plugged in from boot, could this have to do with the order
gspca and snd-usb-audio are loaded?

Regards,
   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?


pgpjmnZzEvzUY.pgp
Description: PGP signature


Re: [v4l/dvb] identification/ fixed registration order of DVB cards

2010-10-06 Thread VDR User
Can't this be forced using udev rules?
--
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: gspca, audio and ov534: regression.

2010-10-06 Thread Jean-Francois Moine
On Wed, 6 Oct 2010 16:04:41 +0200
Antonio Ospite osp...@studenti.unina.it wrote:

 Thanks, the following change fixes it, was this what you had in mind?
 
 diff --git a/drivers/media/video/gspca/gspca.c
 b/drivers/media/video/gspca/gspca.c index b984610..30e0b32 100644
 --- a/drivers/media/video/gspca/gspca.c
 +++ b/drivers/media/video/gspca/gspca.c
 @@ -651,7 +651,7 @@ static struct usb_host_endpoint *get_ep(struct
 gspca_dev *gspca_dev) : USB_ENDPOINT_XFER_ISOC;
 i = gspca_dev-alt; /* previous alt
 setting */ if (gspca_dev-cam.reverse_alts) {
 -   if (gspca_dev-audio)
 +   if (gspca_dev-audio  !gspca_dev-cam.bulk)
 i++;
 while (++i  gspca_dev-nbalt) {
 ep = alt_xfer(intf-altsetting[i], xfer);
 @@ -659,7 +659,7 @@ static struct usb_host_endpoint *get_ep(struct
 gspca_dev *gspca_dev) break;
 }
 } else {
 -   if (gspca_dev-audio)
 +   if (gspca_dev-audio  !gspca_dev-cam.bulk)
 i--;
 while (--i = 0) {
 ep = alt_xfer(intf-altsetting[i], xfer);

Yes, but, after thought, as there is only one alternate setting, the
tests could be:
if (gspca_dev-audio  i  gspca_dev-nbalt - 1)
and
if (gspca_dev-audio  i  0)

This should work also for isochronous transfers.

regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS

2010-10-06 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:Wed Oct  6 19:00:18 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   15164:1da5fed5c8b2
git master:   3e6dce76d99b328716b43929b9195adfee1de00c
git media-master: c8dd732fd119ce6d562d5fa82a10bbe75a376575
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.32.6-armv5: WARNINGS
linux-2.6.33-armv5: WARNINGS
linux-2.6.34-armv5: WARNINGS
linux-2.6.35.3-armv5: WARNINGS
linux-2.6.32.6-armv5-davinci: ERRORS
linux-2.6.33-armv5-davinci: ERRORS
linux-2.6.34-armv5-davinci: ERRORS
linux-2.6.35.3-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: ERRORS
linux-2.6.33-armv5-ixp: ERRORS
linux-2.6.34-armv5-ixp: ERRORS
linux-2.6.35.3-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: ERRORS
linux-2.6.33-armv5-omap2: ERRORS
linux-2.6.34-armv5-omap2: ERRORS
linux-2.6.35.3-armv5-omap2: ERRORS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.32.6-m32r: WARNINGS
linux-2.6.33-m32r: WARNINGS
linux-2.6.34-m32r: WARNINGS
linux-2.6.35.3-m32r: WARNINGS
linux-2.6.32.6-mips: WARNINGS
linux-2.6.33-mips: WARNINGS
linux-2.6.34-mips: WARNINGS
linux-2.6.35.3-mips: WARNINGS
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35.3-powerpc64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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


Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!

2010-10-06 Thread Antti Palosaari
It is QT1010 tuner driver issue. None is working for that currently or 
in near future. Feel free to fix :]


Antti

On 10/06/2010 04:56 PM, Paul Gover wrote:

I've a cheap USB DVB key that won't work with Kaffeine.
It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U).
It shows up on Kaffeine's Configure Television dialog,
but scanning for channels finds nothing,
and tuning using an old channel list gives Sorry - no available device found

I had Kaffeine working OK with a different USB TV key.

dvbscan produces WARNING:  tuning failed!!! messages.

The key works on XP using KWorld's HyperMedia Center.
Rebooting from there to Linux with warm USB key shows it contains 4.95.0
firmware.
At one point, such a warm reboot enabled Kaffeine to show TV.
That was with one of the early KDE4 Kaffeine candidates,
and an older linux kernel (sorry, I forget which).

Now using kernel modules in Linux version 2.6.34-gentoo-r6.
Kaffeine 1.0, KDE 4.4.5.  linuxtv-dvb-apps 1.1.1.20080317
on an ASUS EeePC 1000HE (Intel Atom processor).

Diagnostic stuff

lsusb -v :

Bus 001 Device 023: ID 1b80:e396 Afatech
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   idVendor   0x1b80 Afatech
   idProduct  0xe396
   bcdDevice2.00
   iManufacturer   1 Afatech
   iProduct2 DVB-T 2
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   46
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0x80
   (Bus Powered)
 MaxPower  500mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   4
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  0
   bInterfaceProtocol  0
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x02  EP 2 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x84  EP 4 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x85  EP 5 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
Device Qualifier (for other device speed):
   bLength10
   bDescriptorType 6
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   bNumConfigurations  1
Device Status: 0x
   (Bus Powered)

lsmod :

Module  Size  Used by
ppp_deflate 3156  0
zlib_deflate   17980  1 ppp_deflate
zlib_inflate   14197  1 ppp_deflate
bsd_comp4568  0
ppp_async   6283  1
crc_ccitt   1023  1 ppp_async
ppp_generic14958  7 ppp_deflate,bsd_comp,ppp_async
slhc4431  1 ppp_generic
sr_mod 10825  0
cdrom  29800  1 sr_mod
option 18224  1
usbserial  24352  4 option
snd_seq_oss23625  0
snd_seq_midi_event  4280  1 snd_seq_oss
snd_seq39723  4 snd_seq_oss,snd_seq_midi_event
snd_seq_device  4109  2 snd_seq_oss,snd_seq
snd_pcm_oss30331  0
snd_mixer_oss  12481  1 snd_pcm_oss
snd_hda_codec_realtek   187652  1
qt1010  4461  1
snd_hda_intel 

[PATCH]UPDATE for LME2510(C) DM04/QQBOX USB DVB-S BOXES.

2010-10-06 Thread tvbox
Updated driver for DM04/QQBOX USB DVB-S BOXES to version 1.50

These include
-later kill of usb_buffer to avoid kernel crash on hot unplugging.
-DiSEqC functions.
-LNB Power switch
-Faster channel change.

Signed-off-by: Malcolm Priestley tvbox...@gmail.com

http://mercurial.intuxication.org/hg/tvboxspy/summary

---

diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c 
b/drivers/media/dvb/dvb-usb/lmedm04.c
index 794b16d..3569e34 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -51,10 +51,7 @@
  * LME2510: Non Intel USB chipsets fail to maintain High Speed on
  * Boot or Hot Plug.
  *
- * DiSEqC functions are not fully supported in this driver. The main
- * reason is the frontend is cut off during streaming. Allowing frontend
- * access will stall the driver. Applications that attempt to this, the
- * commands are ignored.
+ * QQbox suffers from noise on LNB voltage.
  *
  * PID functions mave been removed from this driver version due to
  * problems with different firmware and application versions.
@@ -154,15 +151,15 @@ static int lme2510_usb_talk(struct dvb_usb_device *d,
return -EAGAIN;
 
ret |= usb_clear_halt(d-udev, usb_sndbulkpipe(d-udev, 0x01));
-   msleep(5);
-   ret |= lme2510_bulk_write(d-udev, buff, wlen , 0x1);
 
-   msleep(5);
-   ret |= usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x1));
+   ret |= lme2510_bulk_write(d-udev, buff, wlen , 0x01);
+
+   msleep(12);
+
+   ret |= usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x01));
 
-   msleep(5);
ret |= lme2510_bulk_read(d-udev, buff, (rlen  512) ?
-   512 : rlen , 0x1);
+   512 : rlen , 0x01);
 
if (rlen  0)
memcpy(rbuf, buff, rlen);
@@ -172,6 +169,19 @@ static int lme2510_usb_talk(struct dvb_usb_device *d,
return (ret  0) ? -ENODEV : 0;
 }
 
+static int lme2510_usb_talk_restart(struct dvb_usb_device *d,
+   u8 *wbuf, int wlen, u8 *rbuf, int rlen) {
+   static u8 stream_on[] = LME_ST_ON_W;
+   int ret;
+   u8 rbuff[1];
+   /*Send Normal Command*/
+   ret = lme2510_usb_talk(d, wbuf, wlen, rbuf, rlen);
+   /*Restart Stream Command*/
+   ret |= lme2510_usb_talk(d, stream_on, sizeof(stream_on),
+   rbuff, sizeof(rbuff));
+   return ret;
+}
+
 static int lme2510_remote_keypress(struct dvb_usb_adapter *adap, u16 keypress)
 {
struct dvb_usb_device *d = adap-dev;
@@ -233,7 +243,7 @@ static void lme2510_int_response(struct urb *lme_urb)
/* Tweak for earlier firmware*/
if (ibuf[1] == 0x03) {
st-signal_level = ibuf[3];
-   st-signal_sn = ibuf[2];
+   st-signal_sn = ibuf[4];
} else {
st-signal_level = ibuf[4];
st-signal_sn = ibuf[5];
@@ -318,6 +328,7 @@ static int lme2510_msg(struct dvb_usb_device *d,
case TUNER_S7395:
if (wbuf[3] == 0x24)
st-signal_lock = rbuf[1];
+   msleep(5);
break;
default:
break;
@@ -358,6 +369,18 @@ static int lme2510_msg(struct dvb_usb_device *d,
rbuf[0] = 0x55;
rbuf[1] = (st-signal_level  0x80)
? 0 : st-signal_lock;
+   break;
+   /*DiSEqC functions as per STV0288*/
+   case 0x5:
+   case 0x6:
+   case 0x7:
+   case 0x8:
+   case 0x9:
+   case 0xa:
+   case 0xb:
+   if (wbuf[2] == 0xd0)
+   lme2510_usb_talk_restart(d,
+   wbuf, wlen, rbuf, rlen);
default:
break;
}
@@ -472,7 +495,6 @@ static int lme2510_identify_state(struct usb_device *udev,
 static int lme2510_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
 {
struct lme2510_state *st = adap-dev-priv;
-   static u8 reset[] =  LME_RESET;
static u8 stream_on[] = LME_ST_ON_W;
static u8 clear_reg_3[] =  LME_CLEAR_PID;
static u8 rbuf[1];
@@ -481,19 +503,14 @@ static int lme2510_streaming_ctrl(struct dvb_usb_adapter 
*adap, int onoff)
 
if (onoff == 1) {
st-i2c_talk_onoff = 0;
-   msleep(400); /* give enough time for i2c to stop */
+   msleep(40); /* give enough time for i2c to stop */
ret |= 

Re: [PATCH] vivi: Don't depend on FONTS

2010-10-06 Thread Randy Dunlap

| - Original Message -
| From: b...@decadent.org.uk
| To: mche...@infradead.org
| Cc: linux-media@vger.kernel.org, randy.dun...@oracle.com
| Sent: Sunday, October 3, 2010 6:18:33 PM GMT -08:00 US/Canada Pacific
| Subject: [PATCH] vivi: Don't depend on FONTS
| 
| CONFIG_FONTS has nothing to do with whether find_font() is defined.
| 
| Signed-off-by: Ben Hutchings b...@decadent.org.uk
---

True.  I wonder how my patch mattered before, when I tested it.

Anyway:
Acked-by: Randy Dunlap randy.dun...@oracle.com

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


Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!

2010-10-06 Thread dave cunningham

In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote

It is QT1010 tuner driver issue. None is working for that currently or 
in near future. Feel free to fix :]




The wiki appears to show this stick as working. 
http://linuxtv.org/wiki/index.php/Afatech_AF9015.


Is this information incorrect or is it hit and miss depending on the 
host system?


Thanks,
David



Antti

On 10/06/2010 04:56 PM, Paul Gover wrote:

I've a cheap USB DVB key that won't work with Kaffeine.
It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U).
It shows up on Kaffeine's Configure Television dialog,
but scanning for channels finds nothing,
and tuning using an old channel list gives Sorry - no available 
device found


I had Kaffeine working OK with a different USB TV key.

dvbscan produces WARNING:  tuning failed!!! messages.

The key works on XP using KWorld's HyperMedia Center.
Rebooting from there to Linux with warm USB key shows it contains 4.95.0
firmware.
At one point, such a warm reboot enabled Kaffeine to show TV.
That was with one of the early KDE4 Kaffeine candidates,
and an older linux kernel (sorry, I forget which).

Now using kernel modules in Linux version 2.6.34-gentoo-r6.
Kaffeine 1.0, KDE 4.4.5.  linuxtv-dvb-apps 1.1.1.20080317
on an ASUS EeePC 1000HE (Intel Atom processor).

Diagnostic stuff

lsusb -v :

Bus 001 Device 023: ID 1b80:e396 Afatech
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   idVendor   0x1b80 Afatech
   idProduct  0xe396
   bcdDevice2.00
   iManufacturer   1 Afatech
   iProduct2 DVB-T 2
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   46
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0x80
   (Bus Powered)
 MaxPower  500mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   4
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  0
   bInterfaceProtocol  0
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x02  EP 2 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x84  EP 4 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x85  EP 5 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
Device Qualifier (for other device speed):
   bLength10
   bDescriptorType 6
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   bNumConfigurations  1
Device Status: 0x
   (Bus Powered)

lsmod :

Module  Size  Used by
ppp_deflate 3156  0
zlib_deflate   17980  1 ppp_deflate
zlib_inflate   14197  1 ppp_deflate
bsd_comp4568  0
ppp_async   6283  1
crc_ccitt   1023  1 ppp_async
ppp_generic14958  7 ppp_deflate,bsd_comp,ppp_async
slhc4431  1 ppp_generic
sr_mod 10825  0
cdrom  29800  1 sr_mod
option 18224  1
usbserial  24352  4 option
snd_seq_oss23625  0
snd_seq_midi_event  4280  1 snd_seq_oss
snd_seq 

Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!

2010-10-06 Thread Antti Palosaari

On 10/06/2010 11:36 PM, dave cunningham wrote:

In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote


It is QT1010 tuner driver issue. None is working for that currently or
in near future. Feel free to fix :]



The wiki appears to show this stick as working.
http://linuxtv.org/wiki/index.php/Afatech_AF9015.

Is this information incorrect or is it hit and miss depending on the
host system?


It works but performance is poor. Usually it locks when RF signal is 
weak. If you fix bug around line 381 in qt1010.c it will work much 
better. But if you fix that it will break devices zl10353+qt1010 since 
zl10353 driver misses AGC configuration.


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


[no subject]

2010-10-06 Thread Halim Sahin
help
--
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] video: fix potential use-before-NULL-check crash

2010-10-06 Thread Kees Cook
Moves use to after NULL-check.

Signed-off-by: Kees Cook kees.c...@canonical.com
---

Sent before as part of https://patchwork.kernel.org/patch/138711/ but it
still hasn't been applied.

---
 drivers/media/video/em28xx/em28xx-video.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-video.c 
b/drivers/media/video/em28xx/em28xx-video.c
index 7b9ec6e..95a4b60 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -277,12 +277,13 @@ static void em28xx_copy_vbi(struct em28xx *dev,
 {
void *startwrite, *startread;
int  offset;
-   int bytesperline = dev-vbi_width;
+   int bytesperline;
 
if (dev == NULL) {
em28xx_isocdbg(dev is null\n);
return;
}
+   bytesperline = dev-vbi_width;
 
if (dma_q == NULL) {
em28xx_isocdbg(dma_q is null\n);
-- 
1.7.1


-- 
Kees Cook
Ubuntu Security Team
--
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] Resource reservation for frontend - Was: Re: xc5000 and switch RF input

2010-10-06 Thread Dmitri Belimov
Hi

 Em 06-10-2010 16:52, Dmitri Belimov escreveu:
  Hi
  
  Our TV card Behold X7 has two different RF input. This RF inputs
  can switch between different RF sources. 
  
  ANT 1 for analog and digital TV
  ANT 2 for FM radio
  
  The switch controlled by zl10353.
  
  How to I can control this switch?
  
  I found 2 way
  
  1. 
  Use tuner callback to saa1734. add some params like
  XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h call tuner
  callback from xc5000_set_analog_params with new params about
  switching. In this case inside saa7134 need know about zl10353 and
  configuration. I don't understand how to do. The structure
  saa7134_dev hasn't pointer to the structure dvb_frontend. Or use
  hardcoded i2c_addr and params.
  
  2.
  Direct call switch the switcher from the tuner code. In this case
  need know TV card type. I think it is not so good idea.
 
 The issues between FM and TV mode is only a small part of a big
 problem that we're currently facing: drivers that support multiple
 types of streams, like radio, analog TV and digital TV need a way to
 avoid conflicts between different parts of the driver, and between a
 DVB and a V4L call.
 
 The long-term solution seems to implement a tuner/frontend resource
 reservation routine. This will solve other problems as well, like
 having both analog and digital parts of the driver trying to access
 the same resource at the same time.
 
 While implementing both analog and ISDB-T support for a saa7134-based
 board, I got one issue where analog tuner were trying to do RF
 callibration while the DVB demod were initialized. As the access to
 the demod requires one I2C gate setup and the access to the tuner
 requires another setup, both operations failed.
 
 We had similar problems in em28xx and cx231xx. Both were partially
 solved with a lock, but still if the user tries to open both DVB and
 V4L interfaces, it will likely have problems.
 
 So, we really need to implement some type of resource locking that
 will properly setup I2C gates, RF gates, etc, depending on the type
 of resource currently in use.
 
 Basically, the idea would be to implement something like:
 
 enum frontend_resource {
   ANALOG_TV_TUNER,
   DIGITAL_TV_TUNER,
   FM_TUNER,
   ANALOG_DEMOD,
   DIGITAL_DEMOD,
 };
 
 And add a new callback at struct dvb_frontend_ops():
 
   int (*set_resource)(struct dvb_frontend* fe, enum
 frontend_resource, bool reserve);
 
 Those callbacks may replace i2c_gate_ctrl().
 
 With those changes, when a driver needs to access, for example, a
 tuner at a dvb part of the driver, it would do:
 
 fe-ops.set_resource(fe, DIGITAL_TV_TUNER, true);
 /* All i2c transactions and other operations needed at tuner */
 fe-ops.set_resource(fe, DIGITAL_TV_TUNER, false);
 
 In other words, it will basically replace the current occurrences of
 i2c_gate_ctrl(), providing a clearer indication that the I2C change
 needed are to enable the access to the tuner.
 
 The fun begins if other parts of the driver try to do different
 things on resources that may be shared. They can now say that they
 want to access the demod with:
 
 fe-ops.set_resource(fe, DIGITAL_DEMOD, true);
 
 So, demods operations will be protected by:
 
 fe-ops.set_resource(fe, DIGITAL_DEMOD, true);
   /* All i2c transactions and other operations applied on demod
 */ fe-ops.set_resource(fe, DIGITAL_DEMOD, false);
 
 It is up to driver callback to handle this call. If both
 DIGITAL_DEMOD and DIGITAL_TV_TUNER are at the same i2c bus (e.g.
 there's no i2c gate), and if there's no risk for one I2C access to
 affect the other, the callback can just return 0. Otherwise, it may
 return -EBUSY and let the caller wait for the resource to be freed
 with: wake_up(fe-ops.set_resource(fe, DIGITAL_DEMOD, true) == 0); or
   wake_up_interruptible(fe-ops.set_resource(fe, DIGITAL_DEMOD,
 true) == 0);
 
 This way, when the resource is freed, the digital demod logic may
 happen.
 
 Comments?

What about hardware encoders? May be need switch between some TV and encoders.
Switch input source, output bus and other.

With my best regards, Dmitry.

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


[GIT PULL for 2.6.36-rc7] V4L/DVB fixes

2010-10-06 Thread Mauro Carvalho Chehab
Hi Linus,

Please pull from:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus


It is basically a few fixes at V4L drivers, plus some fixes at IR core and 
one at V4L core (at videobuf).

All the patches are available at linux-next and should compile fine.


The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c:

  Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

Andy Walls (1):
  V4L/DVB: cx25840: Fix typo in volume control initialization: 65335 vs. 
65535

Baruch Siach (1):
  V4L/DVB: mx2_camera: fix a race causing NULL dereference

Brian Rogers (1):
  V4L/DVB: ir-core: Fix null dereferences in the protocols sysfs interface

Dan Carpenter (5):
  V4L/DVB: unlock on error path
  V4L/DVB: IR: ir-raw-event: null pointer dereference
  V4L/DVB: opera1: remove unneeded NULL check
  V4L/DVB: pvrusb2: remove unneeded NULL checks
  V4L/DVB: saa7164: move dereference under NULL check

Dan Rosenberg (1):
  V4L/DVB: ivtvfb: prevent reading uninitialized stack memory

Dmitri Belimov (1):
  V4L/DVB: Fix regression for BeholdTV Columbus

Hans Verkuil (1):
  V4L/DVB: videobuf-dma-sg: set correct size in last sg element

Ionut Gabriel Popescu (1):
  V4L/DVB: mt9v022.c: Fixed compilation warning

Jarod Wilson (1):
  V4L/DVB: mceusb: add two new ASUS device IDs

Jason Wang (1):
  V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch

Jean-François Moine (1):
  V4L/DVB: gspca - sn9c20x: Bad transfer size of Bayer images

Laurent Pinchart (2):
  V4L/DVB: uvcvideo: Fix support for Medion Akoya All-in-one PC integrated 
webcam
  V4L/DVB: uvcvideo: Restrict frame rates for Chicony CNF7129 webcam

Marek Szyprowski (1):
  V4L/DVB: v4l: radio: si470x: fix unneeded free_irq() call

Mauro Carvalho Chehab (3):
  V4L/DVB: Don't identify PV SBTVD Hybrid as a DibCom device
  V4L/DVB: rc-core: increase repeat time
  V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0)

Maxim Levitsky (3):
  V4L/DVB: IR: fix duty cycle capability
  V4L/DVB: IR: fix keys beeing stuck down forever
  V4L/DVB: IR: extend MCE keymap

Michael Grzeschik (2):
  V4L/DVB: mt9m111: cropcap and s_crop check if type is VIDEO_CAPTURE
  V4L/DVB: mt9m111: added current colorspace at g_fmt

Olivier Grenie (2):
  V4L/DVB: dib7770: enable the current mirror
  V4L/DVB: dib7000p: add disable sample and hold, and diversity delay 
parameter

Pawel Osciak (4):
  V4L/DVB: v4l: mem2mem_testdev: fix errorenous comparison
  V4L/DVB: v4l: mem2mem_testdev: add missing release for video_device
  V4L/DVB: v4l: s5p-fimc: Fix return value on probe() failure
  V4L/DVB: v4l: videobuf: prevent passing a NULL to dma_free_coherent()

Randy Dunlap (1):
  V4L/DVB: tm6000: depends on IR_CORE

Richard Zidlicky (1):
  V4L/DVB: dvb: fix smscore_getbuffer() logic

Stefan Ringel (1):
  V4L/DVB: tm6000: bugfix data handling

Sylwester Nawrocki (1):
  V4L/DVB: v4l: s5p-fimc: Fix 3-planar formats handling and pixel offset 
error on S5PV210 SoCs

lawrence rust (1):
  V4L/DVB: cx88: Kconfig: Remove EXPERIMENTAL dependency from 
VIDEO_CX88_ALSA

 drivers/media/IR/ir-keytable.c|9 ++-
 drivers/media/IR/ir-lirc-codec.c  |2 +-
 drivers/media/IR/ir-raw-event.c   |4 +-
 drivers/media/IR/ir-sysfs.c   |   17 +++--
 drivers/media/IR/keymaps/rc-rc6-mce.c |3 +
 drivers/media/IR/mceusb.c |4 +
 drivers/media/dvb/dvb-usb/dib0700_core.c  |3 -
 drivers/media/dvb/dvb-usb/dib0700_devices.c   |   56 ++-
 drivers/media/dvb/dvb-usb/opera1.c|4 +-
 drivers/media/dvb/frontends/dib7000p.c|8 ++-
 drivers/media/dvb/frontends/dib7000p.h|5 ++
 drivers/media/dvb/siano/smscoreapi.c  |   31 +++-
 drivers/media/radio/si470x/radio-si470x-i2c.c |2 +-
 drivers/media/video/cx231xx/Makefile  |1 +
 drivers/media/video/cx231xx/cx231xx-cards.c   |   17 +++--
 drivers/media/video/cx25840/cx25840-core.c|2 +-
 drivers/media/video/cx88/Kconfig  |2 +-
 drivers/media/video/gspca/gspca.c |1 +
 drivers/media/video/gspca/sn9c20x.c   |3 +-
 drivers/media/video/ivtv/ivtvfb.c |2 +
 drivers/media/video/mem2mem_testdev.c |3 +-
 drivers/media/video/mt9m111.c |8 ++-
 drivers/media/video/mt9v022.c |3 -
 drivers/media/video/mx2_camera.c  |4 +
 drivers/media/video/pvrusb2/pvrusb2-ctrl.c|6 +-
 drivers/media/video/s5p-fimc/fimc-core.c  |   94 +++--
 drivers/media/video/saa7134/saa7134-cards.c   |   10 ++--
 drivers/media/video/saa7164/saa7164-buffer.c  |5 +-
 

Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input

2010-10-06 Thread Mauro Carvalho Chehab
Em 07-10-2010 10:00, Dmitri Belimov escreveu:
 Hi
 
 Em 06-10-2010 16:52, Dmitri Belimov escreveu:
 Hi

 Our TV card Behold X7 has two different RF input. This RF inputs
 can switch between different RF sources. 

 ANT 1 for analog and digital TV
 ANT 2 for FM radio

 The switch controlled by zl10353.

 How to I can control this switch?

 I found 2 way

 1. 
 Use tuner callback to saa1734. add some params like
 XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h call tuner
 callback from xc5000_set_analog_params with new params about
 switching. In this case inside saa7134 need know about zl10353 and
 configuration. I don't understand how to do. The structure
 saa7134_dev hasn't pointer to the structure dvb_frontend. Or use
 hardcoded i2c_addr and params.

 2.
 Direct call switch the switcher from the tuner code. In this case
 need know TV card type. I think it is not so good idea.

 The issues between FM and TV mode is only a small part of a big
 problem that we're currently facing: drivers that support multiple
 types of streams, like radio, analog TV and digital TV need a way to
 avoid conflicts between different parts of the driver, and between a
 DVB and a V4L call.

 The long-term solution seems to implement a tuner/frontend resource
 reservation routine. This will solve other problems as well, like
 having both analog and digital parts of the driver trying to access
 the same resource at the same time.

 While implementing both analog and ISDB-T support for a saa7134-based
 board, I got one issue where analog tuner were trying to do RF
 callibration while the DVB demod were initialized. As the access to
 the demod requires one I2C gate setup and the access to the tuner
 requires another setup, both operations failed.

 We had similar problems in em28xx and cx231xx. Both were partially
 solved with a lock, but still if the user tries to open both DVB and
 V4L interfaces, it will likely have problems.

 So, we really need to implement some type of resource locking that
 will properly setup I2C gates, RF gates, etc, depending on the type
 of resource currently in use.

 Basically, the idea would be to implement something like:

 enum frontend_resource {
  ANALOG_TV_TUNER,
  DIGITAL_TV_TUNER,
  FM_TUNER,
  ANALOG_DEMOD,
  DIGITAL_DEMOD,
 };

 And add a new callback at struct dvb_frontend_ops():

  int (*set_resource)(struct dvb_frontend* fe, enum
 frontend_resource, bool reserve);

 Those callbacks may replace i2c_gate_ctrl().

 With those changes, when a driver needs to access, for example, a
 tuner at a dvb part of the driver, it would do:

 fe-ops.set_resource(fe, DIGITAL_TV_TUNER, true);
 /* All i2c transactions and other operations needed at tuner */
 fe-ops.set_resource(fe, DIGITAL_TV_TUNER, false);

 In other words, it will basically replace the current occurrences of
 i2c_gate_ctrl(), providing a clearer indication that the I2C change
 needed are to enable the access to the tuner.

 The fun begins if other parts of the driver try to do different
 things on resources that may be shared. They can now say that they
 want to access the demod with:

 fe-ops.set_resource(fe, DIGITAL_DEMOD, true);

 So, demods operations will be protected by:

 fe-ops.set_resource(fe, DIGITAL_DEMOD, true);
  /* All i2c transactions and other operations applied on demod
 */ fe-ops.set_resource(fe, DIGITAL_DEMOD, false);

 It is up to driver callback to handle this call. If both
 DIGITAL_DEMOD and DIGITAL_TV_TUNER are at the same i2c bus (e.g.
 there's no i2c gate), and if there's no risk for one I2C access to
 affect the other, the callback can just return 0. Otherwise, it may
 return -EBUSY and let the caller wait for the resource to be freed
 with: wake_up(fe-ops.set_resource(fe, DIGITAL_DEMOD, true) == 0); or
  wake_up_interruptible(fe-ops.set_resource(fe, DIGITAL_DEMOD,
 true) == 0);

 This way, when the resource is freed, the digital demod logic may
 happen.

 Comments?
 
 What about hardware encoders? May be need switch between some TV and encoders.
 Switch input source, output bus and other.

Yeah, we may need to add encoders here, and other stuff like IR and CA modules.

an approach like that is easy to extend, as new issues that may require
resource reservation is added. 

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


Re: dm1105 scan but won't tune? [PROGRESS]

2010-10-06 Thread Simon Baxter

OK, progress (idiot error?)

My problem was OptusB1 requires a 45 degree skew on the LNB on the dish 
itself.


So now I can do an szap as follows:
TV3:12456:h:0:22500:512:650:1920

./szap -l 11300 -c channels-conf/dvb-s/OptusD1E160 TV3
reading channels from file 'channels-conf/dvb-s/OptusD1E160'
zapping to 1 'TV3':
sat 0, frequency = 12456 MHz H, symbolrate 2250, vpid = 0x0200, apid = 
0x028a sid = 0x0780

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 1f | signal cd82 | snr be5c | ber ff00 | unc fffe | 
FE_HAS_LOCK
status 1f | signal cd07 | snr be9e | ber  | unc fffe | 
FE_HAS_LOCK
status 1f | signal cd07 | snr be4a | ber  | unc fffe | 
FE_HAS_LOCK



New problem though - I can now no longer scan with the LNB skewed!!
S 12456000 V 2250 AUTO
S 12456000 H 2250 AUTO

./scan dvb-s/OptusB1-NZ -l 11300
scanning dvb-s/OptusB1-NZ
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 12456000 V 2250 9
initial transponder 12456000 H 2250 9

tune to: 12456:v:0:22500

DVB-S IF freq is 1156000
WARNING:  tuning failed!!!

tune to: 12456:v:0:22500 (tuning failed)

DVB-S IF freq is 1156000
WARNING:  tuning failed!!!

tune to: 12456:h:0:22500

DVB-S IF freq is 1156000
WARNING:  tuning failed!!!

tune to: 12456:h:0:22500 (tuning failed)

DVB-S IF freq is 1156000
WARNING:  tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.

Any ideas?
- Original Message - 
From: Simon Baxter linu...@nzbaxters.com

To: linux-media@vger.kernel.org
Sent: Sunday, September 26, 2010 9:48 AM
Subject: dm1105 scan but won't tune? (anyone have one of these working?)



Simon Baxter ÐÐÑÐÑ:
Hi. I've got a new dm1105 dvb-s card which I can't get to work. I can
scan and get transponders etc, but can't tune or get a front end lock.



I see there's been some work on this - does anyone have one of these
dvb-s cards working?



I've just pulled the latest from
http://mercurial.intuxication.org/hg/s2-liplianin



I can scan and get info:
./scan dvb-s/OptusB1-NZ -l 11300 -x 0
scanning dvb-s/OptusB1-NZ
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 12456000 H 2250 9

tune to: 12456:h:0:22500

DVB-S IF freq is 1156000
snip
0x 0x0781: pmt_pid 0x010b TV Works -- C4 (running)
snip
C4:12456:h:0:22500:513:651:1921



But I can't get a lock on szap:
./szap -c channels-conf/dvb-s/OptusD1E160 C4
reading channels from file 'channels-conf/dvb-s/OptusD1E160'
zapping to 2 'C4':
sat 0, frequency = 12456 MHz H, symbolrate 2250, vpid = 0x0201,
apid = 0x028b sid = 0x0781
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 03 | signal 9ae2 | snr 7170 | ber ff07 | unc fffe |
status 03 | signal 9c2a | snr 719a | ber ff05 | unc fffe |
status 03 | signal 9b07 | snr 71d9 | ber ff05 | unc fffe |
status 03 | signal 9ace | snr 7200 | ber ff05 | unc fffe |



Or in VDR -
Sep 23 13:49:45 localhost vdr: [2105] frontend 0/0 timed out while
tuning to channel 1, tp 112456
Sep 23 13:50:06 localhost vdr: [2105] frontend 0/0 timed out while
tuning to channel 16, tp 112483
Sep 23 13:50:26 localhost vdr: [2105] frontend 0/0 timed out while
tuning to channel 1, tp 112456




Although dvbtune says:
./dvbtune -f 1245600 -s 22500 -p h -m -tone 0 -x
Using DVB card ST STV0299 DVB-S
tuning DVB-S to L-Band:3, Pol:H Srate=2250, 22kHz=off
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Event: Frequency: 10995803
SymbolRate: 2250
FEC_inner: 3



Bit error rate: 65285
Signal strength: 53063
SNR: 48522
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
?xml version=1.0 encoding=iso-8859-1?
satellite
descriptor tag=0x01
data=4b59204469676974616c20536174656c6c697465205456f3ae000100a9f042413303eb0103ed0103f10103f401040201041101043801043d01044501044c02046002046102046202232983238d8a23f18426ad
text=KY.Digital.Satellite.TV...BA3...8.E..L.a..b
/
Nothing to read from fd_nit
Scanning 12407000V 3000
Using DVB card ST STV0299 DVB-S
tuning DVB-S to L-Band:774218352, Pol:V Srate=3000, 22kHz=off
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
polling
polling




Any suggestions?



___
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-me...@xxx
linux-...@xxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


Hi,

Please, try set parameter card=number at dm1105 module loading.

Best reagrds,
Vladimir Monchenko.


I've tried:
modprobe dm1105 card=1
modprobe dm1105 card=2
modprobe dm1105 card=3
modprobe dm1105 card=4
modprobe 

[PATCH 2/3] V4L/DVB: saa7134-input can't be a module right now

2010-10-06 Thread Mauro Carvalho Chehab
There are some symbols at saa7134-input that are used on saa7134
and vice-versa. Due to that, module install fails.

So, partially revert commit 9f495cf7d691c99bf7bdcec9f35fcfdad2cf9ae9.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/saa7134/Kconfig 
b/drivers/media/video/saa7134/Kconfig
index 892b0b1..3fe71be 100644
--- a/drivers/media/video/saa7134/Kconfig
+++ b/drivers/media/video/saa7134/Kconfig
@@ -25,15 +25,12 @@ config VIDEO_SAA7134_ALSA
  module will be called saa7134-alsa.
 
 config VIDEO_SAA7134_RC
-   tristate Philips SAA7134 Remote Controller support
+   bool Philips SAA7134 Remote Controller support
depends on VIDEO_IR
depends on VIDEO_SAA7134
default y
---help---
- Enables Remote Controller support for saa7134.
-
- To compile this driver as a module, choose M here: the
- module will be called saa7134-rc.
+ Enables Remote Controller support on saa7134 driver.
 
 config VIDEO_SAA7134_DVB
tristate DVB/ATSC Support for saa7134 based TV cards
diff --git a/drivers/media/video/saa7134/Makefile 
b/drivers/media/video/saa7134/Makefile
index 5624468..2a2047b 100644
--- a/drivers/media/video/saa7134/Makefile
+++ b/drivers/media/video/saa7134/Makefile
@@ -1,9 +1,8 @@
 
-saa7134-objs :=saa7134-cards.o saa7134-core.o saa7134-i2c.o\
-   saa7134-ts.o saa7134-tvaudio.o saa7134-vbi.o\
-   saa7134-video.o
-
-saa7134-rc-objs := saa7134-input.o
+saa7134-y :=   saa7134-cards.o saa7134-core.o saa7134-i2c.o
+saa7134-y +=   saa7134-ts.o saa7134-tvaudio.o saa7134-vbi.o
+saa7134-y +=   saa7134-video.o
+saa7134-$(CONFIG_VIDEO_SAA7134_RC) += saa7134-rc.o
 
 obj-$(CONFIG_VIDEO_SAA7134) +=  saa6752hs.o saa7134.o saa7134-empress.o
 
@@ -11,8 +10,6 @@ obj-$(CONFIG_VIDEO_SAA7134_ALSA) += saa7134-alsa.o
 
 obj-$(CONFIG_VIDEO_SAA7134_DVB) += saa7134-dvb.o
 
-obj-$(CONFIG_VIDEO_SAA7134_RC) += saa7134-rc.o
-
 EXTRA_CFLAGS += -Idrivers/media/video
 EXTRA_CFLAGS += -Idrivers/media/common/tuners
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
diff --git a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
index a6ac462..3a0ea56 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -28,7 +28,7 @@
 #include saa7134-reg.h
 #include saa7134.h
 
-#define MODULE_NAME saa7134-rc
+#define MODULE_NAME saa7134
 
 static unsigned int disable_ir;
 module_param(disable_ir, int, 0444);
@@ -1211,6 +1211,3 @@ static int saa7134_nec_irq(struct saa7134_dev *dev)
 
return 1;
 }
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
diff --git a/drivers/media/video/saa7134/saa7134.h 
b/drivers/media/video/saa7134/saa7134.h
index 99f122b..d3b6a19 100644
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -810,7 +810,7 @@ void saa7134_irq_oss_done(struct saa7134_dev *dev, unsigned 
long status);
 /* --- */
 /* saa7134-input.c */
 
-#if defined(CONFIG_VIDEO_SAA7134_RC) || 
(defined(CONFIG_VIDEO_SAA7134_RC_MODULE)  defined(MODULE))
+#if defined(CONFIG_VIDEO_SAA7134_RC)
 int  saa7134_input_init1(struct saa7134_dev *dev);
 void saa7134_input_fini(struct saa7134_dev *dev);
 void saa7134_input_irq(struct saa7134_dev *dev);
-- 
1.7.1


--
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/3] V4L/DVB: tm6000: Fix warnings due to a small array size

2010-10-06 Thread Mauro Carvalho Chehab
drivers/staging/tm6000/tm6000-stds.c:101: warning: excess elements in array 
initializer
drivers/staging/tm6000/tm6000-stds.c:101: warning: (near initialization for 
‘tv_stds[0].common’)
drivers/staging/tm6000/tm6000-stds.c:160: warning: excess elements in array 
initializer
drivers/staging/tm6000/tm6000-stds.c:160: warning: (near initialization for 
‘tv_stds[1].common’)
drivers/staging/tm6000/tm6000-stds.c:219: warning: excess elements in array 
initializer
drivers/staging/tm6000/tm6000-stds.c:219: warning: (near initialization for 
‘tv_stds[2].common’)
drivers/staging/tm6000/tm6000-stds.c:336: warning: excess elements in array 
initializer
drivers/staging/tm6000/tm6000-stds.c:336: warning: (near initialization for 
‘tv_stds[4].common’)

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/staging/tm6000/tm6000-stds.c 
b/drivers/staging/tm6000/tm6000-stds.c
index f6aa753..fe22f42 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -32,7 +32,7 @@ struct tm6000_std_tv_settings {
v4l2_std_id id;
struct tm6000_reg_settings sif[12];
struct tm6000_reg_settings nosif[12];
-   struct tm6000_reg_settings common[25];
+   struct tm6000_reg_settings common[26];
 };
 
 struct tm6000_std_settings {
-- 
1.7.1

--
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/3] V4L/DVB: videobuf-dma-sg: Fix a warning due to the usage of min(PAGE_SIZE, arg)

2010-10-06 Thread Mauro Carvalho Chehab
drivers/media/video/videobuf-dma-sg.c: In function ‘videobuf_pages_to_sg’:
drivers/media/video/videobuf-dma-sg.c:119: warning: comparison of distinct 
pointer types lacks a cast
drivers/media/video/videobuf-dma-sg.c:120: warning: comparison of distinct 
pointer types lacks a cast

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/videobuf-dma-sg.c 
b/drivers/media/video/videobuf-dma-sg.c
index 359f2f3..7153e44 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -116,8 +116,8 @@ static struct scatterlist *videobuf_pages_to_sg(struct page 
**pages,
goto nopage;
if (PageHighMem(pages[i]))
goto highmem;
-   sg_set_page(sglist[i], pages[i], min(PAGE_SIZE, size), 0);
-   size -= min(PAGE_SIZE, size);
+   sg_set_page(sglist[i], pages[i], min((unsigned)PAGE_SIZE, 
size), 0);
+   size -= min((unsigned)PAGE_SIZE, size);
}
return sglist;
 
-- 
1.7.1


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


[RFC PATCH] Audio standards on tm6000

2010-10-06 Thread Mauro Carvalho Chehab
Hi Dmitri,

IMO, the better is to remove the audio init from tm6000-core and add a separate
per-standard set of tables.

I'm enclosing the patch for it. Please check if this won't break for your 
device.

On all tests I did here with a tm6010 device (HVR 900H), I was only able to 
listen to
white noise.

I'm suspecting that this device uses XC3028 MTS mode (e. g. uses xc3028 to 
decode audio,
and just inputs the audio stream from some line IN. As the driver is not able 
yet to
handle an audio mux, this may explain why I'm not able to receive any audio at 
all.

Maybe tm5600 devices may also require (or use) line input entries, instead of 
I2S.

Could you please check those issues?

PS.: the PAL/M hunk will probably fail, as I likely applied some patches before
this one, in order to try to fix it. It should be trivial to solve the 
conflicts.

---

tm6000: Implement audio standard tables

Implement separate tables for audio standards, associating them with the
video standards.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 57cb69e..9cb2901 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -200,6 +200,10 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
val = ~0x40;
tm6000_set_reg(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE, val);
 
+   tm6000_set_reg(dev, TM6010_REQ08_RF1_AADC_POWER_DOWN, 0xfc);
+
+#if 0  /* FIXME: VBI is standard-dependent */
+
/* Init teletext */
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
tm6000_set_reg(dev, TM6010_REQ07_R41_TELETEXT_VBI_CODE1, 0x27);
@@ -249,44 +253,7 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
tm6000_set_reg(dev, TM6010_REQ07_R5B_VBI_TELETEXT_DTO0, 0x4c);
tm6000_set_reg(dev, TM6010_REQ07_R40_TELETEXT_VBI_CODE0, 0x01);
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x00);
-
-
-   /* Init audio */
-   tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
-   tm6000_set_reg(dev, TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R04_A_SIF_AMP_CTRL, 0xa0);
-   tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD, 0x06);
-   tm6000_set_reg(dev, TM6010_REQ08_R07_A_LEFT_VOL, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R08_A_RIGHT_VOL, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL, 0x08);
-   tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, 0x91);
-   tm6000_set_reg(dev, TM6010_REQ08_R0B_A_ASD_THRES1, 0x20);
-   tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2, 0x12);
-   tm6000_set_reg(dev, TM6010_REQ08_R0D_A_AMD_THRES, 0x20);
-   tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1, 0xf0);
-   tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2, 0x80);
-   tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1, 0xc0);
-   tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2, 0x80);
-   tm6000_set_reg(dev, TM6010_REQ08_R12_A_AGC_U, 0x12);
-   tm6000_set_reg(dev, TM6010_REQ08_R13_A_AGC_ERR_T, 0xfe);
-   tm6000_set_reg(dev, TM6010_REQ08_R14_A_AGC_GAIN_INIT, 0x20);
-   tm6000_set_reg(dev, TM6010_REQ08_R15_A_AGC_STEP_THR, 0x14);
-   tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX, 0xfe);
-   tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN, 0x01);
-   tm6000_set_reg(dev, TM6010_REQ08_R18_A_TR_CTRL, 0xa0);
-   tm6000_set_reg(dev, TM6010_REQ08_R19_A_FH_2FH_GAIN, 0x32);
-   tm6000_set_reg(dev, TM6010_REQ08_R1A_A_NICAM_SER_MAX, 0x64);
-   tm6000_set_reg(dev, TM6010_REQ08_R1B_A_NICAM_SER_MIN, 0x20);
-   tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1c, 0x00);
-   tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1d, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R1E_A_GAIN_DEEMPH_OUT, 0x13);
-   tm6000_set_reg(dev, TM6010_REQ08_R1F_A_TEST_INTF_SEL, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R20_A_TEST_PIN_SEL, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_RE4_ADC_IN2_SEL, 0xf3);
-   tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD, 0x00);
-   tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
-
+#endif
} else {
/* Enables soft reset */
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
@@ -360,7 +327,6 @@ int tm6000_init_digital_mode(struct tm6000_core *dev)
tm6000_set_reg(dev, TM6010_REQ07_RFE_POWER_DOWN, 0x28);
tm6000_set_reg(dev, TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xfc);