From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161151AbdAJQw1 (ORCPT ); Tue, 10 Jan 2017 11:52:27 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:40898 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758655AbdAJQwZ (ORCPT ); Tue, 10 Jan 2017 11:52:25 -0500 Date: Tue, 10 Jan 2017 16:51:46 +0000 From: Mark Brown To: David Lechner Cc: nsekhar@ti.com, khilman@kernel.org, linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Message-ID: <20170110165146.ineknejdhln5mwkv@sirena.org.uk> References: <1483673177-31516-1-git-send-email-david@lechnology.com> <20170109194811.p3if5pzvjjaez2g3@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vcx5zrqa4ndhja4i" Content-Disposition: inline In-Reply-To: X-Cookie: To see you is to sympathize. User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: 2001:470:1f1d:6b5::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RESEND] spi: davinci: Allow device tree devices to use DMA X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vcx5zrqa4ndhja4i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 09, 2017 at 02:40:50PM -0600, David Lechner wrote: > On 01/09/2017 01:48 PM, Mark Brown wrote: > > On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote: > > > Unfortunately, this excludes the possibility of using one SPI device = with > > > DMA and one without on the same master. > > Why would you ever want to do that? What would ever make sense about > > not using DMA if it's available and the transfer is suitably large, or > > conversely why would one want to force DMA even if PIO would be more > > performant? > I don't particularly want to do that, but that is the way the spi-davinci > driver currently works. The choice between DMA or PIO is specified in the > platform data on a per-device basis. > What I get from your remarks is that this is wrong and it needs to be fix= ed. > If that is so, could someone please point out a driver that does it the > right way and I will try to fix it. Pretty much any driver doing DMA... off the top of my head the i.MX and Samsung drivers ought to be reasonable examples. If you've got time to look at fixing the driver the other thing that jumps out with it is the use of a threaded interrupt handler with no actual handling in the thread, that looks like some magic timing based hack which seems risky (or completely unneeded which would be better). > > > When I originally submitted this patch, there was some discussion as = to whether > > > dspi->dma_rx should be changed to return an error rather than being n= ull. > >=20 > > > However, I prefer it the way it is and don't see a compelling reason = to change > > > it. > > I don't know what the above comment means, sorry (and don't recall > > having seen any earlier versions of this). > FWIW, you can find the previous conversation at > https://patchwork.kernel.org/patch/9437901/ What Sekhar is saying there is right, it is better style to use an error pointer rather than NULL as someone could potentially come up with a way to make NULL a valid pointer in the API. But it doesn't matter greatly. --vcx5zrqa4ndhja4i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlh1ESIACgkQJNaLcl1U h9C3cAf9Fp4v6jAUNxccyHktIjSTb9eRWnaDY+696sXQsT7tezWL+0wdAmNPRg5s nntqr7ucxAro0Z5oFwfbhkG7g+xNGykqP6v5mKJ44RYJK+fT4JT0hL3EmZZ/yHQe wkRJDbGu4bWmz081IiquVyY3TQc8Ty5wn3C/gUa+td5qIgtsCyNFTjznz5i9q+Cr GYfNr3lefP78RK6NDQa1oZhqmlRPBuwRNYqKORTWMWN8F6fc7c5sOKqL3xh5Jg0i wdVvUH3H6dWXwK/Bxy+JJi7Meja1U2XxB3hShvHMuKKphxHrWV0sx3jb9b8Ohm2P jwDZSXkLrbawlCfzLcGAk9xwy2ua/Q== =epEW -----END PGP SIGNATURE----- --vcx5zrqa4ndhja4i--