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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88CECC433F5 for ; Tue, 22 Feb 2022 09:06:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22A9C8D0002; Tue, 22 Feb 2022 04:06:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DB088D0001; Tue, 22 Feb 2022 04:06:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CA658D0002; Tue, 22 Feb 2022 04:06:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id F22D38D0001 for ; Tue, 22 Feb 2022 04:06:55 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B947C9CD50 for ; Tue, 22 Feb 2022 09:06:55 +0000 (UTC) X-FDA: 79169835990.12.F75823C Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf24.hostedemail.com (Postfix) with ESMTP id E095718000F for ; Tue, 22 Feb 2022 09:06:54 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-308-GmoSOj60Pgiu_y5_NLHrDQ-1; Tue, 22 Feb 2022 09:06:50 +0000 X-MC-Unique: GmoSOj60Pgiu_y5_NLHrDQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Tue, 22 Feb 2022 09:06:49 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.028; Tue, 22 Feb 2022 09:06:48 +0000 From: David Laight To: 'Christoph Hellwig' , Hyeonggon Yoo <42.hyeyoo@gmail.com> CC: Baoquan He , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "cl@linux.com" , "penberg@kernel.org" , "rientjes@google.com" , "iamjoonsoo.kim@lge.com" , "vbabka@suse.cz" , "david@redhat.com" , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "linux-crypto@vger.kernel.org" , "steffen.klassert@secunet.com" , "netdev@vger.kernel.org" , "hca@linux.ibm.com" , "gor@linux.ibm.com" , "agordeev@linux.ibm.com" , "borntraeger@linux.ibm.com" , "svens@linux.ibm.com" , "linux-s390@vger.kernel.org" , "michael@walle.cc" , "linux-i2c@vger.kernel.org" , "wsa@kernel.org" Subject: RE: [PATCH 22/22] mtd: rawnand: Use dma_alloc_noncoherent() for dma buffer Thread-Topic: [PATCH 22/22] mtd: rawnand: Use dma_alloc_noncoherent() for dma buffer Thread-Index: AQHYJ8i+SkBT2V8OuE+2tEasDwiwNayfRZ0Q Date: Tue, 22 Feb 2022 09:06:48 +0000 Message-ID: References: <20220219005221.634-1-bhe@redhat.com> <20220219005221.634-23-bhe@redhat.com> <20220219071900.GH26711@lst.de> <20220222084652.GB6210@lst.de> In-Reply-To: <20220222084652.GB6210@lst.de> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: tf9f4smzbr4zs4gsifxzk16ckt4htxtg X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E095718000F X-HE-Tag: 1645520814-193391 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000044, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Christoph Hellwig > Sent: 22 February 2022 08:47 ... > > Hmm.. for this specific case, What about allocating two buffers > > for DMA_TO_DEVICE and DMA_FROM_DEVICE at initialization time? >=20 > That will work, but I don't see the benefit as you'd still need to call > dma_sync_single* before and after each data transfer. For systems with an iommu that should save all the iommu setup for every transfer. I'd also guess that it saves worrying about the error path when the dma_map fails (eg because the iommu has no space). OTOH the driver would be 'hogging' iommu space, so maybe allocate during open() (or equivalent). =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)