From owner-freebsd-mips@FreeBSD.ORG Mon Aug 27 15:34:35 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 CEA921065673 for ; Mon, 27 Aug 2012 15:34:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 729E88FC30 for ; Mon, 27 Aug 2012 15:34:34 +0000 (UTC) Received: by obbun3 with SMTP id un3so11030980obb.13 for ; Mon, 27 Aug 2012 08:34:34 -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:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=sv9ysqQt0d8GIYk9LOiQWK2BMH1BDWf3NslmGnAmKbY=; b=cZ8Ht/mweFYsCol0lJedZgreCEzY6L0oBvlErTwfIO9JFx2LEhB6m5XJpVKbMxiQmm RcWYlPtUJuIgHnjkiXX+8YxK8xSJYNOvOvwVGEacgxvUBZr1fgLun/hChSrMGJV9uu12 HV+CoBDv8pgTVZWtDhMmTdcONZ2RBpdv4c8MO0jj8aV53r72B2KVfsWEe6j2obOXQsQS g9MhVqmnL0lmX9DFRJhBDAe2B5h5xiwf4adv8g0svMQhWq3c3CD3Stv2LBlPpfzC8ALq 0AZDIH09eunZKZ3tjoJ8iEDanDk3iL1SC6Tokcmb9Wy0EU/2yqSQ+nSLQA8Y0pD25855 CqgA== Received: by 10.182.190.69 with SMTP id go5mr10597608obc.43.1346081674507; Mon, 27 Aug 2012 08:34:34 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id cp8sm17348774obc.23.2012.08.27.08.34.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 08:34:33 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 27 Aug 2012 09:34:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <45C204C3-D4CE-4B00-886A-A88A0FE7CAD7@bsdimp.com> References: <6D83AF9D-577B-4C83-84B7-C4E3B32695FC@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlETiLG3gXUe5Tae8Y9mvIwhHVdBloBau9e4PawB5ZpzsBhoE0tPLcsyxldsc45IPjhWCZl Cc: Hans Petter Selasky , 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: Mon, 27 Aug 2012 15:34:35 -0000 On Aug 27, 2012, at 9:12 AM, Tim Kientzle wrote: >=20 > On Aug 27, 2012, at 6:38 AM, Warner Losh wrote: >=20 >>=20 >> On Aug 27, 2012, at 12:06 AM, Hans Petter Selasky wrote: >>=20 >>> Hi, >>> Correct. >>>=20 >>>> We also need some rules about working with buffers obtained from >>>> bus_dmamem_alloc() and external buffers passed to = bus_dmamap_load(). I >>>> think the rule should be that a buffer obtained from = bus_dmamem_alloc(), >>>> or more formally any region of memory mapped by a = bus_dmamap_load(), is >>>> a single logical object which can only be accessed by one entity at = a >>>> time. That means that there cannot be two concurrent DMA = operations >>>> happening in different regions of the same buffer, nor can DMA and = CPU >>>> access be happening concurrently even if in different parts of the >>>> buffer. =20 >>>=20 >>> Is this something which we can fix using a simple = __align(USB_DMA_ALIGN) on elements in C-structures which are allowed to = be DMA loaded. >>=20 >> No. I don't think so. the reason is that you can't define = USB_DMA_ALGIN to be a constant on MIPS, at least, or I think ARM because = that's determined at run time. >=20 > But don't mbuf structures do pretty much what Hans is suggesting? They kinda do, and kinda don't. > Why is mbuf okay? mbuf is OK because it is never changed while the DMA is pending to the = buffers. That is, m_hdr and m_ext are invariant while the device owns = the memory. In addition, mbuf allocations are so large that no two mbufs = share the same cache line (although it looks like 256 might be too small = to avoid that on some MIPS processors). usb buffers do not obey these = same rules, otherwise none of the stuff we're talking about would = matter. Warner=