Re: [PATCH v1 3/4] max3100: adds console support for MAX3100

[christian pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>]

On Tue, Mar 30, 2010 at 9:19 AM, Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> No words in my last email suggested to use dynamic SPI clock speed,
> I admited that method is brutal and not mature when my driver was
> reviewed. In early version of our 3110 driver, we don't use dynamic
> clock speed, but the maxim clock supports by 3110, while we still use
> 8 words buffer read for RX.
>
> Let me cut my question clear: why not use the 8 words RX HW fifo? For
> bulk RX in 230400 case, is 50us enough to handle controller IRQ +
> spi subsystem overhead + tty receive overhead for one char per spi
> transfer model?
>

For TX it's impossible. Before sending a char we have to check if T
bit says that the TX buffer is empty. Otherwise if SPI bus speed >
UART baud rate we will loose TX chars for sure. For RX maybe it might
be worth to always do 8 byte transfers and the look at R bit of
transfer i to see if we have a valid char in (i+1) instead of doing
single transfers. But here again we are fixing the insane latency per
start of transfer of the underlying SPI master controller. And let me
say that in the actual driver the 8 byte RX fifo *is* used: the loop
in max3100_ist drains RX buffer at a speed greater than the chars
coming (also at 115200). The 8-bytes RX buffer fills as a consequence
of delays in interrupt thread being awaken.

The tests I did with zmodem show that in the direction max3100 <- PC
has very good efficiency compared to max3100 -> PC. I guess the reason
is that the tx buffer is just 1 byte deep and we don't have any other
way to handle the T bit other than the do loop in max3100_ist. Maybe I
will try to do some instrumentation with systemtap to show this (it's
always nice to find some uses for systemtap). Anyway I'm sure that
it's always better to not loose chars being received than delaying
transmitted one for a bit.

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev