On Thu, Apr 30, 2009 at 2:51 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Wed, Apr 29, 2009 at 05:14:13PM +0800, Eric Miao wrote:
On Wed, Apr 29, 2009 at 4:41 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Wed, Apr 29, 2009 at 09:21:53AM +0100, Mark Brown wrote:
On Wed, Apr 29, 2009 at 08:27:06AM +0100, Russell King - ARM Linux wrote:
On Tue, Apr 28, 2009 at 08:06:08PM -0300, Daniel Ribeiro wrote:
The SPI subsystem?
Can the SPI system cope with the other chip being the master of the interface. In other words, can SPI sit around primed for a transfer, and notify the user of SPI that new data has arrived?
If not, the SPI subsystem is totally unsuitable for this.
It's slave only at the minute - there's holes in the API someone could fill in but that's not happened yet.
Well, I guess someone else will have to do that; I don't spend much time on the LX stuff, and so if it requires any time consuming work, it won't be worth trying to get it into mainline.
However, the patch itself doesn't looks like to be a SPI slave (I mean from the view of the processor).
'struct spi_message' does support simultaneous rx/tx transfer and multiple such transfers being queued.
The transfers happen under control of PCON not the PXA; PCON asserts a GPIO to activate the DMA to control when the transfer happens.
That's too bad then. Does that GPIO act like a chip select or it's just a signal to inform the host to do a transfer? And it also depends on the SCLK direction.
If the GPIO behaves like an IRQ to inform the host for a transfer, maybe the driver can arrange a transfer initiated by that event.
We can not just start the SSP for a 32 byte transfer and hope it happens. PCON has to be totally in control.