In-Reply-To: <200603300953.01583.david-b@pacbell.net>
References: <7C75FBEB-F962-4860-A797-AC6B454D6E6E@kernel.crashing.org> <200603300953.01583.david-b@pacbell.net>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EFC9942C-D6F4-4494-9ED7-C6B9B5A6DD46@kernel.crashing.org>
Cc: spi-devel-general@lists.sourceforge.net,
       linux kernel mailing list <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 7bit
From: Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [spi-devel-general] SPI bus driver synchronous support
Date: Thu, 30 Mar 2006 23:52:41 -0600
To: David Brownell <david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1989
Lines: 54


On Mar 30, 2006, at 11:53 AM, David Brownell wrote:

> 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.

Agreed.  It only on the exceptional case of the machine check.  For  
example I would like to send a "mute" command to a micro controller  
which controls audio output if we crash.

>> 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().

That's true.  I guess I'll have to give more thought on if there is a  
way between the bus and client drivers.

I assume you are the SPI maintainer at this point?

- kumar


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