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
>
>
> ------------------------------------------------------------------------
>
next prev parent 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