From owner-freebsd-arch@FreeBSD.ORG Fri Aug 24 04:00:48 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 063BD106566B for ; Fri, 24 Aug 2012 04:00:48 +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 6419F8FC0A for ; Fri, 24 Aug 2012 04:00:47 +0000 (UTC) Received: by ialo14 with SMTP id o14so3236393ial.13 for ; Thu, 23 Aug 2012 21:00:46 -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=/fumm9ehnwMxdlhILXylmJSdzHQbk9R61mCz3E6uRRA=; b=IuMNz62qvmpHzoG5MX56WeR7iDQFUKw3beKKwcVD86mvENRsVZ9OqPjVquc1BPaEHz oLF5MpV1m45zlspURZrcdXFWswfZ6NolnLe6ml3RHwggYgTgxrwcTlIJM3thuUfFJoXd S1MyAz1hLgIXEJV8tLemsZ9MvSx6rNfC1v7TdRfDNk1QFBHyXX7r3bx/vVVpE0f57iHu KlxeZKtElDjIuM0GPGXIENYMwzoodqs5Y0XICrSdZ4cCrnlyCeEmJbwZPyybPcBK2w4c 8vDxnAphlMEPjbJt1y6IoHsX2A20Rx/vZLVTIt/ov3SACphryE90CuK1Way/rDSj8efy HOeA== Received: by 10.50.47.161 with SMTP id e1mr702151ign.11.1345780846750; Thu, 23 Aug 2012 21:00:46 -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 ua2sm3449366igb.7.2012.08.23.21.00.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 21:00:46 -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: Date: Thu, 23 Aug 2012 22:00:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1345766109.27688.606.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl++j6qcE7r4S03QjtCBkezO84OTxqdotfsKoys7bPdKIhAc+WjZ/dpH89hF3CIyaTHeNZt Cc: Ian Lepore , 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-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 04:00:48 -0000 On Aug 23, 2012, at 5:59 PM, Adrian Chadd wrote: > On 23 August 2012 16:55, Ian Lepore = wrote: >=20 >>> In what case though would the hardware say it can only DMA on a 64k >>> alignment BUT move one byte at a time? Then what would the starting >>> address be for each DMA? >>>=20 >>=20 >> Maybe the device has a reduced number of address bits in its = registers >> and the low-order bits always start at zero and increment internally = in >> a wider register so that any length dma can happen, but it has to = start >> on a 64k boundary. >>=20 >> Maybe the address you pass it has to be a 64k boundary, but then the >> bytes actually end up in one-of-N slots within that 64k region, based = on >> other parameters of the transfer. >>=20 >> I've worked with some strange hardware over the years. >=20 > Right. That's pretty odd though. But now I understand where you're = coming from. >=20 > I still think the short term solution should be "fix the USB stack to > not do that!" >=20 > The longer term problem is likely to figure out what makes sense. Eg, > if you're going to allow the allocator to interleave 16 byte chunks > (on a 32 byte cache line platform) with some being DMA buffers and > others being non-DMA buffers; or whether you enforce that the whole > chunk is a DMA buffer for your hardware and you look after it, or > something else.. The bottom line is that you can't mix things like that when cache lines = are involved. The current code that tries is doomed to failure. Doomed. = You just can't control all flushes, as Ian's missive demonstrates, and = trying to accommodate code that does this I don't think can possibly = work. All the interrupt masking, copying in and out, etc I fear is = doomed to utter and abject failure. =20 Warner=