Steve, your:

I think your expectations might be wrong.

The SPI clock is not free-running.  It is only driven during actual
SPI transactions.

If you intend to have more than one device on the SPI bus you *must*
have a chip select per device, otherwise the master has no way to
indicate which slave should talk/listen.

is understood. The SPI clock is not assumed free-running.

It is observed to be free-running only when in omap2_mcspi.c, this section:

ret = omap2_mcspi_setup_transfer(spi, NULL);
omap2_mcspi_disable_clocks(mcspi);

is commented out.
After that observation, the code is enabled back.
Chip Select 0 is consecutively used for ADS7846 as a model, and then for 1278 to
emulate the model.

SPI is enabled in the standard image, but you will of course need to
write a kernel driver for the SPI chip you intend to use, and you will
also need to modify the overo board file in linux to enable that
driver.

board-overo.c declares ADC1278 like it declares 7846:

static struct spi_board_info overo_spi_board_info[] __initdata = {
    {
        .modalias        = "adc1278",
//        .modalias        = "ads7846",

        .bus_num        = 1,

//              .chip_select            = 1,
        .chip_select        = 0,

//        .max_speed_hz        = 27000000,
        .max_speed_hz        = 1500000,

        .controller_data    = &ads7846_mcspi_config,

//        .irq            = 31,
        .irq            = OMAP_GPIO_IRQ(OVERO_GPIO_PENDOWN),

//        .platform_data        = &ads7846_config,
        .platform_data        = &ad1278_config,
    },

and I create the driver adc1278.c with adc1278.h, starting from ads7846.c and ads7846.h.

They are in the linux ads7846 driver!
Once again, u-boot does nothing with SPI.  Everything you mention is
done by the linux ads7846 driver.
 
Changes in printk in ads7846.c don't show up in the log of the boot file.
The messages come from elsewhere.

Ion A. Beza.
 


On Wed, Feb 24, 2010 at 1:06 PM, Steve Sakoman <sakoman@gmail.com> wrote:
On Wed, Feb 24, 2010 at 11:14 AM, RayS <rays@blue-cove.com> wrote:
> We have an Overo with Palo43 and LCD module; all is well and the device
> boots and works fine.  The LCD however has 4 wire SPI (ie with CS) and is is
> not the best example for a driver for a read-only ADC module (no CS). The
> main issue we're having is that the Gumstix only enables the SPI clock
> (SCLK) if a device is recognized at boot.

I think your expectations might be wrong.

The SPI clock is not free-running.  It is only driven during actual
SPI transactions.

If you intend to have more than one device on the SPI bus you *must*
have a chip select per device, otherwise the master has no way to
indicate which slave should talk/listen.

If you have only one device on SPI then you can get by with no chip select.

> We're having a tough time figuring
> out what we need to write a kernel (or user) driver that enables SPI, or can
> assume SPI is enabled from boot..

SPI is enabled in the standard image, but you will of course need to
write a kernel driver for the SPI chip you intend to use, and you will
also need to modify the overo board file in linux to enable that
driver.

> By observing the log file of the booting when the touchscreen is mounted,
> u-boot seems to do device
> recognition.

U-boot does nothing with SPI.  The log messages you are referring to
are output by the linux kernel during the boot process.

> Before the log file shows "remounting root fs" (including remounting of
> ads7846.c, which is the
> touchscreen driver), the log file shows "booting", meaning u-boot is
> running.
> It is during this "booting" that ADS7846 is detected on SPI 1, Chip Select
> 0, or is not.
> It is detected when in board_overo.c the field .modalias = "ads7846".
> Without this field written in board-overo.c, the detection doesn't happen.
> Once again, this detection is during "booting" as per the log file.
> The log file prints messages that show detection or not.
> The exact words in these messages are not found with a search engine on the
> computer, meaning
> we don't have the source code that generates them.
> So, where are they?

They are in the linux ads7846 driver!

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=blob;f=drivers/input/touchscreen/ads7846.c;h=7cc9973241e51dcb88de2087b77c9526a4ed7666;hb=refs/heads/omap3-2.6.32

> u-boot also puts Chip Select to 0 on SPI 1 after it detects ADS7846.
> Later-on, after "remounting root fs", the file ads7846.c (the touchscreen
> driver) takes over, detects ADS7846
> like u-boot did, does transmit and receive on the SPI bus when the screen is
> touched, and maintains
> Chip Select to 0.

Once again, u-boot does nothing with SPI.  Everything you mention is
done by the linux ads7846 driver.

Regards,

Steve

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