![]() | |||||||||||
Messages in this thread |
David, > So consider two different tasks accessing devices on the same SPI bus. > > One is lower priority, currently waiting for an SPI request to complete. > A request that has your magic "leave me owning chipselect/bus after > this request flag" ... because the first thing it's going to do when > it returns is start another transfer. (And in the case of the MTD driver, > that transfer could already have been queued, removing the issue as > well as the need for that flag.) > > Now the high priority task issues a request to the other device on > that same SPI bus. This means that *two* other tasks ought to be > temporarily operating with that higher priority: whatever task > you've allocated to manage the I/O queue on that bus (plus maybe > an IRQ task with RT_PREEMPT); and the task that's waiting for that > transfer to complete. Inversions ... Can you please tell me if that's not the same for your core? I'm afraid this problem is common between the cores :( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-12-03 13:03 [from the cache] ©2003-2008 | |||||||||||