From owner-freebsd-current@FreeBSD.ORG Tue Jan 10 21:27:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0351065672 for ; Tue, 10 Jan 2012 21:27:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id C216D8FC19 for ; Tue, 10 Jan 2012 21:27:56 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Kwyl1i0081u4NiLA8xTwh6; Tue, 10 Jan 2012 21:27:56 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id KxTv1i00L4NgCEG8hxTvyw; Tue, 10 Jan 2012 21:27:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0ALRr0B026784; Tue, 10 Jan 2012 14:27:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Andriy Gapon In-Reply-To: <4F0CAA54.7060005@FreeBSD.org> References: <4F0C9D14.60705@FreeBSD.org> <1326228825.2419.22.camel@revolution.hippie.lan> <4F0CAA54.7060005@FreeBSD.org> Content-Type: text/plain Date: Tue, 10 Jan 2012 14:27:53 -0700 Message-Id: <1326230873.2419.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: bus dma: a flag/quirk for page zero X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:27:57 -0000 On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote: > on 10/01/2012 22:53 Ian Lepore said the following: > > On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote: > >> > >> Some hardware interfaces may reserve a special meaning for a (physical) memory > >> address value of zero. One example is the OHCI specification where a zero value > >> in CurrentBufferPointer doesn't mean a physical address, but has a reserved > >> meaning. To be honest I don't have another example :) but don't preclude its > >> existence. > >> > >> To deal with this peculiarity we could use a special flag/quirk that would > >> instruct the bus dma code to never use the page zero for communication with the > >> hardware. > >> Here's a proof of concept patch that implements the idea: > >> http://people.freebsd.org/~avg/usb-dma-pagezero.diff > >> > >> Some concerns: > >> - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag > >> - the patch implements the flag only for x86 at the moment > >> - usb code uses the flag regardless of the actual controller type > >> > >> What do you think? > > > > I think another way to handle this, one that doesn't require modifying > > the busdma_machdep implementation for every architecture, would be for > > usb_dma_tag_create() to set lowaddr to zero and provide a filter func > > that filters based on both the value zero and the expression currently > > being passed as lowaddr. At least, I think that's how the filterfunc > > stuff is supposed to work, I've never actually coded a busdma filter. > > This has still some problems: > - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not > inclusive, as such there is no way to filter page zero > - a bounce page could still be at the physical address zero > - and overriding the above, even worse, bounce pages are allocated in the range > below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages Wow, I didn't realize. That almost reads like a list of bugs in the current busdma design. It seems especially wrong to assume that no hardware in the world now or ever would have its range of DMA-able addresses in the middle of its physical address space. I'll throw one more idea out, (because it just popped into my head, not because I think it's the best possible idea)... Could the problems you list be circumvented (for this situation and maybe others) with a new flag BUS_DMA_ALWAYS_FILTER that makes the filter function run regardless of the low/high addr values? That would add the flexibility to handle any arbitary kinds of ranges no matter what hardware or strange requirements come along. -- Ian