From owner-freebsd-mips@FreeBSD.ORG Fri Aug 24 04:03:24 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 172CF1065673 for ; Fri, 24 Aug 2012 04:03:24 +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 87AF08FC12 for ; Fri, 24 Aug 2012 04:03:23 +0000 (UTC) Received: by ialo14 with SMTP id o14so3240747ial.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=DX5qwQeDD+BYrEtQmAmM3CBYwgKOA/zaUmMGGDRU7r1Af44ig9cXc+2tIXmucUS0ZV INO7+zePR08JTyXt83R/FU2kAn25YXv4ZVQg+9G+RGLgSonSZSK9+r77pcFEsDdUH+hH C9CK7FRY8DO/yOIxVxEfa7aOqbByTXWAoh6SfCmpzEPZtksU1pD0AsYzqvQGsEzGVZDb HatA3mHwtkw3ytBqkSikyGgRvBwzarBPDNA3DIYJDYNzV3FKlXVtAF9izIyA65oZ/N8L jWj59k7T+kdmv5N3cMroQ5757Z96NDRFAd5jGxjfyH5o8eeE7LABLE+lPYuhtqq3eubW 9bBQ== 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: ALoCoQmdrse6vSWQK4r6usRp10hobAtGE8Iwi4m/+BdwAsw/wLuDKCT3/IhRF/BNgV8+7bTiAZgG 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 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