On Mon, May 25, 2020 at 02:41:31PM +0200, Marc Kleine-Budde wrote: > On 5/25/20 1:31 PM, Mark Brown wrote: > > This isn't something that every individual driver should be doing, such > > rewriting should happen in the core so that everything sees the benefit. > The core could merge several half duplex transfers (until there's as cs_change) > into a single full duplex transfer. Yes, that is what I am suggesting. > I think it's not easy to detect and reliable to split a full duplex transfer > into half duplex ones. How can you tell, if the controller is supposed to tx 0x0 > or actually receive. I don't understand how that could possibly work or why it would make sense? > I think spi_write_then_read() can be extended to generate one full duplex > transfer instead on two half duplex ones it does a memcpy() anyways. This has the same problem as doing it in any other driver code - it causes a needless incompatibility with three wire and single duplex devices. > To get a feeling for the use cases, this is what I do in the regmap read > function of a (not yet mainlined) CAN SPI driver. Like I say it's probably better if code like this gets pushed into the SPI core where we've got more information about what the controller can do and there's more win from doing the tuning since more devices and systems can take advantage of it.
Attachment:
signature.asc
Description: PGP signature
