Messages in this thread | | | From | Kumar Gala <> | Subject | Re: [spi-devel-general] SPI bus driver synchronous support | Date | Thu, 30 Mar 2006 23:52:41 -0600 |
| |
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/
| |