public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: John Sanpe <sanpeqf@gmail.com>
Cc: jagan@amarulasolutions.com, u-boot@lists.denx.de,
	"Icenowy Zheng" <uwu@icenowy.me>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>
Subject: Re: [PATCH] suniv: fix dramc autofresh freq calculation issue
Date: Fri, 21 Apr 2023 00:41:17 +0100	[thread overview]
Message-ID: <20230421004117.014e471b@slackpad.lan> (raw)
In-Reply-To: <20230320005959.176726-1-sanpeqf@gmail.com>

On Mon, 20 Mar 2023 08:59:59 +0800
John Sanpe <sanpeqf@gmail.com> wrote:

Hi John,

thanks for sending this, and sorry for the delay.

> External use mhz to express frequency, autofresh use hz,
> no unit conversion is performed when calling, cause dram
> instability at low frequency.

What low frequency? Are you running it with less than 156 MHz?

Anyway I had a deeper look at this DRAM driver a while ago, and made
some significant cleanups. One of them affects
dram_set_autofresh_cycle(), which is ... weird ... to say at least. Not
only does it support specifying the frequency both in MHz or Hz, it also
uses some quite obfuscated arithmetic to avoid divisions.
This is what I made of this function:
https://github.com/apritzel/u-boot/commit/729d3c61b62

This is part of the whole cleanup series, which is not quite ready yet,
but I put a WIP branch up anyway:
https://github.com/apritzel/u-boot/commits/suniv-dram-WIP

As a bonus this allows to run the DRAM at 204 MHz, with JEDEC timings,
which was not only quite stable for me (ran memtester over the
weekend), but also provided quite some performance advantage.

It would be nice if you could give this series a go, and see if it
works for you. Feel free to play around with the frequency, it should
now program optimised timings for each rate.

Regarding your patch: I am afraid this is somewhat obsoleted by my
series, also it seems to just paper over the actual problems, which
probably are in the crude arithmetic.

Cheers,
Andre

> Incorporated xboot repair patch for this driver.
> 
> Signed-off-by: John Sanpe <sanpeqf@gmail.com>
> ---
>  arch/arm/mach-sunxi/dram_suniv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_suniv.c b/arch/arm/mach-sunxi/dram_suniv.c
> index 3aa3ce7627..830fa7895d 100644
> --- a/arch/arm/mach-sunxi/dram_suniv.c
> +++ b/arch/arm/mach-sunxi/dram_suniv.c
> @@ -310,7 +310,7 @@ static u32 dram_get_dram_size(struct dram_para *para)
>  		para->size = 64;
>  	else
>  		para->size = 32;
> -	dram_set_autofresh_cycle(para->clk);
> +	dram_set_autofresh_cycle(para->clk * 1000000);
>  	para->access_mode = 0;
>  	dram_para_setup(para);
>  


      reply	other threads:[~2023-04-20 23:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  0:59 [PATCH] suniv: fix dramc autofresh freq calculation issue John Sanpe
2023-04-20 23:41 ` Andre Przywara [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230421004117.014e471b@slackpad.lan \
    --to=andre.przywara@arm.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=sanpeqf@gmail.com \
    --cc=u-boot@lists.denx.de \
    --cc=uwu@icenowy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox