On Tue, Mar 30, 2010 at 9:19 AM, Feng Tang <feng.tang@xxxxxxxxx> 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." -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
