Re: PXA270 SSPSFRM gates chip select ?

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

Zik Saleeba wrote:
> On Feb 12, 2008 2:24 PM, Ned Forrester <nforrester-/d+BM93fTQY@public.gmane.org> wrote:
>> I thought it was generally considered good practice...
> 
> Yes, it probably is good practice. Unfortunately the tasklet seemed to
> be causing performance issues which made the driver essentially
> unusable for my application. I'm working with a serial chip which
> requires large numbers of small SPI transfers (several register reads
> etc. via SPI on each interrupt). If each of these transfers takes a
> millisecond it becomes impossible to service even a single fairly slow
> serial connection. I have to service 8 relatively fast serial ports so
> I can't put up with 99% SPI unavailability.

I thought you might be doing lots of little transfers; that would 
explain your need.  Is each transfer in a separate message, because you 
have to interact with every transfer, or can you put several transfers 
in one message, to be executed without higher level interaction?   The 
latter would be faster because each transfer would be pumped in 
interrupt context, rather than from a work queue.

> I'm using an earlier kernel (2.6.16) which I've back-ported the latest
> SPI code so it's possible that tasklets work better in more recent
> kernels. Anyone know if that might be true?

Well I do know that the version of pxa2xx_spi.c in 2.6.16 is very old. 
How much did you backport?  Did you get Stephen's 12/7/06 patches? 
Reading your test above, I would guess you did, but wonder what you had 
to change to get the "latest" to compile in 2.6.16.  Does your 
pxa2xx_spi.c contain the function "set_dma_burst_and_threshold()"? If it 
does, you have Stephen's 12/7/06 patch.

>> I assume that "removing the tasklet" means calling pump_transfers()
>> directly from the interrupt service routines, rather than having the
>> ISRs schedule a tasklet to make that call.  Right?
> 
> Not exactly. pump_transfers() is called from pump_messages() and a few
> other places, all of which run in a workqueue. So it's not called from
> interrupt context but from a workqueue.

Actually, it is scheduled from each of the xx_error_stop() and 
xx_transfer_complete() routines, which all run in interrupt context.  It 
is also scheduled from pump_messages, which is the only place it is 
scheduled from a work_queue.  So it is scheduled from a work_queue only 
for each new message, but from interrupt context for each transfer 
within a message, and at the end of each each message to call giveback().

>> I believe tasklets will never run later than the next timer
>> tick, which I believe is 1ms on most modern processors (but which can be
>> changed).  Thus 1ms should be the maximum latency; I would expect better
>> than 1ms most of the time.
> 
> I seem to be seeing 1ms consistently on a Compulab cm-x270 - or at
> least I did until I made this change.

You might want to check the kernel config parameters for your system and 
make sure that the timer ticks are at least 1000HZ.   I notice that mine 
is set by default (by Gumstix perhaps) to be a tickless system (dynamic 
ticks):

CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

I don't know if this helps; it is just the way mine is set.

-- 
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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/