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.
Also, who is the maintainer for the SPI subsystem?
thanks
- kumar
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
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.
> 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().
- Dave
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