From owner-freebsd-current@FreeBSD.ORG Wed Jan 11 15:14:04 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 B2E47106566B; Wed, 11 Jan 2012 15:14:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFAD8FC16; Wed, 11 Jan 2012 15:14:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2E55E46B55; Wed, 11 Jan 2012 10:14:04 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B2A47B922; Wed, 11 Jan 2012 10:14:03 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 11 Jan 2012 10:01:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F0C9D14.60705@FreeBSD.org> In-Reply-To: <4F0C9D14.60705@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201111001.04724.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 11 Jan 2012 10:14:03 -0500 (EST) Cc: Andriy Gapon 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: Wed, 11 Jan 2012 15:14:04 -0000 On Tuesday, January 10, 2012 3:18:28 pm 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 this is fine, but you should just always exclude page zero when allocating bounce pages. Bounce pages are assigned to zones that can be shared by multiple tags, so other tags that map to the same zone can alloc bounce pages that ohci will use (add_bounce_page() should probably take the bounce zone as an arg instead of a tag). I think it's not worth creating a separate zone just for ohci, but to forbid page zero from all zones instead. Also, please change this: - if (newtag->lowaddr < ptoa((vm_paddr_t)Maxmem) - || newtag->alignment > 1) + if (newtag->lowaddr < ptoa((vm_paddr_t)Maxmem) || + newtag->alignment > 1) + newtag->flags |= BUS_DMA_COULD_BOUNCE; + + if ((newtag->flags & BUS_DMA_NO_PAGEZERO) != 0) newtag->flags |= BUS_DMA_COULD_BOUNCE; To just be one if. -- John Baldwin