All of
 help / color / mirror / Atom feed
From: Martin Sperl <>
To: Mark Brown <>
	Stephen Warren <>
Subject: Re: ARM: bcm2835: DMA driver + spi_optimize_message - some questions/info
Date: Wed, 2 Apr 2014 22:40:41 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Thanks for the feedback.

Will try to keep emails shorter - I wanted to get everything out in one
and document it also trying to answer questions I thought would come up.

So I will take it that I can continue from where I am right now.

Just to summarize the current "modules" and their respective files:

spi-optimize - essentially the patch shared with my original email touching:

maybe adding some documentation on how to "optimize" high-volume drivers
to make optimal use of the interface.

basic generic dma-fragment support (structures/methods):
(maybe add: Documentation/dma-fragment.txt)

bcm2835 specific fragment support (dumping, scheduling, linking):

generic spi specific dma-fragment code: 
mostly about extensions pre/post dma transforms for vary support 
- also handling DMA-mapping, and data for the state-machine used in transformation
from spi-message to dma_fragment)
this could get integrated with spi.h/spi.c if it is deemed sensible

spi-bcm2835dma driver:
include/linux/spi/bcm2835.h (SPI DMA registers and Bits)
drivers/spi/spi-bcm2835dma.h (datastructures and defines)
drivers/spi/spi-bcm2835dma_drv.c (driver itself)
drivers/spi/spi-bcm2835dma_frag.c (the code filling/creating the fragments)

Does this look "ok" from an approach perspective?

I will share one module after the other for initial review.

I will brush up the code for the generic DMA fragment code, so that it
becomes presentable and will share that part in the hope that it live in
parallel to dmaengine and/or get somehow integrated - possibly as another target
besides cyclic.

It is really mostly management of those dma blocks so that they can get
joined together easily as well as the management of a group of those blocks.

Also it is designed to be generic that is why there is the bcm2835 specific code
as well as a separate module.

As such drivers using this specific interface will need to know enough about
the HW itself, my assumption is that the driver will need to know about the DMA
engine used to work properly - so I left all sorts of abstractions out of the 
design - this can get added later if needed...
Anyway this should come with deeper integration with dma-engine.

With regards to VARY: I have used the "options" provided to cover most of the
bases that I thought I would need to "auto-optimize" those simple cases of
spi_read, spi_write, spi_write_then_read. The VARY_DELAY_USEC was just added as
an after-thought, as it is not so "complex" to enable this as a feature...

As for the measurements on effective CPU utilization shared originally - is the
data shared understood/convincing? Does it need more explanation?

Ciao, Martin

P.s: as an afterthought: I actually think that I could implement a DMA driven
bit-bang SPI bus driver with up to 8 data-lines using the above dma_fragment 
approach - not sure about the effective clock speed that this could run... 
But right now it is not worth pursuing that further. --
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to
More majordomo info at

  parent reply	other threads:[~2014-04-02 20:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02 16:06 ARM: bcm2835: DMA driver + spi_optimize_message - some questions/info Martin Sperl
     [not found] ` <>
2014-04-02 18:15   ` Mark Brown
     [not found]     ` <>
2014-04-02 20:40       ` Martin Sperl [this message]
     [not found]         ` <>
2014-04-03 22:02           ` Mark Brown
     [not found]             ` <>
2014-04-04 14:17               ` martin sperl
     [not found]                 ` <>
2014-04-10 22:35                   ` Mark Brown
     [not found]                     ` <>
2014-04-11 12:40                       ` martin sperl
     [not found]                         ` <>
2014-04-21 22:20                           ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.