Edge selecton on SPI bus

Edge selecton on SPI bus

[Imre Deak]

Hi,

I think the edge selection in the omap_uwire and omap2_mcspi is borked.
I have a patch for it, but I'd like to ask first if my assumption is
right:
On the SPI / uWire bus by definition you can only configure a mode (one
of the 4 modes), in which the read / write takes place on opposite
edges. That is you can't configure for example a read rising edge /
write rising edge mode.

On OMAP2 this I even see from the fact that you can set the reading edge
and the writing edge is implied.

--Imre

Re: Edge selecton on SPI bus

[David Brownell]

On Monday 15 May 2006 4:05 am, Imre Deak wrote:
> Hi,
> 
> I think the edge selection in the omap_uwire and omap2_mcspi is borked.
> I have a patch for it, but I'd like to ask first if my assumption is
> right:
> On the SPI / uWire bus by definition you can only configure a mode (one
> of the 4 modes), in which the read / write takes place on opposite
> edges. That is you can't configure for example a read rising edge /
> write rising edge mode.

That's my understanding, yes.  Consider that if you connect MOSI directly
to MISO for a loopback configuration, what you send is supposed to exactly
match what you receive ... that couldn't happen if there were no settling
time between setting MOSI and reading MISO.

That WRITE_FALLING | READ_FALLING always did look goofy, but I recall it
as more or less a direct translation from the old driver.  In any case
the REVISIT note seems to have gotten lost.

- Dave



> On OMAP2 this I even see from the fact that you can set the reading edge
> and the writing edge is implied.
> 
> --Imre
> 
> 

[PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus]

[Imre Deak]

On Mon, 2006-05-15 at 11:59 -0700, ext David Brownell wrote:
> On Monday 15 May 2006 4:05 am, Imre Deak wrote:
> > Hi,
> > 
> > I think the edge selection in the omap_uwire and omap2_mcspi is borked.
> > I have a patch for it, but I'd like to ask first if my assumption is
> > right:
> > On the SPI / uWire bus by definition you can only configure a mode (one
> > of the 4 modes), in which the read / write takes place on opposite
> > edges. That is you can't configure for example a read rising edge /
> > write rising edge mode.
> 
> That's my understanding, yes.  Consider that if you connect MOSI directly
> to MISO for a loopback configuration, what you send is supposed to exactly
> match what you receive ... that couldn't happen if there were no settling
> time between setting MOSI and reading MISO.
> 
> That WRITE_FALLING | READ_FALLING always did look goofy, but I recall it
> as more or less a direct translation from the old driver.  In any case
> the REVISIT note seems to have gotten lost.

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.

The OMAP2 McSPI code too has a wrong mapping between SPI mode and read /
write edge.

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.

I'm posting 3 patches to solve these issues.

--Imre

> 
> - Dave
> 
> 
> 
> > On OMAP2 this I even see from the fact that you can set the reading edge
> > and the writing edge is implied.
> > 
> > --Imre
> > 
> > 

Re: [PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus]

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]


> 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.

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.  


> 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?


> 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

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus]

[Imre Deak]

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
> 
> 
> ------------------------------------------------------------------------
> 

Re: [PATCH 0/3] ARM: OMAP: SPI edge selection [was Re: Edge selecton on SPI bus]

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [060517 11:50]:
> 
> > 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.
> 
> 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.  
> 
> 
> > 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?
> 
> 
> > 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.

Pushed all 3 patches.

Tony