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/