On Thu, Dec 5, 2019 at 11:13 PM Dan Handley Dan.Handley@arm.com wrote:
Hi Sandeep
(I accidentally dropped the TF-A list in my last reply - now re-adding).
-----Original Message----- From: Sandeep Tripathy sandeep.tripathy@broadcom.com Sent: 05 December 2019 17:17
On Thu, Dec 5, 2019 at 9:54 PM Dan Handley Dan.Handley@arm.com wrote:
Hi Sandeep
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Sandeep Tripathy via TF-A Sent: 05 December 2019 12:00
My query is more on the spec. The OS (eg: linux) and atf and psci spec seem to have assumed that it is managing an independent system or managing 'all' the masters in a coherent domain. What other reason could possibly encourage to not to follow a shutdown sequence.
Do you mean "to not follow a *graceful* shutdown sequence"?
Yes, exactly. Thanks!
If so I can think of 3 reasons:
- It's much slower than a non-graceful shutdown.
But this is certainly not a concern for smaller embedded systems.
True, but TF-A tries to be a reference for all systems.
- There is no observable difference between a graceful and non-graceful
shutdown from the calling OS's point of view. The OS presumably has no knowledge of other masters it does not manage.
Can CCN state machine go bad because one participating entity just goes off without marking its exit ? Please note I have not seen the issue and it is my assumption.
It depends on the interconnect. Arm interconnects designed for pre-v8.2 systems required explicit programming to take the master our of the coherency domain. Arm interconnects for v8.2+ systems do this automatically via hardware system coherency signals. The TF-A off/reset platform interfaces have provision to do this programming if necessary, but only for the running cluster, which is another reason not to use these PSCI functions in this scenario.
we use the reset/reset2/ platform interface for the coherency exit. I thought there might be some dependency on a proper core and cluster power down sequence like clearing smp bit flushing the local caches. And it did not seem wrong to do so. Though it does assume at leaf level that other cores have done their bit. Not sure which is the right place to handle that. If it is firmware, it is complex.
- It's hard for firmware to implement in the multicore situation.
Agree. It is complex to initiate and ensure 'other cores' power down in firmware.
I haven't yet seen a reason why SYSTEM_SUSPEND won't work instead.
I think you are suggesting to use psci system suspend hook in reboot /power off path Or use system suspend from the OS itself ? Should work.
I'm suggesting to just do a normal SYSTEM_SUSPEND (suspend to RAM) from the OS.
@Sudeep, I agree alternate approaches to solve data loss problem works and may be those are the best suited. The past thread[1] is somewhat related but diverged in multiple directions. I wanted to know and focus the above 3 points especially point 2.
Regards
Dan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.