From owner-freebsd-usb@FreeBSD.ORG Wed Dec 19 18:58:49 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F94333F for ; Wed, 19 Dec 2012 18:58:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1554F8FC0A for ; Wed, 19 Dec 2012 18:58:48 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so1410568pbc.18 for ; Wed, 19 Dec 2012 10:58:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=WVxI1JkugBHI7AEmxo2kqRHe7J9KoybbisPIOxTXR9M=; b=QwfIO4JQM9ADZviPn7yaeqZ0/voyYYHdiJ8jjRkkvWGw7XEhHrToMaMHBQTpVBRuDo uYeJlN1Hv7vrIfxrMrQ5vup7gOlappD18W6ZKYva6v9nLzrooRJe7Fqka5Llq/H3MS0c vGqgir40pMNagBxDJakzxPvSeJ9aH6+niCGfBplBBQVTwmIrEKeo19E0/WSptKhR22hj Z/kQxP2l3fNtMmjJXil8OPXLP8Rry9JQbXK0VotxJE40LbyXo5Pkkp5xVCf/NXqxzoea sf7rEBjXPSwJpFlTWvAmESYxr9dkSynq49wxui5xXE6k04CFAAE8OgrC0n/YcJ0pzNd/ j3GA== X-Received: by 10.68.220.198 with SMTP id py6mr21383129pbc.119.1355943528671; Wed, 19 Dec 2012 10:58:48 -0800 (PST) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id kp4sm3532161pbc.52.2012.12.19.10.58.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 10:58:47 -0800 (PST) Sender: Warner Losh Subject: Re: EHCI on armv6 with Write-Back caches Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201212190926.35132.hselasky@c2i.net> Date: Wed, 19 Dec 2012 11:58:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121218204931.5322922d@fubar.geek.nz> <201212182044.11326.hselasky@c2i.net> <1482FC19-720A-480A-BAD2-C8CD306E2E5F@bsdimp.com> <201212190926.35132.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmnc8lte1AHwCse32faw08ooqma9/xs3QgLGcSOKOXrWdxANplD281JWODNs68no8BPRYGT Cc: Oleksandr Tymoshenko , Andrew Turner , freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:58:49 -0000 On Dec 19, 2012, at 1:26 AM, Hans Petter Selasky wrote: > On Tuesday 18 December 2012 21:32:46 Warner Losh wrote: >> On Dec 18, 2012, at 12:44 PM, Hans Petter Selasky wrote: >>> On Tuesday 18 December 2012 20:12:29 Andrew Turner wrote: >>>> On Tue, 18 Dec 2012 13:06:44 +0100 >>>>=20 >>>> Hans Petter Selasky wrote: >>>>> Hi Andrew, >>>>>=20 >>>>>> The BUS_DMA_COHERENT flag does nothing on armv6 as we need the = cache >>>>>> enabled for atomic operations to work correctly and we would have = to >>>>>> disable the cache on the entire page. This is acceptable = behaviour >>>>>> from the description of the flag in the busdma man page. >>>>>=20 >>>>> Yes, but when I allocate memory from the USB stack, then I want = that >>>>> memory to not be cached. It is simply not that useful to have that >>>>> memory cached. I didn't check the latest state of busdma, but if = I'm >>>>> not mistaken, if the BUS_DMA_COHERENT flag is set on the DMA tag, = the >>>>> flush/invalidate will simply return and do nothing. Maybe that is = the >>>>> problem ... >>>>=20 >>>> The exact meaning of BUS_DMA_COHERENT depends on the architecture. = The >>>> code is still required to call bus_dmamap_sync with a coherent map = but >>>> when the flag is implemented the cost of the operation will be = reduced. >>>> It doesn't guarantee the memory is uncached, it may be implemented = that >>>> way but the USB code can't rely on it. >>>>=20 >>>> Andrew >>>=20 >>> The USB code doesn't rely on this flag. I'm wondering if BUSDMA by >>> accident sets this flag, so that the cache sync ops are not called. >>=20 >> No. It doesn't. >>=20 >=20 > Hi, >=20 >> Does the USB code still touch bytes in the same cache line while the = DMA is >> still outstanding? >=20 > Yes, only for data. The busdma API must handle this case properly as = discussed=20 > before. No, it mustn't. It can't. The hardware is such that it is impossible to = do this, as discussed before. You can't mix access to memory in the same = cache line between host and DMA. Warner=