Re: pxa2xx_spi with SFRM

[Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org>]

Ned Forrester wrote:
> Vernon Sauder wrote:
>> <opinion> As a user, it would seem that the SSP should work with
>> minimum fuss. If there are values that enable 99% of devices to work,
>> then why would you *not* want them to be the defaults? If the user
>> needs to tweak the values because they need more performance, then they
>> can. But if they only need a low bandwidth connection, causing
>> transfers to hang because they did not provide a "know-able" value
>> seems less than useful. I know it took me entirely too long to get this
>> working. I am only trying to help the next user that needs this.
>> </opinion>
> 
> I agree with your sentiment.  What I am not sure of is whether there are
> even 90% of applications that could use a single group of settings.  I
> think the DMA burst and the thresholds could likely be set to reasonable
> defaults: burst = bits/word (for 8, 16, and 32 bit words, this results
> in burst equaling half the FIFO), and thresholds of 8/8 (again, half the
> FIFO).  For the timeout, I'm less sure of the best approach; probably it
> should be very long, a millisecond or more (if we know what that
> translates to on a PXA270), and let users reduce it if they want faster
> response.  My main concern is the poor documentation of this in the PXA
> developer's manuals.

Vernon, have you had any more thoughts about this.  I am working on a
patch to deal with problems that were discovered a while ago, and which
finally tripped up another user (Re: [spi-devel-general] [PATCH]
pxa2xx_spi: wait_rx_stall before deasserting CS on PIO mode).  I
wondered if we are ready to converge on any changes.  On the one hand it
would be easy to throw improvement in the defaults in the with the other
changes, but on the other hand I think they are independent, and so they
should probably be in separate patches.

As a consequence of studying the driver for the other patch (regarding
transfer delays and chip select), I have a new understanding of the
timeout that simplifies the problems I discussed above.  I am now
reasonably sure (but cannot test) that a timeout value that is "too
short" will only result in excess interrupt service for unneeded
timeouts, and not in early termination of a transfer.  In
interrupt_transfer, acceptance of a timeout interrupt is conditioned on
being able to retrieve all expected characters from the RX FIFO; in
dma_transfer, acceptance is similarly conditioned on the whole transmit
process being complete (and thus the receive process is done or will be
in nsec).

The result is that neither a too short, nor a too long timeout is fatal,
and thus it IS reasonable to more firmly establish a default timeout,
even it is short.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/