Re: [RFC PATCH 3/5] pxa: clean up the legacy SSP API

From: Eric Miao <eric.y.miao@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@sirena.org.uk>,
	Philipp Zabel <philipp.zabel@gmail.com>,
	Paul Shen <bshen9@marvell.com>,
	linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
	Daniel Ribeiro <drwyrm@gmail.com>
Subject: Re: [RFC PATCH 3/5] pxa: clean up the legacy SSP API
Date: Thu, 30 Apr 2009 10:31:53 +0800	[thread overview]
Message-ID: <f17812d70904291931o7bbf4df6g2827bdb28920f82b@mail.gmail.com> (raw)
In-Reply-To: <20090429185151.GC21459@n2100.arm.linux.org.uk>

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.
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel