Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751789AbcCKK4P (ORCPT ); Fri, 11 Mar 2016 05:56:15 -0500 Received: from down.free-electrons.com ([37.187.137.238]:34002 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751076AbcCKK4C (ORCPT ); Fri, 11 Mar 2016 05:56:02 -0500 Date: Fri, 11 Mar 2016 11:55:49 +0100 From: Maxime Ripard To: Vinod Koul Cc: Boris Brezillon , Dan Williams , dmaengine@vger.kernel.org, Chen-Yu Tsai , linux-sunxi@googlegroups.com, Emilio =?iso-8859-1?Q?L=F3pez?= , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users Message-ID: <20160311105549.GZ8418@lukather> References: <1457344771-12946-1-git-send-email-boris.brezillon@free-electrons.com> <20160307145429.GG11154@localhost> <20160307160857.577bb04d@bbrezillon> <20160307203024.GD8418@lukather> <20160308025547.GI11154@localhost> <20160309120627.67612b1d@bbrezillon> <20160311062607.GP11154@localhost> <20160311104552.23e06a16@bbrezillon> <20160311100902.GY11154@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CRj9LSjXOCc6Ii+Z" Content-Disposition: inline In-Reply-To: <20160311100902.GY11154@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3546 Lines: 92 --CRj9LSjXOCc6Ii+Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2016 at 03:39:02PM +0530, Vinod Koul wrote: > On Fri, Mar 11, 2016 at 10:45:52AM +0100, Boris Brezillon wrote: > > On Fri, 11 Mar 2016 11:56:07 +0530 > > Vinod Koul wrote: > >=20 > > > On Wed, Mar 09, 2016 at 12:06:27PM +0100, Boris Brezillon wrote: > > > > On Tue, 8 Mar 2016 08:25:47 +0530 > > > > Vinod Koul wrote: > > > > >=20 > > > > > Why does dmaengine need to wait? Can you explain that > > > >=20 > > > > I don't have an answer for that one, but when I set WAIT_CYCLES to 1 > > > > for the NAND use case it does not work. So I guess it is somehow > > > > related to how the DRQ line is controlled on the device side... > > >=20 > > > Is the WAIT cycle different for different usages or same for all > > > usages/channels? > > >=20 > >=20 > > In Allwinner BSP they adapt it on a per slave device basis, but since > > DMA channels are dynamically allocated, you can't know in advance which > > physical channel will be attached to a specific device. >=20 > And we have the correct values availble in datasheet for all usages No, we don't. If you look at the datasheet in question, page 169. https://github.com/allwinner-zh/documents/blob/master/A20/A20_User_Manual_v= 1.4_20150510.pdf This is the only documentation we have. And as you can see, it is very sparse (and that's an understament). So we cannot make that assumption, so far the values have been found through trial and error for the devices in question. > > Another option I considered was adding a new cell to the sun4i DT > > binding to encode these WAIT_CYCLES and BLOCK_SIZE information. But I'm > > not sure adding that to the DT is a good idea (not to mention that it > > would break DT ABI again, and given the last discussions on this topic, > > I'm not sure it's a good idea :-/). >=20 > Yes i was veering towards DT as well. This is a new property so ABI rules > wont break as long as driver still works with old properties. Yeah, we can always default to our current hardcoded value if the property is missing. And since no-one is using the engine at the moment anyway, so it's not really a big deal. > But this nees to be property for clients and not driver. Client can then > program these Yes, totally. The question here is how the clients give that information to the driver. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --CRj9LSjXOCc6Ii+Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW4qQ1AAoJEBx+YmzsjxAg8gsP/1BWPkD13wGa6abOU2GTRX6f IHY8tk6VwNpRQG9DAz+VbtCkwXrjMRQipWK+p5gdzLE0GCpwHxQNRVSb3O0FW0a5 rXYTsoKddbAq2SLil/jrR6rRXAgHV2WDECYgoRmIzwB3t9l5zNCM9ZkyG/to9Hop GKxNJTpTePLIGV6elwe1Lz6qSQlfdu/PG3u9kaOUkE8ZuSDmLpL/KByKd6+qkb4i 9BjAqmI9cuU9nELO1E9U3cn2zdFSExHbgVkLdY7tGOf0m5dd4aLC2VuiJ4fRtUw3 AnSzCDFENLEuy4k9yCbAk9I24o3B3p0WURajWfTlLvJqDfDKkISYQ9YAjQjm7DBY psxBmrNDpovZ/9kAjekUcLvIJ6tffgaEG4vYIQEee/gLtX7V1T0sFEI4Ytn8Ko8L gpFw31DIrKWdj4AplMJhJD9cQXmDM5VAErOM+CzXYyIU8C2/A9OoJ7Nizr/jp4X0 yC+HpLhQxtOyyfvxvlHo3Fepe1ANBFpAQbErYxpj7zGjEp4O+tovZzC9SuXP0Ero adnKgF8AykqDeNrrEDAu/rdgMdyn2nUlKBzqoLzwFrjSOgsMlATuvTKgMVZeFpie DT4f7xSCWvuKXZPPurz+yDTsMHn1ETFT4aPLHuZ8sdT5ldfXGxZY4tqLTolF+YXG bh3peWiRpNSHyAOMreOC =ldqN -----END PGP SIGNATURE----- --CRj9LSjXOCc6Ii+Z--