From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pxa2xx/cpufreq: Fix DRI computation
Date: Tue, 8 Jun 2010 21:36:30 +0200 [thread overview]
Message-ID: <201006082136.30785.marek.vasut@gmail.com> (raw)
In-Reply-To: <87ljap7opx.fsf@free.fr>
Dne ?t 8. ?ervna 2010 13:23:06 Robert Jarzmik napsal(a):
> Marek Vasut <marek.vasut@gmail.com> writes:
> > The DRI field was incorrectly computed, causing various hangs and weird
> > behaviour on PXA2xx machines. This patch introduces the DRI computation
> > according to the PXA255 (January 2004) and PXA270 (MV-S301039-00 Rev. A)
> > datasheets.
> >
> > NOTE: The CPU type is checked only once, so the code is a little bit
> > faster now.
> >
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > ---
> >
> > arch/arm/mach-pxa/cpufreq-pxa2xx.c | 33
> > +++++++++++++++++++++++++++++---- 1 files changed, 29 insertions(+), 4
> > deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> > b/arch/arm/mach-pxa/cpufreq-pxa2xx.c index 9e4d981..5373db0 100644
> > --- a/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> > +++ b/arch/arm/mach-pxa/cpufreq-pxa2xx.c
> > @@ -251,17 +251,42 @@ static void init_sdram_rows(void)
> >
> > if (mdcnfg & (MDCNFG_DE0 | MDCNFG_DE1))
> >
> > drac0 = MDCNFG_DRAC0(mdcnfg);
> >
> > - sdram_rows = 1 << (11 + max(drac0, drac2));
> > + sdram_rows = 11 + max(drac0, drac2);
>
> I don't think that's correct.
> From DRACn, you learn that SDRAM row is selected from 11+DRACn bits. That
> means that if drac == 2, then the SDRAM row is a number between 0 and
> (11+drac0) - 1. That in turn means that the number of SDRAM rows is : 2 ^
> (11 + drac0). Example:
> - drac0 = 2 : row encoded on 13 bits => 2^13 rows (ie. 1 << (11 + 2)).
That I'm aware of, but are you sure the TRM means it that way ?
>
> > static u32 mdrefr_dri(unsigned int freq)
> > {
> >
> > u32 dri = 0;
> >
> > - if (cpu_is_pxa25x())
> > - dri = ((freq * SDRAM_TREF) / (sdram_rows * 32));
> > + /*
> > + * PXA255 (6.5.3):
> > + * DRI = (Refresh time / rows * memory clock frequency) / 32
> > + * PXA270 (Table 91):
> > + * DRI = (Refresh time / rows * memory clock frequency - 31) / 32
> > + *
> > + * Memory clock frequency is in MHz here! (Refresh time is in ms).
> > + */
>
> I don't agree here either. The "freq" variable is in kHz.
That's concerning the TRM, not the freq value. In TRM, it's in MHz.
> It comes from
> "new_freq_mem = pxa_freq_settings[idx].membus;" in pxa_set_target(). The
> membus value is in kHz, as in tables pxaXXX_freqs (see 104000 and 208000,
> second column in pxa27x_freqs for example). As refresh time is in ms,
> there is no need for a 1000th multiplier.
>
> And my understanding is that the legacy formula is incorrect, as you
> discovered it. Yet it should be, IMO :
> if (cpu_is_pxa27x())
> - dri = ((freq * SDRAM_TREF) / (sdram_rows - 31)) / 32;
> + dri = ((freq * SDRAM_TREF) / sdram_rows - 31) / 32;
>
> This is the only change to apply IMHO.
Ok, but still, even though I fixed it your way, it doesn't fix the real problem,
I'll recheck though, I just need a few days too.
Cheers
>
> Can you confirm my analysis ?
next prev parent reply other threads:[~2010-06-08 19:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-05 0:46 [PATCH] pxa2xx/cpufreq: Fix DRI computation Marek Vasut
2010-06-07 19:41 ` Robert Jarzmik
2010-06-07 21:20 ` Marek Vasut
2010-06-07 21:26 ` Marek Vasut
2010-06-08 11:23 ` Robert Jarzmik
2010-06-08 19:36 ` Marek Vasut [this message]
2010-06-09 13:59 ` Robert Jarzmik
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=201006082136.30785.marek.vasut@gmail.com \
--to=marek.vasut@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).