Scott,

SPI would clock only when the Chip Select line for a peripheral is low.

So, SPI would clock only when the Chip Select 0 line for ADS 1278 is low.

Up until the "booting" word showing in the log file of the boot, CS0 = 0.
It's seen like this with a Voltmeter.
Detection of 1278 doesn't take place, according to messages in the log file of the boot.
It should according to .modalias in board_overo.c.

When a device is not detected on SPI 1 Chip Select 0, then on SPI 1, Chip
Select becomes 1.

In the log of the boot file, at the "remounting root fs" level, Chip Select is 1.
After "remounting root fs", ads1278.c and omap2_mcspi.c are not executed because
CS0 = 1.

I am studying more your:

SPI setup on module load using the
spi_alloc/spi_add functions. I think this is new kernel spi stuff.


Ion A. Beza.

On Thu, Feb 25, 2010 at 11:28 AM, Scott Ellis <scottellis.developer@gmail.com> wrote:
Hi all,

Tony, why do you care what the McSPI controller is doing with CS if
it's not connected to anything on your device? Just curious, I don't
have much SPI experience.

FWIW, I put up a real simple overo SPI driver here

http://github.com/scottellis/overo-myspy

Not intended for anything real. I was just playing around with the
only SPI device I have handy, an I/O expander, but I'm not really
interested enough in it to finish a driver for it. It was more just
for fooling around with gumstix SPI.

It does one thing kind of interesting that I haven't seen people
talking about and that is I skip the board registration stuff in
board-overo.c and instead do all SPI setup on module load using the
spi_alloc/spi_add functions. I think this is new kernel spi stuff.

Seems to work okay, but like I said, just an experiment right now. I
can use the I/O expander as expected.

There are two problems I've encountered.

One is DMA transfers fail on the last byte, doesn't matter how big the transfer.
DMA transfers happen when len >= 8. If you stay below 8 bytes, no
problem. The data looks good on the scope though so I think it's a
omap2_mcspi driver problem.

The second is the state of the CS line is low before the driver
starts. That might  be a problem with a real driver. Okay for simple
testing though.

One more problem. There is a bug in the omap2_mcspi_cleanup() code. I
submitted a patch to the kernel guys that was accepted. I'll send one
to you Steve if you want it. Most people won't ever encounter it.

Just thought I'd share.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users