This patchset fixes a couple of issues encountered in the suspend/resume code
base. First when using the kernel device tree update code update-nodes is
unnecessarily called more than once. Second the cpu cache lists are not
updated after a suspend/resume which under certain conditions may cause a
panic. Finally, since the cache list fix utilzes in kernel device tree update
code a means for telling drmgr not to perform a device tree update from
userspace is required.
Changes from v2:
- Moved dynamic configuration update code into pseries specific routine
per Nathan's suggestion.
Changes from v1:
- Fixed several commit message typos
- Fixed authorship of first two patches
Haren Myneni (2):
powerpc/pseries: Device tree should only be updated once after
suspend/migrate
powerpc/pseries: Update dynamic cache nodes for suspend/resume
operation
Tyrel Datwyler (1):
powerpc/pseries: Report in kernel device tree update to drmgr
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/platforms/pseries/mobility.c | 26 +++++++-----------
arch/powerpc/platforms/pseries/suspend.c | 44 ++++++++++++++++++++++++++++++-
3 files changed, 54 insertions(+), 17 deletions(-)
--
1.7.12.2
From: Haren Myneni <redacted>
The current code makes rtas calls for update-nodes, activate-firmware and then
update-nodes again. The FW provides the same data for both update-nodes calls.
As a result a proc entry exists error is reported for the second update while
adding device nodes.
This patch makes a single rtas call for update-nodes after activating the FW.
It also add rtas_busy delay for the activate-firmware rtas call.
Signed-off-by: Haren Myneni <redacted>
Signed-off-by: Tyrel Datwyler <redacted>
---
arch/powerpc/platforms/pseries/mobility.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
From: Haren Myneni <redacted>
pHyp can change cache nodes for suspend/resume operation. The current code
updates the device tree after all non boot CPUs are enabled. Hence, we do not
modify the cache list based on the latest cache nodes. Also we do not remove
cache entries for the primary CPU.
This patch removes the cache list for the boot CPU, updates the device tree
before enabling nonboot CPUs and adds cache list for the boot cpu.
Signed-off-by: Haren Myneni <redacted>
Signed-off-by: Tyrel Datwyler <redacted>
---
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/platforms/pseries/suspend.c | 19 +++++++++++++++++++
2 files changed, 20 insertions(+)
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel during the resume. Therefore, a mechanism is required
for drmgr to determine who is responsible for the update. This patch adds a
show function to the "hibernate" attribute that returns 1 if the kernel
updates the device tree after the resume and 0 if drmgr is responsible.
Signed-off-by: Tyrel Datwyler <redacted>
---
arch/powerpc/platforms/pseries/suspend.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
This patchset fixes a couple of issues encountered in the suspend/resume code
base. First when using the kernel device tree update code update-nodes is
unnecessarily called more than once. Second the cpu cache lists are not
updated after a suspend/resume which under certain conditions may cause a
panic. Finally, since the cache list fix utilzes in kernel device tree update
code a means for telling drmgr not to perform a device tree update from
userspace is required.
Changes from v2:
- Moved dynamic configuration update code into pseries specific routine
per Nathan's suggestion.
Changes from v1:
- Fixed several commit message typos
- Fixed authorship of first two patches
Haren Myneni (2):
powerpc/pseries: Device tree should only be updated once after
suspend/migrate
powerpc/pseries: Update dynamic cache nodes for suspend/resume
operation
Tyrel Datwyler (1):
powerpc/pseries: Report in kernel device tree update to drmgr
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/platforms/pseries/mobility.c | 26 +++++++-----------
arch/powerpc/platforms/pseries/suspend.c | 44 ++++++++++++++++++++++++++++++-
3 files changed, 54 insertions(+), 17 deletions(-)
Ping?
Nathan, can I at least get your ack on this v3 patchset. We really need
to get these upstream.
-Tyrel
From: Benjamin Herrenschmidt <hidden> Date: 2014-02-17 00:22:51
On Fri, 2014-01-31 at 15:58 -0800, Tyrel Datwyler wrote:
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel during the resume. Therefore, a mechanism is required
for drmgr to determine who is responsible for the update. This patch adds a
show function to the "hibernate" attribute that returns 1 if the kernel
updates the device tree after the resume and 0 if drmgr is responsible.
This is not right.
We cannot change the kernel behaviour in a way that is incompatible with
existing userspace, and unless you can explain me why that is not the
case, it feels like this patch set does just that ....
What happens if you have an older drmgr which still does the update
itself ?
You can't just change user visible behaviours and interface without at
least explaining why it's ok to do so at the very least (and ensuring
that of course) without breaking existing userspace.
Now it's possible that the double update caused by this series is
harmless, in which case please explain it in the changeset, I certainly
can't assume it and if it's not, you'll need some other way for drmgr to
signal the kernel to indicate it supports the new behaviour before you
enable it.
Ben.
On 02/16/2014 04:22 PM, Benjamin Herrenschmidt wrote:
On Fri, 2014-01-31 at 15:58 -0800, Tyrel Datwyler wrote:
quoted
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel during the resume. Therefore, a mechanism is required
for drmgr to determine who is responsible for the update. This patch adds a
show function to the "hibernate" attribute that returns 1 if the kernel
updates the device tree after the resume and 0 if drmgr is responsible.
This is not right.
We cannot change the kernel behaviour in a way that is incompatible with
existing userspace, and unless you can explain me why that is not the
case, it feels like this patch set does just that ....
What happens if you have an older drmgr which still does the update
itself ?
In this case we get a double update which I clearly neglected to mention
in the patch. The first patch in this series actually removes an
unnecessary double update from the existing kernel implementation. The
same information is returned by the update-nodes/properties call the
second time around and aside from being a waste of a few cycles is harmless.
Tyrel
You can't just change user visible behaviours and interface without at
least explaining why it's ok to do so at the very least (and ensuring
that of course) without breaking existing userspace.
Now it's possible that the double update caused by this series is
harmless, in which case please explain it in the changeset, I certainly
can't assume it and if it's not, you'll need some other way for drmgr to
signal the kernel to indicate it supports the new behaviour before you
enable it.
Ben.
From: Benjamin Herrenschmidt <hidden> Date: 2014-02-18 23:47:26
On Tue, 2014-02-18 at 15:28 -0800, Tyrel Datwyler wrote:
In this case we get a double update which I clearly neglected to
mention
in the patch. The first patch in this series actually removes an
unnecessary double update from the existing kernel implementation. The
same information is returned by the update-nodes/properties call the
second time around and aside from being a waste of a few cycles is
harmless.
Thanks. Can you resend the patches with updated descriptions ? I will
try to send them to Linus by end of week.
Cheers,
Ben.