Re: [Gumstix-users] Segmentation issue and SPI clock problems

Also remember without a patched omap2_mcspi driver, you can't call
spi_put_device() on the spi_device you get from spi_alloc_device() if you
decide not to use it.
The spi_device has some uninitialized fields that will cause an oops in
omap2_mcspi_cleanup() which gets called by spi_put_device().
That first patch in the series fixes that problem.
You do need to free the spi_device if you don't add it to the bus or you
will have a leak.
--
View this message in context: http://old.nabble.com/Segmentation-issue-and-SPI-clock-problems-tp27883728p27887471.html
Sent from the Gumstix mailing list archive at Nabble.com.

omap2_mcspi.c is a linux omap driver written first I think by some Nokia
guys, but lots of other linux developers have touched it since. Nothing in
there to blame on gumstix ;-)
To change the clock settings I have found you have a couple of choices.
One way is to make sure the first device probed or added in your board init
has the default speed you want.
The second is to override the speed in the speed_hz field of each struct
spi_transfer you add to your spi_messages.
For that second method to work, you need some patches to the omap2_mcspi
driver. It was only partially implemented.
Look at the SPI driver I posted earlier
http://github.com/scottellis/overo-adc-mcp3002 overo-adc-mcp3002 . I
provided patches for omap2_mcspi for OE kernel builds as part of that
project. (I have to rework patch #2 as per the linux-omap guys, but the
functionality will remain the same).
I played around with that driver such that I could have a default
max_speed_hz of one value (a default of sorts) and then for each of two
devices, I would run each communication with them at a different speeds,
intermingled. It works fine.
Look at the adc_async() function in adc.c of the project.
You don't have to mess with enabling or disabling the mcspi clocks.
--
View this message in context: http://old.nabble.com/Segmentation-issue-and-SPI-clock-problems-tp27883728p27884810.html
Sent from the Gumstix mailing list archive at Nabble.com.

Also remember without a patched omap2_mcspi driver, you can't call
spi_put_device() on the spi_device you get from spi_alloc_device() if you
decide not to use it.
The spi_device has some uninitialized fields that will cause an oops in
omap2_mcspi_cleanup() which gets called by spi_put_device().
That first patch in the series fixes that problem.
You do need to free the spi_device if you don't add it to the bus or you
will have a leak.
--
View this message in context: http://old.nabble.com/Segmentation-issue-and-SPI-clock-problems-tp27883728p27887471.html
Sent from the Gumstix mailing list archive at Nabble.com.

Scott,
regarding your statement:
omap2_mcspi.c is a linux omap driver written first I think by some Nokia
>
guys, but lots of other linux developers have touched it since. Nothing in
> there to blame on gumstix ;-)
>
I see that Linux Angstrom 2.6.31 and 2.6.32-r51 come from the Gumstix site,
they are different, so it must be that Gumstix people are these "...other
linux developers have touched it since..." who do change Linux 31 to 32.
Regarding your statement:
The second is to override the speed in the speed_hz field of each struct
> spi_transfer you add to your spi_messages.
I attempted to do this, for example in the section of code in omap2_mcspi.c
below:
#if 0
ret = omap2_mcspi_setup_transfer(spi, NULL);
#endif
#if 0
omap2_mcspi_disable_clocks(mcspi);
#endif
#if 0
t->speed_hz = 12000000;
#endif
but it seems that according to you I need Linux patches because "...It was
only
partially implemented...":
For that second method to work, you need some patches to the omap2_mcspi
> driver. It was only partially implemented.
>
Regarding your statement:
You don't have to mess with enabling or disabling the mcspi clocks.
that would be good. I am working on your patches.
Ion A. Beza.
On Sat, Mar 13, 2010 at 5:41 AM, ScottEllis
<scottellis.developer@...>wrote:
>
> Also remember without a patched omap2_mcspi driver, you can't call
> spi_put_device() on the spi_device you get from spi_alloc_device() if you
> decide not to use it.
>
> The spi_device has some uninitialized fields that will cause an oops in
> omap2_mcspi_cleanup() which gets called by spi_put_device().
>
> That first patch in the series fixes that problem.
>
> You do need to free the spi_device if you don't add it to the bus or you
> will have a leak.
>
> --
> View this message in context:
> http://old.nabble.com/Segmentation-issue-and-SPI-clock-problems-tp27883728p27887471.html
> Sent from the Gumstix mailing list archive at Nabble.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
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details