From owner-freebsd-arm@FreeBSD.ORG Fri Aug 24 04:03:23 2012 Return-Path: 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 ; 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 ; Fri, 24 Aug 2012 04:03:23 +0000 (UTC) Received: by ialo14 with SMTP id o14so3240748ial.13 for ; 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 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh 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> <1345765503.27688.602.camel@revolution.hippie.lan> <1345769488.27688.625.camel@revolution.hippie.lan> To: Ian Lepore 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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