[lkml]   [2005]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [spi-devel-general] Re: [PATCH 2.6-git 0/4] SPI core refresh
On Tue, 2005-12-13 at 16:11 +0100, Rui Sousa wrote:
> On Tue, 2005-12-13 at 15:09 +0300, dmitry pervushin wrote:
> > On Mon, 2005-12-12 at 19:01 +0100, Rui Sousa wrote:
> > > How do you handle IRQ's generated by a SPI device (e.g ack the
> > > interrupt, check if it was the SPI device that generated the
> > > interrupt, ...) if you can't read/write on the SPI bus from interrupt
> > > context?
> > Hmm... what do you mean by "cannot read/write" ? Normally you can
> > write/read registers in interrupt context
I expect the answer from David Brownell too; and, because both discussed
frameworks are going to be the only (and the best), please also pay
attention to his (possible) answer. But I'd comment your code :)
> If I read the API correctly reading/writing a byte from the SPI bus
> (synchronously) always implies putting the task doing the read to sleep:
> int spi_transfer(struct spi_msg *msg, void (*callback) (struct spi_msg
> *, int))
> {
> ...
> err = TO_SPI_BUS_DRIVER(bus->driver)->queue(msg);
> wait_for_completion(&msg->sync);
> ...
> }
> So, how can I, from an interrupt handler, read/write a couple of bytes
> from my SPI device using this API?
You can issue the request (in terms of core that you are using, queue
the message) in interrupt context, and perform the rest of processing in
`status' callback. It will be called when message is processed. You can
ack the irq here, and continue your processing.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-13 18:18    [W:0.106 / U:30.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site