From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Boris BREZILLON <boris.brezillon@free-electrons.com>,
Lior Amsalem <alior@marvell.com>,
Tawfik Bayouk <tawfik@marvell.com>,
Nadav Haklai <nadavh@marvell.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] ARM: mvebu: Add standby support
Date: Fri, 03 Jul 2015 14:21:09 +0200 [thread overview]
Message-ID: <55967E35.8050002@free-electrons.com> (raw)
In-Reply-To: <20150703141716.785a27c5@free-electrons.com>
Hi Thomas,
On 03/07/2015 14:17, Thomas Petazzoni wrote:
> Gregory,
>
> On Fri, 03 Jul 2015 13:39:49 +0200, Gregory CLEMENT wrote:
>
>> Having 2 initcall does not work because, there is a dependency between these
>> 2 calls. And actually the suspend_ops is registered before the board specific
>> hook. As soon as the suspend_ops is registered, mvebu_pm_valid() is called but
>> at this point mvebu_board_pm_enter is NULL so PM_SUSPEND_MEM is not available.
>
> And? It will become available soon afterwards.
No it is called during boot and if the method is not there then it is no
more available for the user. I made te test and with a cat on /sys/power/state
I only got "freeze" and "standby" but not "mem".
Thanks,
Gregory
>
>> All the complexity of the original patch was to allow registering a handler
>> without needed to get the resource(gpio device) that are not available when using
>> arch_initcall(). However the device_initcall_sync comes latter enough to
>> get all the devices registered but it still happens before the late_initcall,
>> so I will use this one and I will add a comment around it.
>
> I don't think we care about the order in which the initcalls are called.
>
> If the SoC level init call registering the suspend_ops gets called
> first, then at the beginning there is only support for standby. The
> support for suspend to RAM will be enabled once the board-level init
> call gets called.
>
> If the board level init call is called first, then it will set
> mvebu_board_pm_enter. It is not useful at this point. Until the SoC
> level init call registers the suspend_ops.
>
> I believe that the ->valid() method of suspend_ops gets called when the
> user actually enters the suspend state by writing to /sys/power/state.
> And by that time, both init calls will have been called.
>
> Best regards,
>
> Thomas
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/4] ARM: mvebu: Add standby support
Date: Fri, 03 Jul 2015 14:21:09 +0200 [thread overview]
Message-ID: <55967E35.8050002@free-electrons.com> (raw)
In-Reply-To: <20150703141716.785a27c5@free-electrons.com>
Hi Thomas,
On 03/07/2015 14:17, Thomas Petazzoni wrote:
> Gregory,
>
> On Fri, 03 Jul 2015 13:39:49 +0200, Gregory CLEMENT wrote:
>
>> Having 2 initcall does not work because, there is a dependency between these
>> 2 calls. And actually the suspend_ops is registered before the board specific
>> hook. As soon as the suspend_ops is registered, mvebu_pm_valid() is called but
>> at this point mvebu_board_pm_enter is NULL so PM_SUSPEND_MEM is not available.
>
> And? It will become available soon afterwards.
No it is called during boot and if the method is not there then it is no
more available for the user. I made te test and with a cat on /sys/power/state
I only got "freeze" and "standby" but not "mem".
Thanks,
Gregory
>
>> All the complexity of the original patch was to allow registering a handler
>> without needed to get the resource(gpio device) that are not available when using
>> arch_initcall(). However the device_initcall_sync comes latter enough to
>> get all the devices registered but it still happens before the late_initcall,
>> so I will use this one and I will add a comment around it.
>
> I don't think we care about the order in which the initcalls are called.
>
> If the SoC level init call registering the suspend_ops gets called
> first, then at the beginning there is only support for standby. The
> support for suspend to RAM will be enabled once the board-level init
> call gets called.
>
> If the board level init call is called first, then it will set
> mvebu_board_pm_enter. It is not useful at this point. Until the SoC
> level init call registers the suspend_ops.
>
> I believe that the ->valid() method of suspend_ops gets called when the
> user actually enters the suspend state by writing to /sys/power/state.
> And by that time, both init calls will have been called.
>
> Best regards,
>
> Thomas
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2015-07-03 12:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 17:18 [PATCH v2 0/4] Add standby support for the recent mvebu SoCs Gregory CLEMENT
2015-06-30 17:18 ` Gregory CLEMENT
2015-06-30 17:18 ` [PATCH v2 1/4] ARM: mvebu: Use __init for the PM initialization functions Gregory CLEMENT
2015-06-30 17:18 ` Gregory CLEMENT
2015-06-30 17:18 ` Gregory CLEMENT
2015-07-01 15:18 ` Thomas Petazzoni
2015-07-01 15:18 ` Thomas Petazzoni
2015-06-30 17:18 ` [PATCH v2 2/4] ARM: mvebu: Add standby support Gregory CLEMENT
2015-06-30 17:18 ` Gregory CLEMENT
2015-07-01 15:47 ` Thomas Petazzoni
2015-07-01 15:47 ` Thomas Petazzoni
2015-07-03 11:39 ` Gregory CLEMENT
2015-07-03 11:39 ` Gregory CLEMENT
2015-07-03 12:17 ` Thomas Petazzoni
2015-07-03 12:17 ` Thomas Petazzoni
2015-07-03 12:21 ` Gregory CLEMENT [this message]
2015-07-03 12:21 ` Gregory CLEMENT
2015-07-03 12:33 ` Thomas Petazzoni
2015-07-03 12:33 ` Thomas Petazzoni
2015-06-30 17:18 ` [PATCH v2 3/4] ARM: mvebu: Allow using the GIC for wakeup in standby mode Gregory CLEMENT
2015-06-30 17:18 ` Gregory CLEMENT
2015-07-01 15:54 ` Thomas Petazzoni
2015-07-01 15:54 ` Thomas Petazzoni
2015-07-03 7:18 ` Gregory CLEMENT
2015-07-03 7:18 ` Gregory CLEMENT
2015-07-27 11:02 ` Sudeep Holla
2015-07-27 11:02 ` Sudeep Holla
2015-07-28 9:42 ` Gregory CLEMENT
2015-07-28 9:42 ` Gregory CLEMENT
2015-07-01 16:05 ` Sudeep Holla
2015-07-01 16:05 ` Sudeep Holla
2015-07-01 16:56 ` Geert Uytterhoeven
2015-07-01 16:56 ` Geert Uytterhoeven
2015-06-30 17:19 ` [PATCH v2 4/4] ARM: mvebu: Warn about the wake-up sources not taken into account in suspend Gregory CLEMENT
2015-06-30 17:19 ` Gregory CLEMENT
2015-07-01 16:04 ` Thomas Petazzoni
2015-07-01 16:04 ` Thomas Petazzoni
2015-07-03 9:55 ` Gregory CLEMENT
2015-07-03 9:55 ` Gregory CLEMENT
2015-07-25 15:20 ` [PATCH v2 0/4] Add standby support for the recent mvebu SoCs Gregory CLEMENT
2015-07-25 15:20 ` Gregory CLEMENT
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=55967E35.8050002@free-electrons.com \
--to=gregory.clement@free-electrons.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=boris.brezillon@free-electrons.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=nadavh@marvell.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.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.