All of
 help / color / mirror / Atom feed
From: Mark Brown <>
To: Martin Sperl <>
	Stephen Warren <>
Subject: Re: ARM: bcm2835: DMA driver + spi_optimize_message - some questions/info
Date: Thu, 3 Apr 2014 23:02:32 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]

On Wed, Apr 02, 2014 at 10:40:41PM +0200, Martin Sperl wrote:

> 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.

Sending several mails might've helped too - the way a patch series is
structured is actually a fairly good way of breaking things up for

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

> spi-optimize - essentially the patch shared with my original email touching:
> include/linux/spi/spi.h
> driver/spi/spi.c

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

There should be some win from this purely from the framework too even
without drivers doing anything.

> Does this look "ok" from an approach perspective?

Broadly.  Like I say the DMA stuff is the biggest alarm bell - if it's
not playing nicely with dmaengine that'll need to be dealt with.

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

It's OK to post the lot at once as part of a series but it needs to be
split up into separate logical patches.  Hopefully we can get the
externally visible optimisation stuff merged relatively quickly so that
drivers can start building on it.

> 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.

Yes, something like that.  The most important thing is to make it usable
with any driver.

> 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.

That would seem very surprising - I'd really have expected that we'd be
able to expose enough capability information from the DMA controllers to
allow fairly generic code; there's several controllers that have to work
over multiple SoCs.

> 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. 

Right, and it does depend on being able to DMA to set GPIOs which is
challenging in the general case.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2014-04-03 22:02 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
     [not found]         ` <>
2014-04-03 22:02           ` Mark Brown [this message]
     [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.