All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sylvain Rochet <sylvain.rochet@finsecur.com>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Peter Rosin <peda@axentia.se>,
	Wenyou Yang <wenyou.yang@atmel.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alexandre.belloni@free-electrons.com" 
	<alexandre.belloni@free-electrons.com>
Subject: Re: [PATCH v2 02/12] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
Date: Mon, 26 Jan 2015 17:11:24 +0100	[thread overview]
Message-ID: <20150126161124.GA24190@gradator.net> (raw)
In-Reply-To: <54C66589.3040505@atmel.com>

Hello Nicolas and Peter,

On Mon, Jan 26, 2015 at 05:04:25PM +0100, Nicolas Ferre wrote:
> Le 26/01/2015 16:58, Peter Rosin a écrit :
> > Sylvain Rochet wrote:
> >> Hello Nicolas,
> >>
> >> On Mon, Jan 26, 2015 at 02:34:38PM +0100, Nicolas Ferre wrote:
> >>> Le 26/01/2015 11:36, Sylvain Rochet a écrit :
> >>>>
> >>>> I think we should explain we are dealing with an errata here, this
> >>>> is not obvious at first sight, the patch summary may find its place
> >>>> here :-)
> >>>
> >>> True but the problem is that this errata is not public yet, it will be
> >>> in a couple of weeks.
> >>>
> >>> I have the feeling though that the commit message is pretty clear.
> >>> We'll maybe add that it"s an actual errata.
> >>
> >> Humm, this is not what I meant actually. I only proposed a code source
> >> comment explaining why this is done this way, the current patch summary
> >> looked like it will be perfect between /* */ ;-)
> > 
> > I did not want to fill up the source with wordy comments, and settled
> > for a one-liner. I don't know much about the underlying reasons other
> > than the fact that LPDDR1 mode of the controller isn't working properly
> > in self-refresh and that the DDR2 spec is similar enough to work.
> > 
> > The one-liner comment says about the same thing, but not with so
> > many words. The comment does make it clear that the switch to DDR2
> > is intentional, and that is all that is needed as protection from some
> > future cleanup. I mean, anyone seeing that comment and just erasing
> > the whole thing without further investigation is not doing a very good
> > job as there is no reason to intentionally switch from LPDDR1 mode to
> > DDR2 mode, other that the fact that the LPDDR1 mode isn't working for
> > some reason. That reason is not to be found in the commit message
> > and I have no information to improve the situation. IMO, the only thing
> > missing is a pointer to the as yet unreleased errata, which should explain
> > the situation clearly for any and all interested parties. May I suggest that
> > someone who cares sends a patch with the comment update when the
> > errata is released?
> 
> That's the option that I'll take.
> 
> Let's go for it (and anyone remind me if I don't when the errata is
> released).

I fully agree with that, a pointer to a datasheet errata is exactly the 
same thing as explaining the issue.

Sylvain

WARNING: multiple messages have this Message-ID (diff)
From: sylvain.rochet@finsecur.com (Sylvain Rochet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 02/12] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
Date: Mon, 26 Jan 2015 17:11:24 +0100	[thread overview]
Message-ID: <20150126161124.GA24190@gradator.net> (raw)
In-Reply-To: <54C66589.3040505@atmel.com>

Hello Nicolas and Peter,

On Mon, Jan 26, 2015 at 05:04:25PM +0100, Nicolas Ferre wrote:
> Le 26/01/2015 16:58, Peter Rosin a ?crit :
> > Sylvain Rochet wrote:
> >> Hello Nicolas,
> >>
> >> On Mon, Jan 26, 2015 at 02:34:38PM +0100, Nicolas Ferre wrote:
> >>> Le 26/01/2015 11:36, Sylvain Rochet a ?crit :
> >>>>
> >>>> I think we should explain we are dealing with an errata here, this
> >>>> is not obvious at first sight, the patch summary may find its place
> >>>> here :-)
> >>>
> >>> True but the problem is that this errata is not public yet, it will be
> >>> in a couple of weeks.
> >>>
> >>> I have the feeling though that the commit message is pretty clear.
> >>> We'll maybe add that it"s an actual errata.
> >>
> >> Humm, this is not what I meant actually. I only proposed a code source
> >> comment explaining why this is done this way, the current patch summary
> >> looked like it will be perfect between /* */ ;-)
> > 
> > I did not want to fill up the source with wordy comments, and settled
> > for a one-liner. I don't know much about the underlying reasons other
> > than the fact that LPDDR1 mode of the controller isn't working properly
> > in self-refresh and that the DDR2 spec is similar enough to work.
> > 
> > The one-liner comment says about the same thing, but not with so
> > many words. The comment does make it clear that the switch to DDR2
> > is intentional, and that is all that is needed as protection from some
> > future cleanup. I mean, anyone seeing that comment and just erasing
> > the whole thing without further investigation is not doing a very good
> > job as there is no reason to intentionally switch from LPDDR1 mode to
> > DDR2 mode, other that the fact that the LPDDR1 mode isn't working for
> > some reason. That reason is not to be found in the commit message
> > and I have no information to improve the situation. IMO, the only thing
> > missing is a pointer to the as yet unreleased errata, which should explain
> > the situation clearly for any and all interested parties. May I suggest that
> > someone who cares sends a patch with the comment update when the
> > errata is released?
> 
> That's the option that I'll take.
> 
> Let's go for it (and anyone remind me if I don't when the errata is
> released).

I fully agree with that, a pointer to a datasheet errata is exactly the 
same thing as explaining the issue.

Sylvain

  reply	other threads:[~2015-01-26 16:11 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26  9:36 [PATCH v2 00/12] AT91 pm cleanup for 3.20 Wenyou Yang
2015-01-26  9:36 ` Wenyou Yang
2015-01-26  9:37 ` [PATCH v2 01/12] pm: at91: pm_slowclock: improve reliability of suspend/resume Wenyou Yang
2015-01-26  9:37   ` Wenyou Yang
2015-01-26 14:54   ` [PATCH v2 0/2] " Sylvain Rochet
2015-01-26 14:54     ` Sylvain Rochet
2015-01-26 14:54     ` [PATCH v2 1/2] pm: at91: pm_slowclock: fix suspend/resume hang up in timeouts Sylvain Rochet
2015-01-26 14:54       ` Sylvain Rochet
2015-01-26 14:54     ` [PATCH v2 2/2] pm: at91: pm_slowclock: remove clocks which are already stopped when entering slow clock mode Sylvain Rochet
2015-01-26 14:54       ` Sylvain Rochet
2015-01-26  9:38 ` [PATCH v2 02/12] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories Wenyou Yang
2015-01-26  9:38   ` Wenyou Yang
2015-01-26 10:36   ` Sylvain Rochet
2015-01-26 10:36     ` Sylvain Rochet
2015-01-26 13:34     ` Nicolas Ferre
2015-01-26 13:34       ` Nicolas Ferre
2015-01-26 13:44       ` Sylvain Rochet
2015-01-26 13:44         ` Sylvain Rochet
2015-01-26 15:58         ` Peter Rosin
2015-01-26 15:58           ` Peter Rosin
2015-01-26 16:04           ` Nicolas Ferre
2015-01-26 16:04             ` Nicolas Ferre
2015-01-26 16:11             ` Sylvain Rochet [this message]
2015-01-26 16:11               ` Sylvain Rochet
2015-01-26  9:39 ` [PATCH v2 03/12] pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK Wenyou Yang
2015-01-26  9:39   ` Wenyou Yang
2015-01-26  9:40 ` [PATCH v2 04/12] pm: at91: move the copying the sram function to the sram initializationi phase Wenyou Yang
2015-01-26  9:40   ` Wenyou Yang
2015-01-26 12:57   ` Sergei Shtylyov
2015-01-26 12:57     ` Sergei Shtylyov
2015-01-27  3:27     ` Yang, Wenyou
2015-01-27  3:27       ` Yang, Wenyou
2015-01-26  9:40 ` [PATCH v2 05/12] ARM: at91: move select SRAM to ARCH_AT91 Wenyou Yang
2015-01-26  9:40   ` Wenyou Yang
2015-01-26  9:41 ` [PATCH v2 06/12] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK Wenyou Yang
2015-01-26  9:41   ` Wenyou Yang
2015-01-26  9:42 ` [PATCH v2 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode Wenyou Yang
2015-01-26  9:42   ` Wenyou Yang
2015-01-26 10:09   ` Sylvain Rochet
2015-01-26 10:09     ` Sylvain Rochet
2015-01-27  4:44     ` Yang, Wenyou
2015-01-27  4:44       ` Yang, Wenyou
2015-01-26  9:42 ` [PATCH v2 08/12] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S Wenyou Yang
2015-01-26  9:42   ` Wenyou Yang
2015-01-26  9:43 ` [PATCH v2 09/12] pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn Wenyou Yang
2015-01-26  9:43   ` Wenyou Yang
2015-01-26  9:44 ` [PATCH v2 10/12] pm: at91: remove the at91_xxx_standby() function definitions in the pm.h Wenyou Yang
2015-01-26  9:44   ` Wenyou Yang
2015-01-26  9:45 ` [PATCH v2 11/12] pm: at91: setup: remove the struct ramc_ids .data at91_xxx_standby members Wenyou Yang
2015-01-26  9:45   ` Wenyou Yang
2015-01-26  9:45 ` [PATCH v2 12/12] pm: at91: amend the pm_suspend entry for at91_cpuidle_device Wenyou Yang
2015-01-26  9:45   ` Wenyou Yang
2015-01-26  9:55 ` [PATCH v2 00/12] AT91 pm cleanup for 3.20 Sylvain Rochet
2015-01-26  9:55   ` Sylvain Rochet
2015-01-27  2:58   ` Yang, Wenyou
2015-01-27  2:58     ` 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=20150126161124.GA24190@gradator.net \
    --to=sylvain.rochet@finsecur.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.ferre@atmel.com \
    --cc=peda@axentia.se \
    --cc=wenyou.yang@atmel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.