From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Eric Miao <eric.y.miao@gmail.com>
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: Wed, 29 Apr 2009 19:51:51 +0100 [thread overview]
Message-ID: <20090429185151.GC21459@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <f17812d70904290214g110f2a5ax5da4af478688f3d1@mail.gmail.com>
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.
We can not just start the SSP for a 32 byte transfer and hope it happens.
PCON has to be totally in control.
next prev parent reply other threads:[~2009-04-29 18:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-23 5:06 [RFC PATCH 3/5] pxa: clean up the legacy SSP API Eric Miao
2009-04-23 8:24 ` Mark Brown
2009-04-28 22:20 ` Russell King - ARM Linux
2009-04-28 23:06 ` Daniel Ribeiro
2009-04-29 2:18 ` Eric Miao
2009-04-29 7:27 ` Russell King - ARM Linux
2009-04-29 8:21 ` Mark Brown
2009-04-29 8:41 ` Russell King - ARM Linux
2009-04-29 9:14 ` Eric Miao
2009-04-29 18:51 ` Russell King - ARM Linux [this message]
2009-04-30 2:31 ` Eric Miao
2009-04-30 7:08 ` Russell King - ARM Linux
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=20090429185151.GC21459@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=bshen9@marvell.com \
--cc=drwyrm@gmail.com \
--cc=eric.y.miao@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=philipp.zabel@gmail.com \
/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