On Thu, 2008-11-20 at 20:10 -0800, David Brownell wrote: > On Tuesday 21 October 2008, Joakim Tjernlund wrote: > > > > > Maybe it indeed makes more sense to use polling for high bitrates. > > > > The cpu can't keep up at ~10MHz for me, but even at much small Hz > > the poll is significantly faster, the IRQ overhead seems huge or is it > > something else? > > I'd guess IRQ-per-word is a bad design policy ... If you assume 10 MHz > SPI clock, and (keeping math simple) a 10-bit word, then a polling loop > of 1 MHz -- 1 usec/loop -- is needed to keep up. > > Regardless of latency, per-IRQ overheads (save context, call handler, > do its work, return, restore) are not always below 1 usec... > > > > The question is if the poll code I sent is good, even for longer transfers? > > Perhaps some sort of LOWLAT flag could be used for transfers that really > > need them? > > So long as you do the polling with IRQs enabled, I'd keep it simple and > just always poll. YMMV of course, but most devices seem to prefer more > like 10 MHz clocks than 1 MHz ones.
Sorry for the delay, forgot about this. Won't polling for long periods starve user space? How to overcome this? Why use a kernel thread(mpc83xx_spi.0) to do the work? Would it not be better if the polling was in process context? Jocke ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
