From owner-freebsd-arm@FreeBSD.ORG Tue Jul 14 08:31:12 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968BE1065674; Tue, 14 Jul 2009 08:31:12 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 44E208FC1A; Tue, 14 Jul 2009 08:31:12 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7F009C3A96; Tue, 14 Jul 2009 10:28:06 +0200 (CEST) From: Piotr =?iso-8859-2?q?Zi=EAcik?= Organization: Semihalf To: Hans Petter Selasky Date: Tue, 14 Jul 2009 10:31:10 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200907091721.01272.kosmo@semihalf.com> <200907091834.42462.hselasky@c2i.net> In-Reply-To: <200907091834.42462.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907141031.11185.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, thompsa@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 08:31:13 -0000 > > 1) My analysis: Only the data areas are being flushed/invalidated. No > transfer descriptors are flushed/invalidated. I see no cache operations > happening on any DMA control structures, even though there are calls from > EHCI to xxx_pc_flush() and xxx_pc_invalidate(). > This is 100% correct if control structures are marked as BUS_DMA_COHERENT. > One patch you can try is to add an additional unload call to > "usbd_transfer_setup_sub_malloc()": > > ==== //depot/projects/usb/src/sys/dev/usb/usb_transfer.c#159 - > /home/hans_other/usb.p4/src/sys/dev/usb/usb_transfer.c ==== > @@ -268,6 +268,10 @@ > pg, z, align)) { > return (1); /* failure */ > } > + > + bus_dmamap_unload(parm->dma_page_cache_ptr->tag, > + parm->dma_page_cache_ptr->map); > + > /* Set beginning of current buffer */ > buf = parm->dma_page_cache_ptr->buffer; > /* Make room for one DMA page cache and one page */ > > This will avoid the same memory area being loaded twice. Not sure if there > is still a bug in pmap about this! I checked this patch and I did not saw any changes in USB behaviour. The problem sill was visible. > > Could you provide a new trace, showing an enumeration failure. In your > previous trace there was no error, because the printouts probably caused to > CPU to flush out its cache. > I have tried many times and I was unable to generate trace showing enumeration faliure. Even little amount of debugging code caused proper enumeration. However access to attached device (pendrive) was not possible - SCSI layer reported errors. Probaby you see more on your AT91 device as you know USB stack internals. Have you tried to bring up OHCI on you ARM board ? -- Best Regards, Piotr Ziecik