On Tuesday 02 December 2008, Joakim Tjernlund wrote: > > > 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?
If your system is that I/O bound, use DMA ... :) > 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? Using a kernel thread, like the not-so-well-named bitbang utilities will do for you, *does* ensure the polling is done in a process context. If it's interruptible, as I suggested, it should also be pre-emptible ... so if its activity (polling) gets to be serious overhead, some other task can be scheduled. ------------------------------------------------------------------------- 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
