Re: [PATCH/RFC v3 01/11] v4l: Move the media/v4l2-mediabus.h header to include/linux
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
-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
-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
-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
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
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
-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
-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.
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
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.
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
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/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
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
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
-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!!!
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.
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
-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
-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
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
-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.
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
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.
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
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!!!
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.
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
| - 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!!!
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!!!
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]
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
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
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
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
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]
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
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
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)
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
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);