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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
