On Sun, 06 Apr 2014 11:49:22 +0200 Jens Kuske <jensku...@gmail.com> wrote: > On 06/04/14 04:19, Siarhei Siamashka wrote: > > On Wed, 26 Mar 2014 17:40:50 +0100 > > Jens Kuske <jensku...@gmail.com> wrote: > > > >> -#if defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I) > >> -static void dramc_set_autorefresh_cycle(u32 clk) > >> +static void dramc_set_autorefresh_cycle(u32 clk, u32 type, u32 density) > >> { > >> struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE; > >> - u32 reg_val; > >> - u32 tmp_val; > >> - reg_val = 0x83; > >> - > >> - tmp_val = (7987 * clk) >> 10; > >> - tmp_val = tmp_val * 9 - 200; > >> - reg_val |= tmp_val << 8; > >> - reg_val |= 0x8 << 24; > >> - writel(reg_val, &dram->drr); > >> + u32 tRFC, tREFI; > >> + > >> + tRFC = (tRFC_table[type][density] * clk + 1023) >> 10; > >> + tREFI = (7987 * clk) >> 10; /* <= 7.8us */ > > > > Maybe I'm missing something, but what has happened to the "tmp_val = > > tmp_val * 9 - 200" part of the old code? > > > > Also looks like there was an intention to replace "reg_val |= 0x8 << > > 24" with the use of the new DRAM_DRR_BURST macro, but I can't see it > > anywhere either. > > > > I forgot to explain that, I removed the burst refresh. Don't know > whether this was a good idea, but there are some resources stating burst > refreshes reduce power consumption at the expense of increased latency. > Normally there is a tRFC-long refresh every tREFI, with burst there are > 9*tRFC breaks every 9*tREFI. This leads to dram "hangs" of up to 3us > every ~70us. > > "reg_val |= 0x8 << 24" made the controller issue 9 refresh commands in > burst, and thus the period between refresh had to be multiplied by 9. > I don't know why they subtract 200, but it looks like some safety > margin. Maybe I shouldn't have removed that... > > This patch was a RFC to discuss such things, so thanks for the comments. > Maybe it should be added again, but I don't think they originally wasted > any thoughts on this, they simply took the default values (reset-value > for burst is 0x8).
Thanks a lot for the explanations. It all makes sense. Have you tried to check if disabling burst refresh helps to prevent the occasional HDMI signal disruption, sometimes observed when driving a 1920x1080 monitor and doing something memory intensive at the same time? I believe that this could have been your original intention when introducing this tweak ;-) -- 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.