From: David Brownell <david-b@pacbell.net>
To: spi-devel-general@lists.sourceforge.net
Subject: Re: [spi-devel-general] SPI bus driver synchronous support
Date: Thu, 30 Mar 2006 09:53:00 -0800
User-Agent: KMail/1.7.1
Cc: Kumar Gala <galak@kernel.crashing.org>,
       linux kernel mailing list <linux-kernel@vger.kernel.org>
References: <7C75FBEB-F962-4860-A797-AC6B454D6E6E@kernel.crashing.org>
In-Reply-To: <7C75FBEB-F962-4860-A797-AC6B454D6E6E@kernel.crashing.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603300953.01583.david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1534
Lines: 35

On Wednesday 29 March 2006 11:49 am, Kumar Gala wrote:

> The case I have is I need to talk to a microcontroller connected over  
> SPI.  I'd like to be able to issue a command to the microcontroller  
> in a MachineCheck handler before the system reboots.  

Issuing the command is trivial, but knowing it completes before the MCE
handler completes is an entirely different kettle of fish.  Remember, the
SPI controller may in general be busy with some other request, which would
need to finish first even if some other request _could_ jump to the head
of the request queue.

I suspect some system designer is thinking about the problem wrong if
you believe you need that kind of solution.  If for some reason your
board design requires that sort of access, then what you'd be needing
is a way to abort then bypass the normal SPI stack.  It could work like
any other board-specific hack.


> I need a truly   
> synchronous interface opposed to one fronting the async interface.

I think the word "synchronous" means something other than what
you're implying here.  Normally in Linux, it means that the
request handling blocks until completion, sleeping allowed.

You seem to be thinking about something behaving more like a
register access, which is safe to call when in_irq().  

- Dave
-
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/