public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@nokia.com>
To: ext David Brownell <david-b@pacbell.net>
Cc: omap-linux <linux-omap-open-source@linux.omap.com>
Subject: Re: [PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus]
Date: Wed, 17 May 2006 13:13:51 +0300	[thread overview]
Message-ID: <446AF75F.4080005@nokia.com> (raw)
In-Reply-To: <200605161950.17041.david-b@pacbell.net>

ext David Brownell wrote:
>> I think the devices worked so far with this buggy logic since I suspect
>> a complementary problem in the TRM for the read edge selection HW flag.
>> I checked this against devices that are known to be using a given SPI
>> mode.
> 
> Hmm, I hope the attached GIF makes it through ... it shows the data
> and clock signals and their variations pretty clearly, though you need
> to understand that "out" means MOSI.

 From the diagram it seems that the master will shift out the data on 
MOSI at the same time as it is latching in the data on MISO. If that's 
really the case, then as I understand the loopback setup (connecting the 
two lines) wouldn't be possible. Also CPHA would define only the mode on 
the MOSI line, the MISO line would operate according to the opposite 
semantic. This might be the case, though I haven't found a description 
where this distinction was pointed out.

> 
> Agreed, the TRM is a bit opaque there.  There are three bits to
> cover two basic protocol options:  sample edge (2x) which seems
> to encode CPHA, and clock polarity which sure ought to be CPOL.  

Yes, so the 2 edge flags should always be set to the same value to 
define a valid SPI mode.

Also in OMAP2 the SPI PHA flag is defined to be the opposite value of 
the CPHA as defined in the four SPI modes.

> 
> 
>> Also at least the ads7846 was using incorrectly SPI mode 0, since it's
>> expecting writes on the falling / reads on the rising edge which maps to
>> mode 1.
> 
> Seems right ... does that give you more consistent sample readings?

No, setting to mode 1 won't change the actual HW configuration, since 
with the uWire patch the mapping also changes to set the same HW flags 
as we used before.

--Imre

> 
> 
>> I'm posting 3 patches to solve these issues.
> 
> They look OK to me.  I'd say to merge them to the OMAP tree; if no
> problems turn up, I'll push the ads7846 patch along soonish.
> 
> - Dave
> 
> 
> ------------------------------------------------------------------------
> 

  reply	other threads:[~2006-05-17 10:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-15 11:05 Edge selecton on SPI bus Imre Deak
2006-05-15 18:59 ` David Brownell
2006-05-16 22:12   ` [PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus] Imre Deak
2006-05-17  2:50     ` David Brownell
2006-05-17 10:13       ` Imre Deak [this message]
2006-05-26 23:43       ` Tony Lindgren

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=446AF75F.4080005@nokia.com \
    --to=imre.deak@nokia.com \
    --cc=david-b@pacbell.net \
    --cc=linux-omap-open-source@linux.omap.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