Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965069AbcCNLrG (ORCPT ); Mon, 14 Mar 2016 07:47:06 -0400 Received: from down.free-electrons.com ([37.187.137.238]:51533 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964999AbcCNLrB (ORCPT ); Mon, 14 Mar 2016 07:47:01 -0400 Date: Mon, 14 Mar 2016 12:46:41 +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: <20160314114641.GC30977@lukather> References: <20160307145429.GG11154@localhost> <20160307160857.577bb04d@bbrezillon> <20160307203024.GD8418@lukather> <20160308025547.GI11154@localhost> <20160309120627.67612b1d@bbrezillon> <20160311062607.GP11154@localhost> <20160311104552.23e06a16@bbrezillon> <20160311100902.GY11154@localhost> <20160311105549.GZ8418@lukather> <20160311111825.GC11154@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: <20160311111825.GC11154@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: 2020 Lines: 57 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2016 at 04:48:26PM +0530, Vinod Koul wrote: > > > But this nees to be property for clients and not driver. Client can t= hen > > > program these > >=20 > > Yes, totally. The question here is how the clients give that > > information to the driver. >=20 > For this part am not worried. If we can generalize this then we add to > dma_slave_config. Otherwise an exported symbol from driver should be fine. It's actually what we would like to avoid. We have two potential provider driver that would need such an interface, and we have customer drivers that would be able to use any of these two, depending on which SoCs we're talking about. Maintaining some logic in each and every driver in that case to know which one of this symbol is to be called seems counterproductive and painful. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW5qShAAoJEBx+YmzsjxAg67gQAKywEZdY7pZFIdy1NkB8U7LP kf2nv61lGaekVtOTYuNMFDZjEWXf5qnnuMoQffBYbq3kLP2OEb1NAtaD4fSQSpTo a5T77es2dquJUd/Wx8QZmS0l68rO4oTEi5LuoiIP63tynD4Hs6J/Vf1AT4HF9oVS el6JdFBXtn8IikEWuzFxw9x+nFNXPdN/yHiNGIQQdS1Uxo1S3GLY2rvJaudIQ3Ey XN5WSgVMrQLFj3skQu1KcqEaOZOFKcXI4CcTRZ501VBSya8ogArPLHjmuLb744Ff wid8ld8COpfmadnyMYpo10Ae+xfE54NkKfh1xtYibm5R0vjBCJE8D13NAZaqBSFG 4r6A0+PQaUDgQB75yh689P7vVuoOoWUgRCqHIItQYRd6/G03FRS7epdCg/qNREiz 11MlV9PwNds880ntyoVlw74y3Rbl8d3WdTfhkHmG0Vyk32EEB85w2ftq0UkmF0bo rDMn6qzG/EbSitoNBiBAHIvCFoBsS/PQTSn+zoq6Wzb6LA6EPF4E4q4lSAK12N4v 8MIkwizUoxhlJAq1EK78btTOeD/K0pt40xLWSsKWc4zqrPbzeQE1QfXldyc8l5Dk 2/qEXOY1ioNTH7nctC14dQG/A7NGxlImaYmQK0mX3gvsjvqKgSxoq7rBE9RUnA1L B7/l1yso4xOZtllv3teT =u3PK -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT--