From: Peter Rosin <peda@axentia.se>
To: Nicolas Ferre <nicolas.ferre@atmel.com>,
Peter Rosin <peda@lysator.liu.se>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Yang, Wenyou" <Wenyou.Yang@atmel.com>
Cc: Andrew Victor <linux@maxim.org.za>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Russell King <linux@arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Alexandre Belloni" <alexandre.belloni@free-electrons.com>,
Boris BREZILLON <boris.brezillon@free-electrons.com>
Subject: RE: [PATCH RESEND] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories
Date: Wed, 14 Jan 2015 21:33:21 +0000 [thread overview]
Message-ID: <018060d2585f4e5480b1bdd39a56e70c@EMAIL.axentia.se> (raw)
In-Reply-To: <54B69DAB.8010303@atmel.com>
Nicolas Ferre wrote:
> Le 14/01/2015 14:20, Peter Rosin a écrit :
> > From: Peter Rosin <peda@axentia.se>
> >
> > The DDRSDR controller (on the ATSAMA5D31) fails miserably to put
> > LPDDR1 memories in self-refresh. Force the controller to think it has
> > DDR2 memories during the self-refresh period, as the DDR2 self-refresh
> > spec is equivalent to LPDDR1, and is correctly implemented in the
> controller.
> >
> > Assume that the second controller has the same fault, and that other
> > CPUs in the family has the same problem, but that is untested.
> >
> > Signed-off-by: Peter Rosin <peda@axentia.se>
>
> I've just verified your code and the scope of this issue and your
> implementation makes perfect sense.
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Peter,
> Thanks for your patch. You will probably see it appearing in 3.20 or 3.21.
Great!
> Wenyou,
> Can you please integrate the patch from Peter in your current rework of the
> PM routines (keeping his authorship of course)?
> Please tell me if I can help with this.
To be 100% honest with credits, I should perhaps have mentioned that I
received an unconditional proof-of-concept patch from Atmel support
(Case 00007347). I'm not certain who wrote that patch, but the only thing
that has survived is the idea to temporarily use DDR2 mode and the trivial
change of the register field width in the header file. So, I do not feel too
dishonest by claiming authorship...
Cheers,
Peter
next prev parent reply other threads:[~2015-01-14 21:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 13:20 Peter Rosin
2015-01-14 16:47 ` Nicolas Ferre
2015-01-14 21:33 ` Peter Rosin [this message]
2015-01-15 5:54 ` Yang, Wenyou
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=018060d2585f4e5480b1bdd39a56e70c@EMAIL.axentia.se \
--to=peda@axentia.se \
--cc=Wenyou.Yang@atmel.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linux@maxim.org.za \
--cc=nicolas.ferre@atmel.com \
--cc=peda@lysator.liu.se \
--cc=plagnioj@jcrosoft.com \
/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
all inboxes | Powered by JetHome®