Den 10.05.2015 22:47, skrev [email protected]:
From: Martin Sperl <[email protected]>
Conditions per spi_transfer are:
* transfer.len >= 96 bytes (to avoid mapping overhead costs)
* transfer.len < 65536 bytes (limitaion by spi-hw block - could get extended)
* an individual scatter/gather transfer length must be a multiple of 4
for anything but the last transfer - spi-hw block limit.
(some shortcut has been taken in can_dma to avoid unnecessary mapping of
pages which, for which there is a chance that there is a split with a
transfer length not a multiple of 4)
If it becomes a necessity these restrictions can get removed by additional
code.
Note that this patch requires a patch to dma-bcm2835.c by Noralf to
enable scatter-gather mode inside the dmaengine, which has not been
merged yet.
That is why no patch to arch/arm/boot/dts/bcm2835.dtsi is included - the
code works as before without dma when tx/rx are not set, but it writes
a message warning about dma not used:
spi-bcm2835 20204000.spi: no tx-dma configuration found - not using dma mode
To enable dma-mode add the following lines to the device-tree:
dmas = <&dma 6>, <&dma 7>;
dma-names = "tx", "rx";
Tested-by: Noralf Trønnes <[email protected]>
(private communication)
Signed-off-by: Martin Sperl <[email protected]>
---
drivers/spi/spi-bcm2835.c | 303 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 301 insertions(+), 2 deletions(-)
Tested with:
* 2x mcp251x
* 1x enc28j60
* 1x fb_st7735r
Note that to make it work it requires the patch to dma-engine by
Noralf Tronnes for scatter/gather DMA.
Also it is recommended that the patch for the race-condition in
spi_finalize_current_message is applied to avoid a free before unmap
situations (this only happens only in some configurations)
A couple of throughput tests using the fbtft drivers:
I set up 2 SPI display devices running a movie on both framebuffers.
Since I don't have an easy way to hook up 2 displays, the test was run
without anything connected. Throughput was measured to ~2.5MB/s on one
device and ~3.0MB/s on the other in bursts of ~50ms with ~10ms delay
between frames. 'top' shows cpu util of ~25% for each mplayer process
and ~10% for system (30-35% idle).
Log details:
[ 2.833071] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB
video memory, 16 KiB DMA buffer memory, fps=50, spi32766.0 at 48 MHz
[ 3.036245] graphics fb2: fb_ili9341 frame buffer, 320x240, 150 KiB
video memory, 16 KiB DMA buffer memory, fps=50, spi32766.1 at 48 MHz
[ 76.863674] fb_ili9341 spi32766.0: Display update: 2576 kB/s (58.217
ms), fps=14 (69.997 ms)
[ 76.894161] fb_ili9341 spi32766.1: Display update: 3077 kB/s (48.735
ms), fps=16 (59.431 ms)
Only 1 display connected (35ms burst, 15ms delay):
[ 2.826042] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB
video memory, 16 KiB DMA buffer memory, fps=50, spi32766.0 at 48 MHz
[ 51.000128] fb_ili9341 spi32766.0: Display update: 4429 kB/s (33.856
ms), fps=20 (49.968 ms)
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
