mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Street <stephen@streetfiresound.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	David Brownell <david-b@pacbell.net>,
	spi-devel-general@lists.sourceforge.net
Subject: Re: [spi-devel-general] SPI bus driver synchronous support
Date: Wed, 29 Mar 2006 17:34:03 -0800	[thread overview]
Message-ID: <1143682443.4496.20.camel@ststephen.streetfiresound.com> (raw)
In-Reply-To: <7C75FBEB-F962-4860-A797-AC6B454D6E6E@kernel.crashing.org>

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


  reply	other threads:[~2006-03-30  1:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-29 19:49 Kumar Gala
2006-03-30  1:34 ` Stephen Street [this message]
2006-03-30 17:53 ` [spi-devel-general] " David Brownell
2006-03-31  5:52   ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1143682443.4496.20.camel@ststephen.streetfiresound.com \
    --to=stephen@streetfiresound.com \
    --cc=david-b@pacbell.net \
    --cc=galak@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®