All of lore.kernel.org
 help / color / mirror / Atom feed
From: sylvain.rochet@finsecur.com (Sylvain Rochet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/12] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
Date: Sun, 25 Jan 2015 14:30:24 +0100	[thread overview]
Message-ID: <20150125133024.GA27125@gradator.net> (raw)
In-Reply-To: <20150123231738.GB32318@piout.net>

Hello Alexandre,


On Sat, Jan 24, 2015 at 12:17:38AM +0100, Alexandre Belloni wrote:
> 
> This is a rework, what is part of linux-3.10-at91 and not yet present in
> mainline should be part of a following series. I would prefer not mixing
> reworks and "new" functionalities (they have been present in the atmel
> tree for a while but never mainlined).

I agree, I just didn't know a new series will follow, maybe I missed 
this point.

Maybe I am a bit too picky (or boring: if I am, please told me), but 
this series by itself adds regression to all users of >= 9x5 boards 
(sama5, ?) because it merges MEM target and MEM+SLOW_CLOCK target, which 
used to be too different target states, not selectable at runtime indeed 
but this is still in practice two different target states. Note that I 
am not saying that MEM target and MEM+SLOW_CLOCK target should not be 
merged, they should, absolutely ;-). For >= 9x5 boards (sama5, ?), MEM 
target works and MEM+SLOW_CLOCK target does not work, MEM and 
MEM+SLOW_CLOCK merge breaks MEM target for those boards.

There is however a good news !, at91_pm_verify_clocks() used to be 
called for MEM target without considering if it was MEM (~STANDBY) or 
MEM+SLOW_CLOCK. It means that all MEM target users can with very good 
chance go to a deeper sleep state without issue because 
at91_pm_verify_clocks() successfully checked on those boards and is why 
we can merge MEM and MEM+SLOW_CLOCK without adding a regression.

Care should be taken to pull-request at the same time both the rework 
and the above cited following series about slow clock support for all 
known boards so we don't break MEM target for a release cycle.


> I would say that PM on 9x5, n12 and sama5 in mainline is clearly not 
> well tested and is lagging behind the atmel tree.

Well, at the current mainline state, everything works fine for me except 
slow clock mode, I thoroughly checked everything else.


Sylvain

WARNING: multiple messages have this Message-ID (diff)
From: Sylvain Rochet <sylvain.rochet@finsecur.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Wenyou Yang <wenyou.yang@atmel.com>,
	nicolas.ferre@atmel.com, linux@arm.linux.org.uk,
	linux-kernel@vger.kernel.org, peda@axentia.se,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 08/12] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
Date: Sun, 25 Jan 2015 14:30:24 +0100	[thread overview]
Message-ID: <20150125133024.GA27125@gradator.net> (raw)
In-Reply-To: <20150123231738.GB32318@piout.net>

Hello Alexandre,


On Sat, Jan 24, 2015 at 12:17:38AM +0100, Alexandre Belloni wrote:
> 
> This is a rework, what is part of linux-3.10-at91 and not yet present in
> mainline should be part of a following series. I would prefer not mixing
> reworks and "new" functionalities (they have been present in the atmel
> tree for a while but never mainlined).

I agree, I just didn't know a new series will follow, maybe I missed 
this point.

Maybe I am a bit too picky (or boring: if I am, please told me), but 
this series by itself adds regression to all users of >= 9x5 boards 
(sama5, …) because it merges MEM target and MEM+SLOW_CLOCK target, which 
used to be too different target states, not selectable at runtime indeed 
but this is still in practice two different target states. Note that I 
am not saying that MEM target and MEM+SLOW_CLOCK target should not be 
merged, they should, absolutely ;-). For >= 9x5 boards (sama5, …), MEM 
target works and MEM+SLOW_CLOCK target does not work, MEM and 
MEM+SLOW_CLOCK merge breaks MEM target for those boards.

There is however a good news !, at91_pm_verify_clocks() used to be 
called for MEM target without considering if it was MEM (~STANDBY) or 
MEM+SLOW_CLOCK. It means that all MEM target users can with very good 
chance go to a deeper sleep state without issue because 
at91_pm_verify_clocks() successfully checked on those boards and is why 
we can merge MEM and MEM+SLOW_CLOCK without adding a regression.

Care should be taken to pull-request at the same time both the rework 
and the above cited following series about slow clock support for all 
known boards so we don't break MEM target for a release cycle.


> I would say that PM on 9x5, n12 and sama5 in mainline is clearly not 
> well tested and is lagging behind the atmel tree.

Well, at the current mainline state, everything works fine for me except 
slow clock mode, I thoroughly checked everything else.


Sylvain

  reply	other threads:[~2015-01-25 13:30 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20  8:16 [PATCH 00/12] AT91 pm cleanup for 3.20 Wenyou Yang
2015-01-20  8:16 ` Wenyou Yang
2015-01-20  8:16 ` [PATCH 01/12] pm: at91: pm_slowclock: improve reliability of suspend/resume Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-20  8:16 ` [PATCH 02/12] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-20  8:16 ` [PATCH 03/12] pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-20  8:16 ` [PATCH 04/12] pm: at91: move the copying the sram function to the sram initializationi phase Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-20  8:16 ` [PATCH 05/12] ARM: at91: move select SRAM to ARCH_AT91 Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-23 10:24   ` Alexandre Belloni
2015-01-23 10:24     ` Alexandre Belloni
2015-01-26  1:10     ` Yang, Wenyou
2015-01-26  1:10       ` Yang, Wenyou
2015-01-20  8:16 ` [PATCH 06/12] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK Wenyou Yang
2015-01-20  8:16   ` Wenyou Yang
2015-01-20  8:17 ` [PATCH 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode Wenyou Yang
2015-01-20  8:17   ` Wenyou Yang
2015-01-23 10:30   ` Alexandre Belloni
2015-01-23 10:30     ` Alexandre Belloni
2015-01-23 16:50   ` Sylvain Rochet
2015-01-23 16:50     ` Sylvain Rochet
2015-01-23 23:13     ` Alexandre Belloni
2015-01-23 23:13       ` Alexandre Belloni
2015-01-27  3:08       ` Yang, Wenyou
2015-01-27  3:08         ` Yang, Wenyou
2015-01-23 17:32   ` Sylvain Rochet
2015-01-23 17:32     ` Sylvain Rochet
2015-01-23 23:02     ` Alexandre Belloni
2015-01-23 23:02       ` Alexandre Belloni
2015-01-26  3:08       ` Yang, Wenyou
2015-01-26  3:08         ` Yang, Wenyou
2015-01-26  3:06     ` Yang, Wenyou
2015-01-26  3:06       ` Yang, Wenyou
2015-01-20  8:17 ` [PATCH 08/12] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S Wenyou Yang
2015-01-20  8:17   ` Wenyou Yang
2015-01-23 19:17   ` Sylvain Rochet
2015-01-23 19:17     ` Sylvain Rochet
2015-01-23 23:17     ` Alexandre Belloni
2015-01-23 23:17       ` Alexandre Belloni
2015-01-25 13:30       ` Sylvain Rochet [this message]
2015-01-25 13:30         ` Sylvain Rochet
2015-01-26  1:25     ` Yang, Wenyou
2015-01-26  1:25       ` Yang, Wenyou
2015-01-20  8:17 ` [PATCH 09/12] pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn Wenyou Yang
2015-01-20  8:17   ` Wenyou Yang
2015-01-20  8:24 ` Wenyou Yang
2015-01-20  8:24   ` Wenyou Yang
2015-01-20  8:24 ` [PATCH 10/12] pm: at91: remove the at91_xxx_standby() function definitions in the pm.h Wenyou Yang
2015-01-20  8:24   ` Wenyou Yang
2015-01-20  8:25 ` [PATCH 11/12] pm: at91: remove the struct ramc_ids .data at91_xxx_standby members Wenyou Yang
2015-01-20  8:25   ` Wenyou Yang
2015-01-20  8:26 ` [PATCH 12/12] pm: at91: amend the pm_suspend entry for at91_cpuidle_device Wenyou Yang
2015-01-20  8:26   ` Wenyou Yang

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=20150125133024.GA27125@gradator.net \
    --to=sylvain.rochet@finsecur.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 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.