Date: Sat, 3 Dec 2005 14:32:24 +0300 (MSK)
From: vitalhome@rbcmail.ru
Message-Id: <200512031132.jB3BWOd5047350@www4.pochta.ru>
To: david-b@pacbell.com
Cc: linux-kernel@vger.kernel.org, dpervushin@ru.mvista.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [PATCH 2.6-git] MTD/SPI dataflash driver
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1227
Lines: 25

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/