From patchwork Wed Sep 9 22:11:39 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Blanford X-Patchwork-Id: 46478 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n89MHVGC013908 for ; Wed, 9 Sep 2009 22:17:31 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753403AbZIIWR1 (ORCPT ); Wed, 9 Sep 2009 18:17:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752175AbZIIWR1 (ORCPT ); Wed, 9 Sep 2009 18:17:27 -0400 Received: from mail-qy0-f192.google.com ([209.85.221.192]:43640 "EHLO mail-qy0-f192.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbZIIWR1 (ORCPT ); Wed, 9 Sep 2009 18:17:27 -0400 Received: by qyk30 with SMTP id 30so4052109qyk.5 for ; Wed, 09 Sep 2009 15:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=0X4nzqpyqa70KMLTDFV2NKZOdovVwK99rBooCp5pIgY=; b=I7lxOv0HahvEoAyvU7tB/8gIIF6ybOZ9yZ74GbRnqaA3sO3+94V87LD1BwFlA/KH03 UcmypvkiAzUESF9hwFJnxggyzVCcjFW2XE4LNxJfXEdd7O446cpouDEESbpME2r+m4yy WKqsCmHJMAqB88RHI/prWMbIAS5iMrpidHH8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=H5N2KalKznzNGsR3SrZosyE0tWRLNyyOh4ejUm68B3Vr4eCgANuzd58lwKBwDFBsE+ v1CfzYcjjC+u5gWOYj7gkpYCG2/iWIIvjrX33Sm2pN+uYhZZzFchEMK6vSzu6IvSkwup lvxuQDySs1v0Q59ukJaYqprRcVyT0r4XRIPME= Received: by 10.224.7.16 with SMTP id b16mr140734qab.94.1252534301356; Wed, 09 Sep 2009 15:11:41 -0700 (PDT) Received: from blackbart.localnet.prv (adsl-99-19-46-38.dsl.klmzmi.sbcglobal.net [99.19.46.38]) by mx.google.com with ESMTPS id 7sm80468qwf.47.2009.09.09.15.11.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Sep 2009 15:11:40 -0700 (PDT) Date: Wed, 9 Sep 2009 18:11:39 -0400 From: James Blanford To: linux-media@vger.kernel.org Subject: gspca stv06xx performance regression - request for testing Message-ID: <20090909181139.06ab4ed5@blackbart.localnet.prv> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.16.5; i486-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Howdy folks, Now that I have my old quickcam express working, I can confirm that the frame rate is half what it was with the old out-of-tree driver. The gspca driver is throwing out every other frame. When a frame is completed, a new frame is started with a new frame buffer that passes the test for being properly queued. But after the first packet is analysed by the subdriver, the exact same test fails and the entire frame is marked for discard. I'm not having any luck tracking the problem down. I would like to find out if it's just my sensor, my subdriver or the entire gspca family. I have some printks that can be added to gspca.c that easily and quickly illustrate the problem. When I test, I get: Sep 8 10:27:48 blackbart kernel: Frame alloc Sep 8 10:27:48 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame completed Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame marked for discard Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame completed Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame marked for discard Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame completed Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame marked for discard Sep 8 10:27:49 blackbart kernel: New frame - first packet Sep 8 10:27:49 blackbart kernel: Frame completed Of course, I shouldn't be getting every other frame marked for discard. Note that this marking takes place when the first packet comes across, _before_ any image data is passed. I'm hoping someone has a few minutes to make a little patch, run the cam for a couple seconds and look at the debug log. Any comments are welcome as well. Thanks, - Jim --- gspca.c.orig 2009-09-04 00:58:26.000000000 -0400 +++ gspca.c 2009-09-09 16:27:10.000000000 -0400 @@ -268,9 +268,11 @@ /* when start of a new frame, if the current frame buffer * is not queued, discard the whole frame */ if (packet_type == FIRST_PACKET) { + printk(KERN_DEBUG "New frame - first packet\n"); if ((frame->v4l2_buf.flags & BUF_ALL_FLAGS) != V4L2_BUF_FLAG_QUEUED) { gspca_dev->last_packet_type = DISCARD_PACKET; + printk(KERN_DEBUG "Frame marked for discard\n"); return frame; } frame->data_end = frame->data; @@ -306,6 +308,7 @@ wake_up_interruptible(&gspca_dev->wq); /* event = new frame */ i = (gspca_dev->fr_i + 1) % gspca_dev->nframes; gspca_dev->fr_i = i; + printk(KERN_DEBUG "Frame completed\n"); PDEBUG(D_FRAM, "frame complete len:%d q:%d i:%d o:%d", frame->v4l2_buf.bytesused, gspca_dev->fr_q, @@ -396,6 +399,7 @@ } gspca_dev->fr_i = gspca_dev->fr_o = gspca_dev->fr_q = 0; gspca_dev->last_packet_type = DISCARD_PACKET; + printk(KERN_DEBUG "Frame alloc\n"); gspca_dev->sequence = 0; return 0; }