archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/>
To: Ned Forrester <nforrester-/>
Cc: Ken Mills <>,
	spi mailing list
Subject: Re: [PATCH] Add support for slave controllers plus sysfs entries for power management
Date: Tue, 16 Feb 2010 20:19:31 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <4B7B048C.8080205-/>

On Tue, Feb 16, 2010 at 1:48 PM, Ned Forrester <nforrester-/> wrote:
> On 02/16/2010 02:33 PM, Linus Walleij wrote:
>> 2010/2/15 jassi brar <>:
>>> I don't think adding SPI_SLAVE support is just a matter of providing
>>> additional callbacks and structures, as is pointed out in this thread....
>> You mean that the responsiveness / control of latencies is the other thing
>> that's needed? Yep so it is. But getting the infrastructure in place doesn't
>> hurt because this is something many people (including self) need and Ken
>> over at Intel is the only one actually doing something about it.
>> Getting SPI slaves to actually work by spawning their worker threads as
>> realtime under that patchset is of course a larger issue. One does not
>> exclude the other tho.
> I'm a little fuzzy on what application you have in mind for this.  It
> doesn't seem productive to lay in a layer of changes for slave operation
> before knowing if it is possible to create a useful slave.  Putting the
> infrastructure before determining feasibility seems the wrong way
> around, especially since you wouldn't be sure what support to add unless
> you have a working model.

exactly right.  Otherwise it is premature generalization.

> As pointed out in the above thread (by David Brownell, not by me), many
> masters expect the slave to respond within one SPI clock cycle (between
> the last bit of the command and the first bit of the response).  On a
> 400MHz PXA processor, I have measured interrupt latency in excess of
> 600us (100us min, 200us typ), so that would imply a maximum SPI clock of
> 1kHz for generalized slave operation.  I'm not sure how many
> applications would be happy with that; likely a few.  I don't think use
> of real time threads will decrease the latency significantly; that is to
> say: whatever reduced latency is achievable is likely to still present a
> significant limit on SPI clock rate for the general case.
> If, on the other hand, you mean to develop restricted slave capability,
> such as the always-predictable case of data-streaming between a single
> slave/master pair, that would be different.   That is the way my slave
> application (and likely others) work.  Note that I did not need any
> changes to the SPI core for that application, only to the device drivers.
> I don't mean to be negative, just realistic.  It's only worth adding
> this capability if there is a clear case that it will be useful in practice.

Well said.  You've pretty much nailed it from my perspective.


SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW

  parent reply	other threads:[~2010-02-17  3:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 21:06 Ken Mills
2010-01-19 15:59 ` Grant Likely
     [not found]   ` <>
2010-02-14 23:20     ` Linus Walleij
     [not found]       ` <>
2010-02-15  1:37         ` jassi brar
     [not found]           ` <>
2010-02-16 19:33             ` Linus Walleij
     [not found]               ` <>
2010-02-16 20:48                 ` Ned Forrester
     [not found]                   ` <4B7B048C.8080205-/>
2010-02-17  3:19                     ` Grant Likely [this message]
2010-02-16 22:07                 ` Grant Likely
2010-02-17  1:43                 ` jassi brar
2010-02-16 22:01             ` Grant Likely

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 \ \
    --to=grant.likely-s3s/ \ \
    --cc=nforrester-/ \ \
    --subject='Re: [PATCH] Add support for slave controllers plus sysfs entries for power management' \

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