Re: [PATCH v4 5/9] spi: spi-mem: Mark dummy transfers by setting dummy_data bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/18/20 12:44 PM, Mark Brown wrote:
On Fri, Dec 18, 2020 at 08:41:02PM +0000, Mark Brown wrote:
On Sat, Dec 19, 2020 at 12:49:38AM +0530, Pratyush Yadav wrote:
Anyway, if the SPI maintainers think this is worth it, I won't object.
This gets kind of circular, for me it's a question of if there's some
meaningful benefit from using the feature vs the cost to support it and
from the sounds of it we don't have numbers on the benefits from using
it at present.
...although I do have to say looking at the implementation that the cost
seems low, it's just a flag set on an existing transfer.  The only issue
is if we'd get more win from coalesing the entire transaction (or entire
transmit) into a single transfer that could be DMAed and/or requires
fewer trips through the stack which does make it seem like an unclear
tradeoff from the point of view of client drivers

Using HW dummy cycles save extra software cycle of transfer which involves transfer setup register writes, writing dummy bytes to TX FIFO, interrupt processing.

Implementation wise it just a single bit field added to spi_transfer and on Tegra controller driver programming dummy cycles with prior transfer and skipping sw dummy transfer which is actually not complex.

From quick check, I see HW dummy cycles transfer of 128KB shows 18 Mb/s while SW transfer of bytes shows 17.3 MB/s on average.

When back-to-back read commands are executed using HW dummy cycles will definitely save cycles.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux