On Mon, 12 May 2014 13:32:32 +0200 Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > On 05/12/2014 09:54 AM, Siarhei Siamashka wrote: > > On Sun, 11 May 2014 22:47:03 +0200 > > Hans de Goede <hdego...@redhat.com> wrote: > > > > <snip> > > >> So what is your opinion no the 3th patch in this series which drops the > >> DRAM clk on the cubieboard2 to 432 MHz ? > > > > It's all very complicated. We also had a report about some A20 device > > not being able to run stable with dram clocked at 432MHz. Unless MBUS > > was also synchronously clocked at 432MHz (using PLL5 instead of PLL6): > > http://irclog.whitequark.org/linux-sunxi/2013-11-26#5690482 > > To some extent this conflicts with the two assumptions from your > > patch series ("432MHz is stable" and "fast MBUS is bad"). > > > > I would say that a bit more experiments are still needed. > > > > Also the whole patch series tries to address the issues, which are > > only specific to Cubieboard2 and Cubietruck. My take on this is the > > following. CubieTech is a commercial company selling these boards. > > They are interested in having high specs listed on their website > > (1GHz CPU, 480MHz DDR3). And they are also interested in having > > their boards running stable at these clock speeds, because they > > have to deal with the warranty and defective boards replacement. > > CubieTech is also linux-sunxi community friendly with some of their > > representatives available here (Huang Benn). So IMHO it's best if > > we take the settings that CubieTech considers appropriate for their > > hardware. If something is not quite right, then some corrections > > may be applied. But then again, IMHO it's best to keep CubieTech > > in the loop. > > The 432 MHz patch is cubie specific, the FAST_MBUS one is not though, > we can fix Oliver's FAST_MBUS issue in another way I'm fine with > using FAST_MBUS *everywhere*, my main problem with FAST_MBUS is > that I want the define to go away and simply use the same settings > everywhere, to make upstreaming all the u-boot-sunxi code easier. Ah, that's what you mean :-) I don't like this define either and actually have it replaced with the extra 'mbus_clock' variable in the dram_para struct. But that's orthogonal to the original reliability problem. -- 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.
