From owner-freebsd-usb@FreeBSD.ORG Thu Aug 8 13:09:49 2013 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7EF9A749 for ; Thu, 8 Aug 2013 13:09:49 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from defer104.ocn.ad.jp (defer104.ocn.ad.jp [122.28.15.168]) by mx1.freebsd.org (Postfix) with ESMTP id 308B72114 for ; Thu, 8 Aug 2013 13:09:48 +0000 (UTC) Received: from msgw001-04.ocn.ad.jp (msgw001-04.ocn.ad.jp [180.37.203.73]) by defer104.ocn.ad.jp (Postfix) with ESMTP id 1ED6A479E16 for ; Thu, 8 Aug 2013 22:09:48 +0900 (JST) Received: from localhost (p9131-ipngn100305sizuokaden.shizuoka.ocn.ne.jp [153.182.255.131]) by msgw001-04.ocn.ad.jp (Postfix) with ESMTP id 6712F833E6E; Thu, 8 Aug 2013 22:09:40 +0900 (JST) Date: Thu, 08 Aug 2013 22:09:39 +0900 (JST) Message-Id: <20130808.220939.219630261.toshi@ruby.ocn.ne.jp> To: freebsd-usb@FreeBSD.org Subject: Re: HS isochronous transfer on musb_otg From: SAITOU Toshihide In-Reply-To: <5202502D.20702@bitfrost.no> References: <51FB5230.3000503@bitfrost.no> <20130807.210258.112628314.toshi@ruby.ocn.ne.jp> <5202502D.20702@bitfrost.no> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:09:49 -0000 In message: <5202502D.20702@bitfrost.no> Hans Petter Selasky writes: > On 08/07/13 14:02, SAITOU Toshihide wrote: >> In message: <51FB5230.3000503@bitfrost.no> >> Hans Petter Selasky writes: >>> On 08/01/13 16:07, SAITOU Toshihide wrote: >>>> My UVC cam is not working with the musb_otg driver and >>>> libusb(3) on the BeagleBone Black. >>>> >>> >>> Hi, >>> >>> It might be that the packet multiplier is not set >>> correctly. Try to figure out which register this is, and >>> simply set the bits correctly. >>> >>> Thank you! >>> >>> --HPS >>> >>>> With the following changes to the musb_otg.c, it feels like >>>> the transaction is performed as expected but the data >>>> doesn't pass to the libusb_transfer's buffer. Does anyone >>>> know what is wrong? >> >> >> Thank you for your information, but still I don't understand >> what is the packet multiplier. Fortunately, there is a >> progress. >> >> With the patch at the end, the data from the UVC camera is >> arrived into the libusb_transfer's buffer. Now the problem >> is >> that the data of each transaction is scattered into the >> buffer >> of the packet. >> >> (now) >> >> | packet size | packet size | packet size | packet size | >> | DATA0 | DATA1 | DATA2 | DATA0 |... >> >> >> (expected) >> >> | packet size | packet size | packet size | >> | DATA0,1,2 | DATA0,1,2 | DATA0,1,2 |... >> >> >> I think if the length of the packet is set using >> libusb_set_iso_packet_length, all transaction data for the >> packet should be packed into it, at this time, max packet >> size >> is declared in the device descriptor so the device doesn't >> send the packet larger than that. Are these right? If so, >> is >> the musbotg_host_data_rx of musb_otg.c need to modify? >> > > Hi, > > The scattering is a bug in the MUSB driver's handling of > incoming data. It should collect more data before advancing > to the next frame! > > See: > > mustbotg_host_data_rx() function. I have confirmed the scattering is fixed by modifying the mustbotg_host_data_rx(), althought the modification I have made breaks other transfer type at the moment. Thank you, SAITOU Toshihide