Re: [PATCH 2.6-git] MTD/SPI dataflash driver

[vitalhome]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/