From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 393D3C433F5 for ; Tue, 1 Feb 2022 15:31:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240379AbiBAPbE (ORCPT ); Tue, 1 Feb 2022 10:31:04 -0500 Received: from netrider.rowland.org ([192.131.102.5]:40309 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S240354AbiBAPbB (ORCPT ); Tue, 1 Feb 2022 10:31:01 -0500 Received: (qmail 308126 invoked by uid 1000); 1 Feb 2022 10:31:01 -0500 Date: Tue, 1 Feb 2022 10:31:01 -0500 From: Alan Stern To: Arnd Bergmann Cc: Russell King , Greg Kroah-Hartman , Arnd Bergmann , Linus Walleij , Christoph Hellwig , Laurentiu Tudor , linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] ARM: sa1100/assabet: move dmabounce hack to ohci driver Message-ID: References: <20220201150339.1028032-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220201150339.1028032-1-arnd@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 01, 2022 at 04:02:48PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The sa1111 platform is one of the two remaining users of the old Arm > specific "dmabounce" code, which is an earlier implementation of the > generic swiotlb. > > Linus Walleij submitted a patch that removes dmabounce support from > the ixp4xx, and I had a look at the other user, which is the sa1111 > companion chip. > > Looking at how dmabounce is used, I could narrow it down to one driver > one one machine: > > - dmabounce is only initialized on assabet and pfs168, but not on > any other sa1100 or pxa platform using sa1111. > > - pfs168 is not supported in mainline Linux. > > - only the OHCI and audio devices on sa1111 support DMA > > - There is no audio driver for this hardware > > In the OHCI code, I noticed that two other platforms already have > a local bounce buffer support in the form of the "local_mem" > allocator. Specifically, TMIO and SM501 use this on a few other ARM > boards with 16KB or 128KB of local SRAM that can be accessed from the > OHCI and from the CPU. > > While this is not the same problem as on sa1111, I could not find a > reason why we can't re-use the existing implementation but replace the > physical SRAM address mapping with a locally allocated DMA buffer. > > There are two main downsides: > > - rather than using a dynamically sized pool, this buffer needs > to be allocated at probe time using a fixed size. Without > having any idea of what it should be, I picked a size of > 64KB, which is between what the other two OHCI front-ends use > in their SRAM. If anyone has a better idea what that size > is reasonable, this can be trivially changed. > > - Previously, only USB transfers to the second memory bank > on Assabet needed to go through the bounce buffer, now all > of them do, which may impact runtime performance, depending > on what type of device is attached. > > On the upside, the local_mem support uses write-combining > buffers, which should be a bit faster for transfers to the device > compared to normal uncached coherent memory as used in dmabounce. > > Cc: Linus Walleij > Cc: Russell King > Cc: Christoph Hellwig > Cc: Laurentiu Tudor > Cc: Alan Stern > Cc: linux-usb@vger.kernel.org > Signed-off-by: Arnd Bergmann > --- > I don't have this hardware, so the patch is not tested at all. > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 3c7c64ff3c0a..5f2fa46c7958 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1260,7 +1260,8 @@ void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb) > EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep); > > /* > - * Some usb host controllers can only perform dma using a small SRAM area. > + * Some usb host controllers can only perform dma using a small SRAM area, > + * or that have restrictions in addressable DRAM. s/that // s/in/on/ Otherwise the USB parts of this look okay to me. I don't have suitable hardware to test either. (I wonder if anyone is still using this platform...) Acked-by: Alan Stern Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4ED13C433EF for ; Tue, 1 Feb 2022 15:32:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0sygrjwvZ2peJ9aZzcpWEkLTy9e0k/gTJDgRL1kLbZg=; b=n2wxRHLmunAG62 URRQF1jW93s5glmp7aq2Cr5dR0nlqitp0fI3PxOcQfLJQIiD22OCsxQZ5qNIXNLf449YQlcQvXk5f 1lCyZVjHrjisUa/ZrreFcQ3wv/k7xorAqBJ6nEOiuxbdkGU4TmhS/Ddvs/W5kgE0gUnRUN+Wyo2IO usscS0wAm0YfsqwpKH+gaT46qQnnqLXfy7ARVXi/R4cDeWkc9cLGzM785AWCwZCj1hJWaDlZL53Yp /MyAWwPLKbvyHewmsZpcsjsb36+paySNFxhk+yJ8jeu+UwvDXucpRwk0WYL/lNkxQtYsev673DOHN gvicpcFOHcYgNbpDylJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEv7j-00ChHI-4s; Tue, 01 Feb 2022 15:31:15 +0000 Received: from netrider.rowland.org ([192.131.102.5]) by bombadil.infradead.org with smtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEv7a-00ChCH-1M for linux-arm-kernel@lists.infradead.org; Tue, 01 Feb 2022 15:31:10 +0000 Received: (qmail 308126 invoked by uid 1000); 1 Feb 2022 10:31:01 -0500 Date: Tue, 1 Feb 2022 10:31:01 -0500 From: Alan Stern To: Arnd Bergmann Cc: Russell King , Greg Kroah-Hartman , Arnd Bergmann , Linus Walleij , Christoph Hellwig , Laurentiu Tudor , linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] ARM: sa1100/assabet: move dmabounce hack to ohci driver Message-ID: References: <20220201150339.1028032-1-arnd@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220201150339.1028032-1-arnd@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220201_073106_298189_AB8EE18B X-CRM114-Status: GOOD ( 43.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 01, 2022 at 04:02:48PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The sa1111 platform is one of the two remaining users of the old Arm > specific "dmabounce" code, which is an earlier implementation of the > generic swiotlb. > > Linus Walleij submitted a patch that removes dmabounce support from > the ixp4xx, and I had a look at the other user, which is the sa1111 > companion chip. > > Looking at how dmabounce is used, I could narrow it down to one driver > one one machine: > > - dmabounce is only initialized on assabet and pfs168, but not on > any other sa1100 or pxa platform using sa1111. > > - pfs168 is not supported in mainline Linux. > > - only the OHCI and audio devices on sa1111 support DMA > > - There is no audio driver for this hardware > > In the OHCI code, I noticed that two other platforms already have > a local bounce buffer support in the form of the "local_mem" > allocator. Specifically, TMIO and SM501 use this on a few other ARM > boards with 16KB or 128KB of local SRAM that can be accessed from the > OHCI and from the CPU. > > While this is not the same problem as on sa1111, I could not find a > reason why we can't re-use the existing implementation but replace the > physical SRAM address mapping with a locally allocated DMA buffer. > > There are two main downsides: > > - rather than using a dynamically sized pool, this buffer needs > to be allocated at probe time using a fixed size. Without > having any idea of what it should be, I picked a size of > 64KB, which is between what the other two OHCI front-ends use > in their SRAM. If anyone has a better idea what that size > is reasonable, this can be trivially changed. > > - Previously, only USB transfers to the second memory bank > on Assabet needed to go through the bounce buffer, now all > of them do, which may impact runtime performance, depending > on what type of device is attached. > > On the upside, the local_mem support uses write-combining > buffers, which should be a bit faster for transfers to the device > compared to normal uncached coherent memory as used in dmabounce. > > Cc: Linus Walleij > Cc: Russell King > Cc: Christoph Hellwig > Cc: Laurentiu Tudor > Cc: Alan Stern > Cc: linux-usb@vger.kernel.org > Signed-off-by: Arnd Bergmann > --- > I don't have this hardware, so the patch is not tested at all. > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 3c7c64ff3c0a..5f2fa46c7958 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1260,7 +1260,8 @@ void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb) > EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep); > > /* > - * Some usb host controllers can only perform dma using a small SRAM area. > + * Some usb host controllers can only perform dma using a small SRAM area, > + * or that have restrictions in addressable DRAM. s/that // s/in/on/ Otherwise the USB parts of this look okay to me. I don't have suitable hardware to test either. (I wonder if anyone is still using this platform...) Acked-by: Alan Stern Alan Stern _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel