Re: [PATCH] Add support for slave controllers plus sysfs entries for power management

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Tue, Feb 16, 2010 at 1:48 PM, Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org> wrote:
> On 02/16/2010 02:33 PM, Linus Walleij wrote:
>> 2010/2/15 jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>>> 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....
>>> http://www.mail-archive.com/spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg00368.html
>>
>> 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.

g.

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev