On Tuesday 02 December 2008, Joakim Tjernlund wrote: > > > > I've not observed polling from a task context to starve anyone, > > when done sanely. The opposite is true for doing an order of > > magnitude more instructions in IRQ context ... > > When playing with this the app developer complained that the system didn't > behave as expected so I guessed it had to do with starvation. Perhaps > lowering the prio or something would be a wise thing to do? Or is the thread > already at lower prio than normal userspace processes?
If you're only guessing about what's going on, you need to go back and get solid data. What does "as expected" mean? Some app developers have silly expectations. If you were "playing" the issue could more easily have been goofs in your code. > I guess you are not keen on a LOWLAT option for SPI transfers? Again, you're guessing in absence of facts ... including a concrete proposal for what a "LOWLAT option" would be here, and how it would relate to that one developer's possibly unrealistic expectations in the context of a collection of experimental kernel hacks vs. using a saner implementation of the I/O loops to start with. > We a app that needs to do protection What is "do protection"? > (in its own RT pthread) so any SPI > transfers should be performed as quickly as possible when the protection > thread is running, for the rest speed it doesn't matter. You're free to impose whatever queuing discipline you like so long as it's FIFO as observed by each spi_device driver. I would not advise trying to have spi_master.transfer() methods infer anything about the call context, though. Such methods are fragile, and are frowned upon in Linux. - Dave ------------------------------------------------------------------------- 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
