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.

Reply via email to