Re: [PATCH] spi: bcm2835: enable dma modes for transfers meeting certain conditions

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

 




Den 10.05.2015 22:47, skrev kernel@xxxxxxxxxxxxxxxx:
From: Martin Sperl <kernel@xxxxxxxxxxxxxxxx>

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 <noralf@xxxxxxxxxxx>
(private communication)

Signed-off-by: Martin Sperl <kernel@xxxxxxxxxxxxxxxx>
---
  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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux