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 [EMAIL PROTECTED] 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=/ _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
