| Message ID | 1376053896-8931-1-git-send-email-oliver@neukum.org (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | Laurent Pinchart |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1V7mTq-0006Ym-5Z; Fri, 09 Aug 2013 15:11:46 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-5) with esmtp id 1V7mTo-0002IS-6p; Fri, 09 Aug 2013 15:11:45 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758083Ab3HINLm (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 9 Aug 2013 09:11:42 -0400 Received: from smtp-out002.kontent.com ([81.88.40.216]:52503 "EHLO smtp-out002.kontent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757990Ab3HINLl (ORCPT <rfc822; linux-media@vger.kernel.org>); Fri, 9 Aug 2013 09:11:41 -0400 Received: from linux-fkkt.site (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: neukum_org@smtp-out002.kontent.com) by smtp-out002.kontent.com (Postfix) with ESMTPSA id 63CED10038098; Fri, 9 Aug 2013 15:11:39 +0200 (CEST) From: oliver@neukum.org To: laurent.pinchart@ideasonboard.com, linux-media@vger.kernel.org Cc: Oliver Neukum <oneukum@suse.de> Subject: [PATCH] uvc: more buffers Date: Fri, 9 Aug 2013 15:11:36 +0200 Message-Id: <1376053896-8931-1-git-send-email-oliver@neukum.org> X-Mailer: git-send-email 1.8.3.1 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.8.9.130332 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_REAL_NAME 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' |
Commit Message
Oliver Neukum
Aug. 9, 2013, 1:11 p.m. UTC
From: Oliver Neukum <oneukum@suse.de> This is necessary to let the new generation of cameras from LiteOn used in Haswell ULT notebook operate. Otherwise the images will be truncated. Signed-off-by: Oliver Neukum <oneukum@suse.de> --- drivers/media/usb/uvc/uvcvideo.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hi Oliver, Thank you for the patch. On Friday 09 August 2013 15:11:36 oliver@neukum.org wrote: > From: Oliver Neukum <oneukum@suse.de> > > This is necessary to let the new generation of cameras from LiteOn used in > Haswell ULT notebook operate. Otherwise the images will be truncated. Could you please post the lsusb -v output for the device ? Why does it need more buffers, is it a superspeed webcam ? > Signed-off-by: Oliver Neukum <oneukum@suse.de> > --- > drivers/media/usb/uvc/uvcvideo.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/uvc/uvcvideo.h > b/drivers/media/usb/uvc/uvcvideo.h index 9e35982..9f1930b 100644 > --- a/drivers/media/usb/uvc/uvcvideo.h > +++ b/drivers/media/usb/uvc/uvcvideo.h > @@ -114,9 +114,9 @@ > /* Number of isochronous URBs. */ > #define UVC_URBS 5 > /* Maximum number of packets per URB. */ > -#define UVC_MAX_PACKETS 32 > +#define UVC_MAX_PACKETS 128 That would mean up to 384KiB per URB. While not unreasonable, I'd like to know how much data your camera produces to require this. > /* Maximum number of video buffers. */ > -#define UVC_MAX_VIDEO_BUFFERS 32 > +#define UVC_MAX_VIDEO_BUFFERS 128 I don't think your camera really needs more than 32 V4L2 (full frame) buffers :-) > /* Maximum status buffer size in bytes of interrupt URB. */ > #define UVC_MAX_STATUS_SIZE 16
On Fri, 2013-08-09 at 15:58 +0200, Laurent Pinchart wrote: Hi, > > This is necessary to let the new generation of cameras from LiteOn used in > > Haswell ULT notebook operate. Otherwise the images will be truncated. > > Could you please post the lsusb -v output for the device ? It is attached. > Why does it need more buffers, is it a superspeed webcam ? No. It is HS. > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > > --- > > drivers/media/usb/uvc/uvcvideo.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/usb/uvc/uvcvideo.h > > b/drivers/media/usb/uvc/uvcvideo.h index 9e35982..9f1930b 100644 > > --- a/drivers/media/usb/uvc/uvcvideo.h > > +++ b/drivers/media/usb/uvc/uvcvideo.h > > @@ -114,9 +114,9 @@ > > /* Number of isochronous URBs. */ > > #define UVC_URBS 5 > > /* Maximum number of packets per URB. */ > > -#define UVC_MAX_PACKETS 32 > > +#define UVC_MAX_PACKETS 128 > > That would mean up to 384KiB per URB. While not unreasonable, I'd like to know > how much data your camera produces to require this. How to determine that? > > /* Maximum number of video buffers. */ > > -#define UVC_MAX_VIDEO_BUFFERS 32 > > +#define UVC_MAX_VIDEO_BUFFERS 128 > > I don't think your camera really needs more than 32 V4L2 (full frame) buffers > :-) Unfortunately, experimental evidence is that it does need them at resolutions above 640x480 Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Oliver, On Monday 12 August 2013 11:01:55 Oliver Neukum wrote: > On Fri, 2013-08-09 at 15:58 +0200, Laurent Pinchart wrote: > > > This is necessary to let the new generation of cameras from LiteOn used > > > in Haswell ULT notebook operate. Otherwise the images will be truncated. > > > > Could you please post the lsusb -v output for the device ? > > It is attached. No it isn't :-) > > Why does it need more buffers, is it a superspeed webcam ? > > No. It is HS. > > > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > > > --- > > > > > > drivers/media/usb/uvc/uvcvideo.h | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/media/usb/uvc/uvcvideo.h > > > b/drivers/media/usb/uvc/uvcvideo.h index 9e35982..9f1930b 100644 > > > --- a/drivers/media/usb/uvc/uvcvideo.h > > > +++ b/drivers/media/usb/uvc/uvcvideo.h > > > @@ -114,9 +114,9 @@ > > > > > > /* Number of isochronous URBs. */ > > > #define UVC_URBS 5 > > > /* Maximum number of packets per URB. */ > > > > > > -#define UVC_MAX_PACKETS 32 > > > +#define UVC_MAX_PACKETS 128 > > > > That would mean up to 384KiB per URB. While not unreasonable, I'd like to > > know how much data your camera produces to require this. > > How to determine that? The UVC descriptors might provide some information. Do you get errors in the kernel log with UVC_MAX_PACKETS set to 32 ? > > > /* Maximum number of video buffers. */ > > > > > > -#define UVC_MAX_VIDEO_BUFFERS 32 > > > +#define UVC_MAX_VIDEO_BUFFERS 128 > > > > I don't think your camera really needs more than 32 V4L2 (full frame) > > buffers :-) > > Unfortunately, experimental evidence is that it does need them at > resolutions above 640x480 Could you please test it again with UVC_MAX_PACKETS set to 128 and UVC_MAX_VIDEO_BUFFERS set to 32 ? UVC_MAX_VIDEO_BUFFERS sets the maximum number of V4L2 full frame buffers, even 32 is probably way too high.
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 9e35982..9f1930b 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -114,9 +114,9 @@ /* Number of isochronous URBs. */ #define UVC_URBS 5 /* Maximum number of packets per URB. */ -#define UVC_MAX_PACKETS 32 +#define UVC_MAX_PACKETS 128 /* Maximum number of video buffers. */ -#define UVC_MAX_VIDEO_BUFFERS 32 +#define UVC_MAX_VIDEO_BUFFERS 128 /* Maximum status buffer size in bytes of interrupt URB. */ #define UVC_MAX_STATUS_SIZE 16