Max seep of the SD slot?

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| I've upgraded to the current kernel. TTFF-issue is solved by the last
| kernel-patch. Congratulations!
|
| Now I'm testing the inteferences while accessing data from the sd-card.
| On the current default clock of 16MHz I see heavy GPS-signal breach-ins
| in a pulsing manner, if I do some continuous access with 'dd' to the
| card. If I stop dd the perception signal stabilizes. Okay, this was to
| expect.
|
| According to the statement below, the clock rate on the SD-card side is
| far above the effective data-rate on the CPU side. We do 16MHz on one
| and something around 2MHz on the other. That makes no sense to me.
| What about fixing the rate on the sd-card side to far lower level, not
| only while ideling, even if accessing? Lets say 5MHz. Would it make any
| sense and would it decrase the clock noise significally enough, to be
| able to just ignore the hardware patch?

It's not a crazy way to look at it, but the latencies add together
currently.  So we have to sit it out while the Glamo independently grabs
the bulk data from the card, then when it completes we get an interrupt
and basically memcpy it to the requested place.  So we delay the overall
action by slowing the SD clock.

It's worth a try using sd_max_clk if you can "see" the effect of SD
traffic on GPS still.

| I haven't found the file to place any permanent kernel opts yet, to test
| this. No grub, no lilo :-) thats beyond my knowledge about the FR
| booting internals. Any hints?

Kernel commandline lives in the twilight world of U-Boot environment.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiJjBwACgkQOjLpvpq7dMpe0QCgjYbDV2kCTQ+j4kwDZJ9/KOLY
rNEAnRaLpkkpVHpqemSWg3jrK8+3GFN0
=EYsI
-----END PGP SIGNATURE-----