[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200521210853.GK4770@sirena.org.uk>
Date: Thu, 21 May 2020 22:08:53 +0100
From: Mark Brown <broonie@...nel.org>
To: Tim Harvey <tharvey@...eworks.com>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>,
open list <linux-kernel@...r.kernel.org>,
linux-can@...r.kernel.org, Wolfgang Grandegger <wg@...ndegger.com>,
Timo Schlüßler <schluessler@...use.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-spi@...r.kernel.org, Jan Glauber <jglauber@...vell.com>,
Robert Richter <rrichter@...vell.com>
Subject: Re: [PATCH] can: mcp251x: convert to half-duplex SPI
On Thu, May 21, 2020 at 01:19:16PM -0700, Tim Harvey wrote:
> Should I be submitting this patch with logic that only does
> half-duplex if the spi controller doesn't support it (if
> (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)) or is it
> acceptable to simply make the driver half-duplex like this for all
> cases?
It seems likely that making the transfers explicitly half duplex will
perform better, especially for PIO controllers since there's less FIFO
stuffing to do but also just generally on longer messages. You will
get some overhead setting up two transfers on write then read messages
which might offset that but my best guess would be that it'll be
negligable on most controllers. It's also just a more accurate
representation of what the transfers are actually doing which seems
nicer.
If there *is* a performance win for doing full duplex messages on some
controllers we should probably look at optimizing this in the SPI core
since it'll affect a wide range of hardware and we already have some
code for forcing full duplex anyway.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists