[alsa-devel] [RFC PATCH 3/5] pxa: clean up the legacy SSP API

[Eric Miao]

On Thu, Apr 30, 2009 at 2:51 AM, Russell King - ARM Linux
<linux at 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 at 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.
>