Re: [spi-devel-general] Re: [PATCH 2.6-git 0/4] SPI core refresh

[Rui Sousa <rui.sousa@laposte.net>]

On Tue, 2005-12-13 at 08:35 -0800, David Brownell 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?
> 
> I don't understand the question.  The SPI controller may be busy
> handling transactions for a different device,

If you provide an async API to start with... if everything is sync
then this problem goes away[1]. When I started writing the SPI layer for
my platform (before any SPI patches started circulating) I was going
to use an async API and then decided against it. For the type of device
I'm using, a SLIC device, where only control data is exchanged on the
SPI bus (read register, check some bit, write register, ...) and very
small amounts of data are transferred at a time (4 bytes maximum) there
is really no point to an async API.

Once you give the possibility to transfer data asynchronously on the SPI
bus, and even if you add a pseudo sync interface, you loose the
possibility to call the transfer function (synchronously) from hard/soft
interrupt context. One way or the other you will eventually need to
sleep.

This forces a simple code like:

u8 device_read_reg(int reg)
{
	u8 buf;

	buf = reg;
	spi_write(dev, &buf, 1);

	spi_read(dev, &buf, 1);

	return buf[0];
}

to be moved to user context or to become much more complex (state
machine + async callbacks).

I guess what I'm trying to say is that for a simple device like the one
I'm using, having an async API adds more trouble that what it's worth
it. Unfortunately I don't have a better solution to put forward.

>  so the best you
> could do from _any_ IRQ handler is to queue some messages that
> will get to the IRQ-issuing device sometime later.
>   It's not
> possible to make the other transactions finish any faster, or
> abort them safely mid-transfer.
> 
> The way the ads7846 driver handles it, for example, is to issue
> a transaction collecting a bunch of touchscreen sensor readings.
> And disable its (nonsharable) irq,

nonsharable is the magic word. I thought of this solution, leaving the
interrupt handler with the interrupt masked and do all the handling in
a workqueue... but my GPIO pin used to generate the interrupt is being
shared with another device.

>  since the interrupt will be
> raised for some time and there's no portable way for Linux to
> force the IRQ to trigger only on the relevant edge.
> 
> See the 2.6.15-rc5-mm1 patches...
> 
> - Dave
> 
> 

Rui

[1] I know this is not a reasonable solution for a number of cases.