DMA capable SPI master driver

[notro]

Is there any interest in pulling a spi-bcm2708 driver that can do DMA?

Source: https://github.com/notro/spi-bcm2708/blob/master/spi-bcm2708.c
Some info: https://github.com/notro/spi-bcm2708/wiki

The driver has been used since September 2013 in the prebuilt FBTFT kernel without issues. The kernel has been downloaded thousands of times as part of the FBTFT images, and also directly from github using rpi-update.

There is one part missing however, the driver doesn't support 9-bit transfers.
I was the one adding that functionality to the current driver, but left it out of this one.
Argumentation: https://github.com/notro/spi-bcm2708/wiki#lossi-mode

Note: The client has to support SPI DMA to make use of the feature.
Example: https://github.com/notro/fbtft/blob/master/fbtft-io.c#L29

[popcornmix]

I don't use SPI, so I'm willing to accept patches if it appears the majority would prefer the change.
Obviously if you can make it so everything the previous driver supported still works then it will be easier to accept.
Any SPI users out there? Can you comment if you'd like this (or prefer to keep existing driver)?

[0b1-k]

DMA SPI would make a serious difference in two ways:

1. Major throughput improvement for bulk transfers (frame buffers, for instance)
2. Interfacing with devices that only use block-oriented SPI DMA transfers due to bandwidth requirements.

Provided that the DMA-based driver preserves the existing behavior of byte-oriented SPI transfers, then this is goodness.

[notro]

Obviously if you can make it so everything the previous driver supported still works then it will be easier to accept.

Even if that 9-bit functionality is flawed for general use?

It doesn't behave as expected for all values:

From BCM2835 ARM Peripherals - 10.3 LoSSI mode

Commands and parameters are issued to a LoSSI peripheral by writing the 9-bit value of the
command or data into the SPI_FIFO register as you would for SPI mode. Reads are automated in that
if the serial interface peripheral detects a read command being issued, it will issue the command and
complete the read transaction, putting the received data into the FIFO.
[...]
Byte read commands are 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0xda, 0xdb, 0xdc.
A 24 bit read can be achieved by using the command 0x04.
A 32bit read can be achieved by using the command 0x09

[popcornmix]

Even if that 9-bit functionality is flawed for general use?
The question is, will people who are happily using the current SPI driver still be happy with the updated one.
If you are saying 9-bit functionality is sufficiently flawed that no-one is happily using it, then it is fine to drop support. If people are happily using it and an update will break things for them, then that makes it a much trickier decision.

[notro]

If anyone is using 9-bit with a LCD controller and suddenly it's gone, they will certainly be unhappy. For them it's working fine. But I don't know of any such drivers execpt two of the drivers that I maintain.
I use 9x8-bit to emulate a 8x9-bit transfer. Luckily on most LCD controllers, 0x00 i a no-op, so I can prefill with that to make all transfers divisible by 9.

Another avenue, is to make it easy to build kernel modules.
Then those that needed SPI DMA could just build the module themselves in a few minutes.
I made a suggestion here #486

I know of 2 main users of SPI DMA and that is for LCD and CAN.
LCD is covered by my FBTFT kernel, and for CAN I don't know how they do it now. I was half expecting some CAN users to chime in here.

[popcornmix]

Anyone using 9-bit SPI transfers, or otherwise concerned by a change in behavior in the SPI please comment here.

@notro feel free to submit a PR. If no one objects in next week or two I'm okay to accept it.
If once it's in there are objections you may have to help find a solution.
Obviously as a last resort it could be reverted or somehow made switchable in behaviour, but hopefully it won't come to that.

[notro]

If once it's in there are objections you may have to help find a solution.

I'm not very keen on spending any more time on this driver, since Martin Sperl is working on DMA support for spi-bcm2835. It might take some time, since he seem to be doing some work on the SPI subsystem as well.

And considering the very low interest in this, I'm just closing the issue.

It is very easy to build this driver for those that need it:
https://github.com/notro/rpi-source/wiki
https://github.com/notro/rpi-source/wiki/Examples-on-how-to-build-various-modules#dma-capable-spi-master-driver-spi-bcm2708