A couple of users of Balloon 3 have recently come across timing problems
when using peripherals on the Samosa bus. The change to
variable-latency IO (VLIO), recently merged into svn trunk, was supposed
to sort this out once and for all. It didn't.
It turns out that the standard arrangement for CPU clock scaling in the
Linux kernel (I've been working with 2.6.29.1) runs the PXA270's memory
clock at 208MHz most of the time. VLIO takes care of the active part of
memory access cycles (when nPWE/nOE/nCS4 are asserted), making sure
they're long enough for the peripheral being accessed. Unfortunately,
when the clock is at 208MHz, the memory controller's registers don't
allow us to lengthen the inactive part of access cycles enough to
satisfy the slowness requirements of some Samosa peripherals. LCD
displays seem to be most sensitive to this.
To sort this out, I've created another kernel patch (balloon3-cpufreq,
only against 2.6.29.1 at the moment) which adjusts the table of CPU
clock frequencies in cpufreq-pxa2xx.c so that the memory clock always
runs at 104MHz. I've made sure that the SDRAM clock stays at 104MHz,
too, since it's derived from the memory clock.
Running the memory clock at 104MHz shouldn't make a noticeable
difference to the performance of anything. In theory, access to the
internal SRAM, LCD SRAM and Quick Capture interface might be a bit slower.
As a consolation prize for any performance loss, the same kernel patch
tweaks the default CPU clock frequency up to its full 520MHz from the
previous 416MHz.
Chris
--
Chris Jones -
chris@martin-jones.com
Martin-Jones Technology Ltd, makers of Solidlights
148 Catharine Street, Cambridge, CB1 3AR, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908
http://www.solidlights.co.uk/
(text/plain)