gumstix-users

<html>
<body>
<font size=2 color="#0000FF">We have an Overo with Palo43 and LCD module;
all is well and the device boots and works fine.&nbsp; 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. 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..<br><br>
By observing the log file of the booting when the touchscreen is mounted,
u-boot seems to do device <br>
recognition.<br>
</font>&nbsp;<br>
<font size=2 color="#0000FF">Before the log file shows &quot;remounting
root fs&quot; (including remounting of ads7846.c, which is the <br>
touchscreen driver), the log file shows &quot;booting&quot;, meaning
u-boot is running.<br>
It is during this &quot;booting&quot; that ADS7846 is detected on SPI 1,
Chip Select 0, or is not.<br>
It is detected when in board_overo.c the field .modalias =
&quot;ads7846&quot;.<br>
Without this field written in board-overo.c, the detection doesn't
happen.<br>
Once again, this detection is during &quot;booting&quot; as per the log
file.<br>
The log file prints messages that show detection or not.<br>
The exact words in these messages are not found with a search engine on
the computer, meaning <br>
we don't have the source code that generates them. <br>
So, where are they?<br><br>
u-boot also puts Chip Select to 0 on SPI 1 after it detects
ADS7846.</font> <br>
<font size=2 color="#0000FF">Later-on, after &quot;remounting root
fs&quot;, the file ads7846.c (the touchscreen driver) takes over, detects
ADS7846 <br>
like u-boot did, does transmit and receive on the SPI bus when the screen
is touched, and maintains <br>
Chip Select to 0.<br>
</font>&nbsp;<br>
Ray<br><br>
</body>
</html>

Hi Ray,
> 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?
Could you include the complete boot log, and the exact text of the
messages you're referring to?
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

<html>
<body>
At 11:29 AM 2/24/2010, you wrote:<br>
<blockquote type=cite class=cite cite="">&gt; The exact words in these
messages are not found with a search engine on the<br>
&gt; computer, meaning<br>
&gt; we don't have the source code that generates them.<br>
&gt; So, where are they?<br><br>
Could you include the complete boot log, and the exact text of the<br>
messages you're referring to?</blockquote><font color="#800000"><br>
Hi Dave,<br>
Be glad to shortly!<br><br>
Ray<br>
</font></body>
</html>

On Wed, Feb 24, 2010 at 11:14 AM, RayS <rays@...> 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@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>

<html>
<body>
At 01:06 PM 2/24/2010, you wrote:<br>
<blockquote type=cite class=cite cite="">On Wed, Feb 24, 2010 at 11:14
AM, RayS &lt;rays@...&gt; wrote:<br>
&gt; We have an Overo with Palo43 and LCD module; all is well and the
device<br>
&gt; boots and works fine.&nbsp; The LCD however has 4 wire SPI (ie with
CS) and is is<br>
&gt; not the best example for a driver for a read-only ADC module (no
CS). The<br>
&gt; main issue we're having is that the Gumstix only enables the SPI
clock<br>
&gt; (SCLK) if a device is recognized at boot.<br><br>
I think your expectations might be wrong.</blockquote><br>
<font color="#800000">always possible!<br><br>
</font><blockquote type=cite class=cite cite="">The SPI clock is not
free-running.&nbsp; It is only driven during actual<br>
SPI transactions.</blockquote><br>
<font color="#800000">SPI/SCLK can free run for the ADS1278 DEV (or
not)<br>
<a href="http://www.ti.com/lit/gpn/ads1278"; eudora="autourl">
http://www.ti.com/lit/gpn/ads1278<br><br&gt;
</a></font><blockquote type=cite class=cite cite="">If you intend to have
more than one device on the SPI bus you *must*<br>
have a chip select per device, otherwise the master has no way to<br>
indicate which slave should talk/listen.<br>
If you have only one device on SPI then you can get by with no chip
select.</blockquote><br>
<font color="#800000">which is the current state of things<br><br>
</font><blockquote type=cite class=cite cite="">&gt; We're having a tough
time figuring<br>
&gt; out what we need to write a kernel (or user) driver that enables
SPI, or can<br>
&gt; assume SPI is enabled from boot..<br><br>
SPI is enabled in the standard image, but you will of course need to<br>
write a kernel driver for the SPI chip you intend to use, and you
will<br>
also need to modify the overo board file in linux to enable that<br>
driver.</blockquote><br>
<font color="#800000">working on that...<br><br>
</font><blockquote type=cite class=cite cite="">&gt; By observing the log
file of the booting when the touchscreen is mounted,<br>
&gt; u-boot seems to do device<br>
&gt; recognition.<br><br>
U-boot does nothing with SPI.&nbsp; The log messages you are referring
to<br>
are output by the linux kernel during the boot process.<br><br>
&gt; Before the log file shows &quot;remounting root fs&quot; (including
remounting of<br>
&gt; ads7846.c, which is the<br>
&gt; touchscreen driver), the log file shows &quot;booting&quot;, meaning
u-boot is<br>
&gt; running.<br>
&gt; It is during this &quot;booting&quot; that ADS7846 is detected on
SPI 1, Chip Select<br>
&gt; 0, or is not.<br>
&gt; It is detected when in board_overo.c the field .modalias =
&quot;ads7846&quot;.<br>
&gt; Without this field written in board-overo.c, the detection doesn't
happen.<br>
&gt; Once again, this detection is during &quot;booting&quot; as per the
log file.<br>
&gt; The log file prints messages that show detection or not.<br>
&gt; The exact words in these messages are not found with a search engine
on the<br>
&gt; computer, meaning<br>
&gt; we don't have the source code that generates them.<br>
&gt; So, where are they?<br><br>
They are in the linux ads7846 driver!<br>
<a href="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"; eudora="autourl">
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</a&gt;
<br>
&gt; u-boot also puts Chip Select to 0 on SPI 1 after it detects
ADS7846.<br>
&gt; Later-on, after &quot;remounting root fs&quot;, the file ads7846.c
(the touchscreen<br>
&gt; driver) takes over, detects ADS7846<br>
&gt; like u-boot did, does transmit and receive on the SPI bus when the
screen is<br>
&gt; touched, and maintains<br>
&gt; Chip Select to 0.<br><br>
U-boot does nothing with SPI.&nbsp; The log messages you are referring
to<br>
are output by the linux kernel during the boot process.</blockquote><br>
<font color="#800000">thanks, we'll review <br><br>
<br>
Ray</font></body>
</html>

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@...> wrote:
> On Wed, Feb 24, 2010 at 11:14 AM, RayS <rays@...> 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@...
> > 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@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

On Wed, Feb 24, 2010 at 2:01 PM, Tony Oxendahl <toxend@...> wrote:
> Changes in printk in ads7846.c don't show up in the log of the boot file.
> The messages come from elsewhere.
Perhaps we are not talking about the same messages!
I am referring to:
ads7846 spi1.0: touchscreen, irq 274
ads7846 spi1.0: no device detected, test read result was 0x00000000
I'm pretty darn sure those messages came from ads7846.c since I'm the
one who put the device detection in the driver :-)
The first line is printed by line 1168 of ads7846.c:
dev_info(&spi->dev, "touchscreen, irq %d\n", spi->irq);
The second is printed by line 1178 of ads7846.c:
dev_info(&spi->dev, "no device detected, test read result was 0x%08X\n", err);
If you are talking about some other messages, post just the lines you
are referring to I'll help you find where they come from.
Steve
> Ion A. Beza.
>
>
>
> On Wed, Feb 24, 2010 at 1:06 PM, Steve Sakoman <sakoman@...> wrote:
>>
>> On Wed, Feb 24, 2010 at 11:14 AM, RayS <rays@...> 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@...
>> > 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@...
>> 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@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>

Hi Tony,
...snip...
> Regarding your own answer Dave, and the slicing of the log of the boot file,
> I consider this:
>
>> The following messages are most likely from loadable kernel modules
>> being loaded as part of the /etc/rc.d mechanism
>>
>> ------------------------------
>>>
>>> ----------------------
>>> > Ion's test 9: SPI clock is enabled here.
>>> > ads7846 spi1.0: touchscreen, irq 274
>>> >
>>> > input: ADS7846 Touchscreen
>>> > as /devices/platform/omap2_mcspi.1/spi1.0/input/input0
>>> > Caching udev devnode
>
> as being the source of the messages.
>
> So the messages don't come from ads7846.c (touchscreen driver), but from:
> "...part of the /etc/rc.d mechanism..."
Well, they're still probably coming from ads7846.c. The ads7846 module
is being loaded by "...part of the /etc/rc.d mechanism..."
What I was really trying to say, is that those messages definitely
didn't come from u-boot as u-boot ended a long time earlier in the
log.
Now when you say that changes in printk aren't showing up, were you
just reloading the kernel, or were you also updating the loadable
modules?
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

Hi Tony,
On Thu, Feb 25, 2010 at 9:58 AM, Tony Oxendahl <toxend@...> wrote:
> Dave, thanks for taking interest in this matter.
>
> Regarding your:
>
>> > It sounds like maybe your probe routine isn't being called. The string
>> > passed to the driver register MUST exactly match the string in the
>> > board file.
>
> in board-overo.c I declared .modalias="adc1278".
> According to the documentation spi-summary this declaration should bind the
> ADC
> driver, adc1278.c (which is a copy of ads7846.c to be tweaked later-on),
> when the initialization code (like scripts in /etc/init.d and rc.d) runs at
> boot.
> This should take care of the first problem, the detection problem: the probe
> routine
> in adc1278.c should be called.
> (like the probe routine in ads7846.c was called; that's why I am using 7846
> as a working
> model on how s)
So this is where things are a little hazy for me. I've never used the
modalias stuff, so I'm not quite sure of the implications.
After your system has booted up, what does
ls /sys/class/platform/devices
ls /sys/class/platform/drivers
show?
I don't have my gumstix readily available right now, so I'm looking at
one of my boards at work.
> In the log of the boot file you see messages written by me, like
>
> Ion's test 9: SPI clock is enabled here.
>
> which is a change I made (a printk(...)) in omap2_mcspi.c.
> Why would this change be updated and changes I make similarly in ads7846.c
> aren't?
Probably because omap2_mcspi.c is statically linked into the kernel,
and ads7846.c is compiled into a loadable module, and you're only
updating the kernel (statically compiled stuff) and not the loadable
modules.
> What do I need to do, in commands to update all my changes?
I'm not sure what the "correct" OE way to do things is.
You can copy the ads7846.ko file (or whatever it's called) from your
build environment to your board. It goes somewhere in the
/lib/modules/2.6.xxx directory tree (find the location of the old
one),
> Finally for now, regarding the second issue, driver that I am making,
> adc1278.c, once again,
> does the controller driver omap2_mcspi.c apply to a 3-wire ADC 1278, or it
> applies only to 4-wire
> SPI?
I'm not familiar enough with the omap to know the answer to that. Most
of the SPI stuff I've worked with has separate MOSI/MISO lines. The
hardware would need special support to support both 3-wire and 4-wire
(since in 3-wire the MOSI/MISO share a pin), and I don't know what the
OMAP has.
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

Quick clarification here, Dave, about your:
I'm not familiar enough with the omap to know the answer to that. Most
> of the SPI stuff I've worked with has separate MOSI/MISO lines. The
> hardware would need special support to support both 3-wire and 4-wire
> (since in 3-wire the MOSI/MISO share a pin), and I don't know what the
> OMAP has.
>
The 3-wire ADC 1278 is MISO, MOSI, Clock.
No Chip Select.
Like if 1278 bends the SPI protocol.
The question of how, is asked at TI and pending .
(in 1278 terminology the three wires are DOUT, DIN, SCLK)
Ion A. Beza.
On Thu, Feb 25, 2010 at 10:18 AM, Dave Hylands <dhylands@...> wrote:
> Hi Tony,
>
> On Thu, Feb 25, 2010 at 9:58 AM, Tony Oxendahl <toxend@...> wrote:
> > Dave, thanks for taking interest in this matter.
> >
> > Regarding your:
> >
> >> > It sounds like maybe your probe routine isn't being called. The string
> >> > passed to the driver register MUST exactly match the string in the
> >> > board file.
> >
> > in board-overo.c I declared .modalias="adc1278".
> > According to the documentation spi-summary this declaration should bind
> the
> > ADC
> > driver, adc1278.c (which is a copy of ads7846.c to be tweaked later-on),
> > when the initialization code (like scripts in /etc/init.d and rc.d) runs
> at
> > boot.
> > This should take care of the first problem, the detection problem: the
> probe
> > routine
> > in adc1278.c should be called.
> > (like the probe routine in ads7846.c was called; that's why I am using
> 7846
> > as a working
> > model on how s)
>
> So this is where things are a little hazy for me. I've never used the
> modalias stuff, so I'm not quite sure of the implications.
>
> After your system has booted up, what does
>
> ls /sys/class/platform/devices
> ls /sys/class/platform/drivers
>
> show?
>
> I don't have my gumstix readily available right now, so I'm looking at
> one of my boards at work.
>
> > In the log of the boot file you see messages written by me, like
> >
> > Ion's test 9: SPI clock is enabled here.
> >
> > which is a change I made (a printk(...)) in omap2_mcspi.c.
> > Why would this change be updated and changes I make similarly in
> ads7846.c
> > aren't?
>
> Probably because omap2_mcspi.c is statically linked into the kernel,
> and ads7846.c is compiled into a loadable module, and you're only
> updating the kernel (statically compiled stuff) and not the loadable
> modules.
>
> > What do I need to do, in commands to update all my changes?
>
> I'm not sure what the "correct" OE way to do things is.
>
> You can copy the ads7846.ko file (or whatever it's called) from your
> build environment to your board. It goes somewhere in the
> /lib/modules/2.6.xxx directory tree (find the location of the old
> one),
>
> > Finally for now, regarding the second issue, driver that I am making,
> > adc1278.c, once again,
> > does the controller driver omap2_mcspi.c apply to a 3-wire ADC 1278, or
> it
> > applies only to 4-wire
> > SPI?
>
> I'm not familiar enough with the omap to know the answer to that. Most
> of the SPI stuff I've worked with has separate MOSI/MISO lines. The
> hardware would need special support to support both 3-wire and 4-wire
> (since in 3-wire the MOSI/MISO share a pin), and I don't know what the
> OMAP has.
>
> --
> 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@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

Hi Tony,
On Thu, Feb 25, 2010 at 10:33 AM, Tony Oxendahl <toxend@...> wrote:
> Quick clarification here, Dave, about your:
>
>> I'm not familiar enough with the omap to know the answer to that. Most
>> of the SPI stuff I've worked with has separate MOSI/MISO lines. The
>> hardware would need special support to support both 3-wire and 4-wire
>> (since in 3-wire the MOSI/MISO share a pin), and I don't know what the
>> OMAP has.
>
> The 3-wire ADC 1278 is MISO, MOSI, Clock.
>
> No Chip Select.
> Like if 1278 bends the SPI protocol.
> The question of how, is asked at TI and pending .
>
> (in 1278 terminology the three wires are DOUT, DIN, SCLK)
Well that's really 4-wire SPI, with no chip-select.
I don't know if the OMAP SPI supports the notion of "no-chip-select".
You might just have to specify that there is a chip select and not use
it (which is fine - it's an output pin).
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/