public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <dvrabel@arcom.com>
To: stephen@streetfiresound.com
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PXA2xx SPI controller updated for 2.6.16-rc1?
Date: Tue, 24 Jan 2006 12:11:22 +0000	[thread overview]
Message-ID: <43D6196A.5040209@arcom.com> (raw)
In-Reply-To: <1137690309.4623.24.camel@localhost.localdomain>

Stephen Street wrote:
> On Thu, 2006-01-19 at 10:51 +0000, David Vrabel wrote:
> 
>>Do you have a version of the PXA2xx SPI contoller driver more recent
>>that the one posted at the end of October 2005?  There are some SPI (and
>>other) API changes required for 2.6.16-rc1.
> 
> I'm working on it now.  I expect to have something with in the week.

Cool.

>>I've attached my attempt (PIO works but DMA doesn't) if it's of any use.
>>
>>The patch also:
>>  - includes support for the different clock on the PXA27x
>>  - calculates the correct clock divisor (at least on the PXA27x...)
>>  - allows null_cs_control for PIO transfer.
>>
> 
> I will review and integrate you changes. THANKS!

When you have a version that works with 2.6.16-rc1 I can produce new
patches including just these changes if that's more convinient.

>>I'm currently using SSP3 on the PXA27x with the slave chip select GPIO
>>line configured as SSPSFRM3 instead of a GPIO.  This works fine provided
>>that each spi_message consists of a single spi_transfer.  With more than
>> one transfer they're not back-to-back and SSPSFRM3 is deasserted
>>between transfers.
> 
> I believe this is the correct SSP in SPI mode behavior for PXA2xx.

I agree.  However, this isn't the behavior I need.

On the board I have here the chip select of the SPI slave (a CAN
controller) is connected to GPIO83 which is also SSPSFRM3.  GPIO83 must
be configured as SSPSFRM3 otherwise the SPI controller doesn't work at
all.  These means I need to use the SSPSFRM3 signal as the chipselect.
This works fine at the moment for single transfer messages and it could
be made for multiple transfer messages if after exhausting a tx_buf the
SPI controller driver switches to the next transfer instead of waiting
for a transmit empty interrupt.

I'll take a look at implementing this once you've produced a updated
version of the driver. (I've worked around it for now by only using
single transfer messages.)

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

      reply	other threads:[~2006-01-24 12:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-19 10:51 PXA2xx SPI controller updated for 2.6.16-rc1? David Vrabel
2006-01-19 17:05 ` Stephen Street
2006-01-24 12:11   ` David Vrabel [this message]

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=43D6196A.5040209@arcom.com \
    --to=dvrabel@arcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stephen@streetfiresound.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