Scott, I am trying out your myspy.c as a way to allocate a new device to SPI
while avoiding the mechanism of board-overo.c, init.d, rc0.d,...

First observation is that your new device to add to SPI is a master.
(like touchscreen 7846 is declared in board-overo.c to be a master; I thought that 1278 is a slave)

Regarding your:

The result of building myspy.c, using the makefile I provided, is myspy.ko.
 
I put your myspy.c and makefile in the directory:

developer@developer-desktop:~/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/drivers/input/touchscreen$

and in that directory I run the command:

make myspy

to an error in the file start.s line 115.

See below:

developer@developer-desktop:~/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/drivers/input/touchscreen$ make myspy
cc     myspy.c   -o myspy
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o: In function `_start':
/build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:115: undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [myspy] Error 1

Do you know if there is something wrong about this?

Ion A. Beza.

On Thu, Feb 25, 2010 at 5:04 PM, Scott Ellis <scottellis.developer@gmail.com> wrote:
SPI drivers are broken into two pieces.

A controller driver and a protocol driver, both kernel modules.
omap2_mcspi is a controller driver. ADS7846.c or myspy.c are protocol
drivers.

The result of building myspy.c, using the makefile I provided, is myspy.ko.

Use insmod to load it.

It exposes a dorky little char device interface. After you create a char file

$ mknod /dev/myspy c <major> <minor>

you can run i/o commands like

$ echo read-config > /dev/myspy

to get it to do something. The output is via printk statements to the console.
Like I said, dorky, but definitely not userspace.

On 2/25/10, Tony Oxendahl <toxend@gmail.com> wrote:
>>
>> I'm thinking it would be pretty easy to write a SPI protocol driver
>> that connects an overo to a bunch of spi devices on the same 3 wires,
>> (CLK, MOSI, MISO) and use GPIO to select the slaves.
>>
>> You might not be real fast and all the work queue code in the
>> omap2_mcspi driver would be wasted, but it seems like it would work.
>>
>> Is there an electrical limit to the number of slaves on a SPI bus?
>>
>
> The protocol driver would be in userspace.
>
> ads7846.c (and a copy that I tweak, ads1278) is in the kernel.
>
> The first difficulty is detection of 1278 by the init boot.
> (init.d, rc0.d, etc...)
>
> I look at how your sample driver in userspace avoids board_overo.c and
> .modalias.
>
>
> Ion A. Beza.
>
> On Thu, Feb 25, 2010 at 3:17 PM, Scott Ellis <scottellis.developer@gmail.com
>> wrote:
>
>> I'm thinking it would be pretty easy to write a SPI protocol driver
>> that connects an overo to a bunch of spi devices on the same 3 wires,
>> (CLK, MOSI, MISO) and use GPIO to select the slaves.
>>
>> You might not be real fast and all the work queue code in the
>> omap2_mcspi driver would be wasted, but it seems like it would work.
>>
>> Is there an electrical limit to the number of slaves on a SPI bus?
>>
>>
>> On 2/25/10, Dave Hylands <dhylands@gmail.com> wrote:
>> > Hi Ion (sorry just noticed you've been signing Ion, but your email says
>> > Tony),
>> >
>> > On Thu, Feb 25, 2010 at 1:54 PM, Tony Oxendahl <toxend@gmail.com> wrote:
>> >> Good catch, Dave:
>> >>
>> >>> SPI_3WIRE refers to Chip-Select, Data, Clock, where both the input
>> >>> data and output data share the same pin.
>> >>
>> >> This means that the omap2_mcspi.c works for 4-wire SPI, might work for
>> >> 3-wire SPI
>> >> (as defined by MISO=MOSI, Chip Select, Clock), but not for 3-wire
>> >> MISO-MOSI-Clock-NoChipSelect
>> >> which the ADS1278 is.
>> >
>> > No - it will work fine for the last case - worst case is that you just
>> > have to waste a pin for the chip select which doesn't get connected to
>> > anything.
>> >
>> > --
>> > Dave Hylands
>> > Shuswap, BC, Canada
>> > http://www.DaveHylands.com/
>> >
>> >
>> ------------------------------------------------------------------------------
>> > 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
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>

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