From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751221AbdEaPuj (ORCPT ); Wed, 31 May 2017 11:50:39 -0400 Received: from www.zeus03.de ([194.117.254.33]:52324 "EHLO mail.zeus03.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751029AbdEaPuh (ORCPT ); Wed, 31 May 2017 11:50:37 -0400 Date: Wed, 31 May 2017 17:50:35 +0200 From: Wolfram Sang To: Vignesh R Cc: David Laight , Florian Fainelli , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Felipe Balbi , Peter Chen , Roger Quadros , Alan Stern , Mathias Nyman , Javier Martinez Canillas , Baoyou Xie , Sekhar Nori , William wu , Arnd Bergmann , Chris Bainbridge , Wolfram Sang , Krzysztof Opasiak , Felix =?utf-8?Q?H=C3=A4dicke?= , Colin Ian King , "open list:USB SUBSYSTEM" , "clemens@ladisch.de" , "maksim.salau@gmail.com" Subject: Re: RE: [PATCH v3 0/2] usb: Check for DMA capable buffer sanity Message-ID: <20170531155034.GB2399@katana> References: <20170426005612.24850-1-f.fainelli@gmail.com> <84087586-d5fc-3115-4b16-93c75e411c59@gmail.com> <20170528160330.xjseehf6nnoooe75@ninjato> <063D6719AE5E284EB5DD2968C1650D6DD0005BB4@AcuExch.aculab.com> <3619ab73-b9f0-89b8-a8e8-b6600a0bf73d@ti.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <3619ab73-b9f0-89b8-a8e8-b6600a0bf73d@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Possibly more useful would be a variant of (IIRC) dma_map_for_device() > > that will allocate a suitable bounce buffer for non-dma memory. > > I think it can already do so for memory that is outside the address > > range that the device can address (eg for a 32bit PCIe master in 64bit > > system). > >=20 >=20 > Such generic DMA API would be greatly useful! >=20 > I tried adding bounce buffers support to handle vmalloc'd buffers in > MTD/SPI subsystem. But, there was a need felt for generic DMA API that > can allocate bounce buffer for non-dma'able buffers that all drivers can > make use of[1][2] Yes, I see this DMA API would make sense for subsystems like SPI, MTD or USB. For I2C, I don't think it makes a lot of sense because DMA is rarely used there. Most hardware doesn't even have DMA support and if so, the drivers apply a threshold (say 8 bytes) because most I2C transfers are smaller and setting up DMA for that simply doesn't pay off. And we are still talking of a mostly 100 or 400 kHz bus here. So, I'd prefer a lightweight helper function telling if DMA is possible/feasible for a given I2C message. If so, do it. If not, falling back to PIO might be good enough for now. We can implement bounce buffer support in the above helper function later. I don't really want to enforce DMA capable buffers for I2C transactions when DMA is so rarely needed there. So, if I2C is a bit different, then it might simply make sense to keep the function local for I2C now? This seems like a sensible start to me meanwhile. Thanks to all for the helpful input here! --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAlku5kYACgkQFA3kzBSg KbYY5Q//cpHJuOI0Uj6Zh/c21JbSoIat71VIJo0cQdxX7TEcB6/1O0lfagvm0bbF Ycx0EeILCCtAWSFfOSF08PJraqGqHYY5CSRCU4oHNRcH+lSSkHaxnVptpt6PZ8L4 DB2LeqWyzBpHXpatRTr0frhjt6vT8VS95zhY1FWneLcYpsOV786pj2Ut3GE40qzu +AXofyOLMd9avYHtd6mMLS1lu2hd5Z0mVQ7xwO5I4q5CO2fxPSRxj9BsVYEJJHzF Qdtq52cs1AgF1XhLvDeTrKZzE/bNl9FuKGmVrK8r3NXfZEax7ieN+OY8rcUQLPnu 3l0L03oaAc0/ozcJd0dpiYihvos6xC8DkQAJI4pzHP7TBKIe1I1ORLXui1V6ZhMk jvDZ17v6MvpMd3QXnnEz11x60hLChImwUxX59CNX2YWR9vPlmET1c/1Z5U2vKF9t rIXN0BSBuLMetPKFoY2U9AYS8LUD9frsrexlhy0E82daIZQfOLGOVShqaQztdjB0 EK1IGhE1oJvEJU5CdgBl1pshWWmEy5uuvlEg7wMcxRqjpNqy1F/HtkIO7RGgc6EC n4d7HwTIurb/1uqhW6r8y7vahz1rLvablgaic1ljR058FhWP6+/d4tOVrifaKyW+ Nr+DNYNSyAjRnScLVas82HXnES9mjqXfgI+n6sSsg857u6H3OIk= =0SXZ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu--