From owner-p4-projects@FreeBSD.ORG Sun Nov 16 12:12:12 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 763531065691; Sun, 16 Nov 2008 12:12:12 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38959106568A; Sun, 16 Nov 2008 12:12:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFF28FC18; Sun, 16 Nov 2008 12:12:11 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Oumcy1zCVZoA:10 a=89sYFII7q9YA:10 a=aniA1o7mVp4QawOfT9qHqA==:17 a=zuRaRlhO4Nr5gQTiq5IA:9 a=rKwk3yYKU2zWmFdr3AcA:7 a=0fWqXSj3WHROwVBhGyQ7Rw-DIDQA:4 a=LY0hPdMaydYA:10 Received: from [62.113.133.1] (account mc467741@c2i.net [62.113.133.1] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1149969296; Sun, 16 Nov 2008 13:12:07 +0100 From: Hans Petter Selasky To: Alexander Motin Date: Sun, 16 Nov 2008 13:14:13 +0100 User-Agent: KMail/1.9.7 References: <200811080910.mA89AgTZ048172@repoman.freebsd.org> <200811141644.55773.hselasky@c2i.net> <491DC170.7090409@FreeBSD.org> In-Reply-To: <491DC170.7090409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811161314.13923.hselasky@c2i.net> Cc: Perforce Change Reviews Subject: Re: PERFORCE change 152649 for review - busdma problem X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 12:12:12 -0000 On Friday 14 November 2008, Alexander Motin wrote: > Hans Petter Selasky wrote: > > The thing is, you cannot specify how many bytes are on the first page > > which can take a full physical address. It is assumed that after the page > > offset wraps to zero a new page begins. > > > > Example: > > > > xxx: means data > > > > Virtual memory: > > PG0 PG1 > > > > | xxx|xxx | > > > > In busdma bounce buffer: > > > > PG0 PG1 > > > > |xxx |xxx | > > > > You see there is a hole just before PG1, and it is impossible to tell the > > USB hardware to skip this hole. > > I have seen very alike organization at SD host controller. There is SDMA > mode, to which most existing controllers limited. There is just initial > address and total data size can be specified. But on every page boundary > controller stops transfer and allows software to load the address of the > next data page. This technique is ugly and new specification provides > new ADMA and ADMA2 modes which allow start address and length to be > specified for every data segment. > > Now within my sdhci driver I have implemented page bouncing by myself, I > am preallocating one aligned 4K page and reloading it with new data on > each page boundary hit. There are many different data alignment > bugs/limitations in that controllers, so such unperfect DMA operation > also allows me to manage most of them. Linux sdhci driver instead just > don't use this page boundary interrupt, operating with only one > continuous memory block, completely disabling DMA on buggy controllers. > > If I understand correctly present busdma API (may be not), it does not > allow you to be sure that both of segment boundaries will be aligned to > the page boundaries. You are only specifying maximum number of segments > and maximum segment size, so busdma, if it wish, may theoretically give > you several small segments instead of single complete page. So if you > are not ready to receive uneven sized segments, you probably should not > specify that you want to receive more then 1 segment. Hi, Isn't the smallest segment size "PAGE_SIZE" bytes? That is what USB is using. Maybe I can make an exception for that case? maxsegsz=PAGE_SIZE, align=1? > > May be it would be good to add some flag to the bus_dma_tag_create() > which would signaled that hardware is able to handle segment boundaries > only at page boundaries. It would also allow us to properly combine > alignment and page boundary requirements. But it is surely not easy task. > Yes. I'm going to work on this today. I'm not sure what the best approach is, but a flag is probably the best, else you don't know if busdma has been patched for this or not. --HPS