On Thu, 27 Mar 2014 16:26:02 +0100 Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > Thanks for the patches. I've merged and pushed the 1st one. > > The 2nd one esp. is a good find and a nice cleanup. > > It also seems to explain why we were getting various reports about > instability on the cubieboard2, which ships with a dram clock of 480 > where as it seems to be stable at 432, which exactly matches the > threshold above which you say the timings become wrong. > > As Olliver already indicated we would like to do some more tests with > the 2nd patch first, but eventually we definitely will want to merge > it (assuming the testing goes well). > > I'm thinking that this means that we may be able to safely bump the dram > clock on the cubietruck to 480, any opinion on this ? I have a Cubietruck, which can successfully boot to a login prompt with dram clocked at 504MHz. And a Cubieboard2, which can also boot to a login prompt with dram clocked at 552MHz respectively. However it does not mean that these devices are going to really work stable in these configurations. I have tried different tests and workloads during the last year or so. And it appears that competing memory accesses from both ARM CPU and Mali GPU tend to cause problems at the memory clock speeds, which are otherwise stable for CPU-only workloads. I understand that setting up binary drivers and then running some 3D accelerated applications while checking for memory corruption bugs at the same time is not something that many people would enjoy (or even try in the first place). And I had plans to try to simplify the test setup since a long time ago. Finally here it is: https://github.com/ssvb/lima-memtester Basically, that's just a single static binary with no dependencies. It combines a memtester tool with a simple spinning textured cube demo from the work-in-progress free open source Mali400 driver project http://limadriver.org/ It would be 100% free software using only free software tools if the open source lima shader compiler could handle vertex shaders. Right now only the fragment shader binary had been generated using the open source shader compiler. But the vertex shader binary (injected as an array into the source code) still used the output of the proprietary shader compiler from the libMali.so blob. Anyway, my Cubietruck passes the test at 456MHz dram clock speed and fails at 480MHz. And my Cubieboard2 passes it at 504MHz but fails at 528MHz. The second patch from Jens Kuske unfortunately does not seem to have any visible effect here and does not change anything for me. More test results using different hardware are welcome. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.