Re: [spi-devel-general] SPI bus driver synchronous support
From: Stephen Street
Date: Wed Mar 29 2006 - 20:32:07 EST
On Wed, 2006-03-29 at 13:49 -0600, Kumar Gala wrote:
> I was wondering if there was any thought to providing a mechanism for
> SPI bus drivers to implement a direct synchronous interface so we
> don't have to use wait_for_completion.
>
> 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. I need a truly
> synchronous interface opposed to one fronting the async interface.
>
While is should be possible (it only software after all, right) there
may be complications:
1) The SPI framework relies heavy on the 2.6 driver model and I do not
know much of the system is running in a "MachineCheck handler" before a
reboot.
2) Most of current SPI controller drivers rely on kernel threads to
drive and internal queue. See spi_bitbang.c for an example. Are kernel
threads still running by the time you want to invoke a fully synchronous
transfer?
3) Some SPI controller drivers are completely interrupt driven with DMA
transfers. See pxa2xx_spi.c for an example. Are interrupts still
enabled by the time you want to invoke a fully synchronous transfer?
This in mind it should be possible to add a transfer_sync function
similar to this:
struct spi_master {
...
int (*transfer_sync)(struct spi_device *spi,
struct spi_message *mesg);
...
};
static inline int
spi_full_sync(struct spi_device *spi, struct spi_message *message)
{
if (spi->master->transfer_sync) {
message->spi = spi;
return spi->master->transfer_sync(spi, message);
}
return -EOPNOTSUPP;
}
Off course, all SPI controller drivers would need some kind of interlock
between the standard transfer and transfer_sync.
Do you have SPI hardware or are you using spi_bitbang? If you have
dedicated hardware what type?
What do you think David?
> Also, who is the maintainer for the SPI subsystem?
>
David Brownell
-Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/