From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 20:32:22 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C92B1519 for ; Thu, 31 Jan 2013 20:32:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id F068AF9C for ; Thu, 31 Jan 2013 20:32:21 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0VKWKhG013710 for ; Thu, 31 Jan 2013 13:32:20 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r0VKWIRi025306; Thu, 31 Jan 2013 13:32:18 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: bud_dmamap_load_buffer() From: Ian Lepore To: Olivier Houchard In-Reply-To: <20130131201623.GA58163@ci0.org> References: <20130131192426.GL2522@kib.kiev.ua> <20130131201623.GA58163@ci0.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 13:32:17 -0700 Message-ID: <1359664337.93359.337.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:32:22 -0000 On Thu, 2013-01-31 at 21:16 +0100, Olivier Houchard wrote: > On Thu, Jan 31, 2013 at 09:24:27PM +0200, Konstantin Belousov wrote: > > I noted that arm/busdma_machdep.c uses essentially inlined pmap_kextract() > > to get the physical address from the kernel address. I consulted with > > gonzo, who said that he does not see a reason for inlining the code. > > > > My theory is that before r240983, pmap_kextract() locked the pmap, which > > caused unneeded and probably wrong locking in the busdma load path. Since > > this issue is fixed, I see no reason for directly walking the page tables. > > > > Could somebody please review and test the patch ? v6 busdma already uses > > pmap_kextract(). > > > > Do not remove me from Cc:. > > Hi Konstantin, > > It's that way for historical reasons. It used to check the caching attributes > of the page, as well as its physical address, to try hard to avoid doing > unnecessery cache flush if the page is already mapped as uncache. Now that > code is long gone, and there's no reason anymore not to just use > pmap_kextract(). Your patch looks fine to me. > > Regards, > > Olivier That would help explain that XXX comment about checking coherent mappings in user maps that never made much sense to me. I think we should delete the comment now as well. I've applied and tested the patch, it's working fine. -- Ian