From owner-freebsd-arm@FreeBSD.ORG  Fri Aug 24 04:03:23 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
Delivered-To: freebsd-arm@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CF8551065670
	for <freebsd-arm@freebsd.org>; Fri, 24 Aug 2012 04:03:23 +0000 (UTC)
	(envelope-from imp@bsdimp.com)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com
	[209.85.210.182])
	by mx1.freebsd.org (Postfix) with ESMTP id 869DD8FC0C
	for <freebsd-arm@freebsd.org>; Fri, 24 Aug 2012 04:03:23 +0000 (UTC)
Received: by ialo14 with SMTP id o14so3240748ial.13
	for <freebsd-arm@freebsd.org>; Thu, 23 Aug 2012 21:03:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=eI5+aVAQMNRlLMXxkUR0Gm4Y8aCwg0o1YoPQvX3yxX8=;
	b=Cfb4pbWg3vlU4NEutQ2EnkUztDTX6SC+Jm7GEuQk3je+MDmujRAZ9+s222KOJExBIX
	QxhUVFsNlfXlrP+yrlqWM6ctW/TtmBoiWlIn8/2lyhFOi5g3Im7cHvZozYeSs6ZWaQTK
	J/XGJTbWY6caIZ+UrNdHJFvraftTdORwhD+aGdNgrhx20C5R8s8thAArFd/gOj1Y2QwU
	dbwhiOkJOahZk3JqOxL6a4omDutsG2k11Kd2jCi4owV2WX7D7RFvN2LWN1yso8OLgNMC
	GOpV6KMGH3T3kLpaKFQTwc69LvQ37/0jOlQLJhzOZ7AHiydxuWIUIvAf7ee6ueMjsXkX
	b82g==
Received: by 10.50.213.106 with SMTP id nr10mr617077igc.58.1345781002439;
	Thu, 23 Aug 2012 21:03:22 -0700 (PDT)
Received: from 63.imp.bsdimp.com
	(50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198])
	by mx.google.com with ESMTPS id ey10sm3397801igb.17.2012.08.23.21.03.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 23 Aug 2012 21:03:21 -0700 (PDT)
Sender: Warner Losh <wlosh@bsdimp.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <1345769488.27688.625.camel@revolution.hippie.lan>
Date: Thu, 23 Aug 2012 22:03:19 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6639450F-11BB-4D01-8D0C-CD66B427EF08@bsdimp.com>
References: <1345757300.27688.535.camel@revolution.hippie.lan>
	<3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com>
	<1345763393.27688.578.camel@revolution.hippie.lan>
	<FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com>
	<1345765503.27688.602.camel@revolution.hippie.lan>
	<CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G+B9xB3NvPFJQ@mail.gmail.com>
	<1345769488.27688.625.camel@revolution.hippie.lan>
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
X-Mailer: Apple Mail (2.1084)
X-Gm-Message-State: ALoCoQlqDGjfTBCPWpAwCTqI2FpK5DGgFeGh2ek+pdMCDCDxkzLRC3ExNSUj0KP7qxg0QynZ3jv6
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-arm@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
	<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
	<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2012 04:03:24 -0000


On Aug 23, 2012, at 6:51 PM, Ian Lepore wrote:

> On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote:
>> On 23 August 2012 16:45, Ian Lepore <freebsd@damnhippie.dyndns.org> =
wrote:
>>=20
>>> 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?
>>>=20
>>> 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.
>>=20
>> That hardware would suck, wouldn't it?
>>=20
>=20
> 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.

And also allow for different cache line sizes for different CPUs within =
the same MACHINE/MACHINE_ARCH, which is common in MIPS land, at least.

Warner