LKML Archive on
help / color / mirror / Atom feed
From: Ned Forrester <>
To: David Brownell <>
Subject: Re: [spi-devel-general] [PATCH] atmel_spi: support zero length	 transfer
Date: Fri, 22 Feb 2008 14:52:06 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

David Brownell wrote:
>> This would be OK.  It would not be hard to fix pxa2xx_spi, for example,
>> to reject zero-length transfers in DMA mode, as long as it is acceptable
>> to reject the message in mid-message.
> Such "illegal message" rejection is best done early; "fail-fast".
> Mid-message rejection isn't wrong, but it's a rude policy.
> It'd be best to fix pxa2xx_spi to not start zero-length DMAs.

So again, same as my last reply, it would be best to handle a zero
length transfer silently, as if it were non-zero, but just skipping over
any invalid hardware operations due to the zero length.

>> 	If it were necessary to scan a
>> whole message for zero-length transfers and refuse to queue an offending
>> message, then that adds burden to all messages.
> Sanity checking messages as they're submitted is easy; and it's
> also the natural point for setting up DMA mappings (and making
> those cachelines available for better use).

Hmmm.... Obviously I have much to learn about modern computers.  It had
not occurred to me, even after reading "Linux Device Drivers", Corbet,, that by DMA mapping, one frees the cache for other uses.  It
makes sense.  In my application I pass many large buffers to the master
driver, and I map them in the protocol driver.  I did that without good
reason, but now I see it was the proper choice.

Unfortunately, pxa2xx_spi does any DMA mapping not done by the protocol
driver in pump_transfers, as each transfer is submitted to the hardware.
 There is not currently any message checking done in transfer(), the
only error return from that is if the master driver is shutdown (queue
stopped).  The current scheme is to return the message with non-zero
spi_message.status if it has failed *after* execution has been
attempted.  I don't look forward to making major changes, if we really
want all DMA mapping and error checking to be in transfer(), though I
see no reason why it could not be done.

Ned Forrester                             
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA

  reply	other threads:[~2008-02-22 19:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 15:54 Atsushi Nemoto
2008-02-20 17:55 ` Marc Pignat
2008-02-21  1:52   ` Atsushi Nemoto
2008-02-21  9:26     ` Marc Pignat
2008-02-21 19:23       ` David Brownell
2008-02-22  9:30         ` Marc Pignat
2008-02-22 14:15           ` Atsushi Nemoto
2008-02-22 14:28             ` [spi-devel-general] " Ned Forrester
2008-02-22 19:06               ` David Brownell
2008-02-22 19:52                 ` Ned Forrester [this message]
2008-02-22 18:58             ` David Brownell
2008-02-23  2:55           ` David Brownell
2008-02-25  8:15             ` Marc Pignat
2008-02-22 14:07         ` [spi-devel-general] " Ned Forrester
2008-02-22 19:02           ` David Brownell
2008-02-22 19:36             ` Ned Forrester
2008-02-23  2:37               ` David Brownell
2008-02-25  0:25               ` Atsushi Nemoto

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 \ \ \ \ \ \ \ \
    --subject='Re: [spi-devel-general] [PATCH] atmel_spi: support zero length	 transfer' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).