From owner-freebsd-mips@FreeBSD.ORG Fri Aug 24 00:51:31 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA37D106566C for ; Fri, 24 Aug 2012 00:51:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 821618FC1C for ; Fri, 24 Aug 2012 00:51:31 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id qEbq1j00V0FhH24A1QrXVz; Fri, 24 Aug 2012 00:51:31 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id qQrV1j00l4NgCEG8UQrWx7; Fri, 24 Aug 2012 00:51:30 +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 q7O0pSKT025681; Thu, 23 Aug 2012 18:51:28 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 18:51:28 -0600 Message-ID: <1345769488.27688.625.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:51:32 -0000 On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote: > On 23 August 2012 16:45, Ian Lepore wrote: > > > So do you think it's safe to assume that any given dma tag that has an > > alignment constraint also implicitly has a buffer size constraint that > > the size must be a multiple of the alignment? > > > > What if we have a platform with a 32-byte cacheline / DMA granularity, > > and then we have a builtin device on that SoC which can only do DMA on a > > 64K alignment (which its tag would reflect), but the hardware can move > > as little as 1 byte at a time? Children of that bridge device come > > along and allocate little 16-byte buffers that eat 16 pages each. It > > doesn't seem all that far-fetched to me. > > That hardware would suck, wouldn't it? > Thinking about this some more, I think that at least for now we don't have to communicate a new constraint to bus_dma_tag_create(), nor do we need to assume that a size constraint is the same as an alignment constraint. The size constraint is machine dependant in nature, and the busdma implementation code is also MD, and thus should have some MD way of knowing about this constraint for itself without being told by callers. -- Ian