Hi, Thanks for the response.
> The pre-defined locations are needed because not every registers needs to > be saved. For example in GIC, pending. Clear, Set sets of register are > pretty much same with inverted logic and can be easily decoded without > saving all of them but just one type of it. Hence the Save layout Interesting. Why the optimization though - is the intent to save time or context space? Every cycle may count, but our investigations lead us to believe that the time for any shutdown is dominated by cache (L1) clean times. > Hence the Save layout > is not linear on OMAP4 and restore is handled in by Secure CODE which > is fixed for a SOC Fair enough, but this is an OMAP4 implementation choice, not a general statement about SoCs. (Correct me if I'm wrong.) > Yes... Again I am not saying that you can't have generic code > doing that.It's doable but it will end up with some SOC specific execeptions. Understood. -Bobby > -----Original Message----- > From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] > Sent: 18 October 2010 06:19 > To: Bobby Batacharia; Jon Callan; linaro-dev@lists.linaro.org > Subject: RE: Common ARM context save/restore code > > Bobby, > > -----Original Message----- > > From: Bobby Batacharia [mailto:bobby.batacha...@arm.com] > > Sent: Sunday, October 17, 2010 4:08 AM > > To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org > > Subject: RE: Common ARM context save/restore code > > > > Santosh, > > > > Again - apologies for the tardy responses to this thread. > > > > > This is something very different from SOC point of view. > > > Example OMAP4, the restore for GIC, SCU, L2 is handled by ROM > > > code and it expect it to save in a particular pattern and > > > pre-defined memory location. Generic code won't work here. > > > > Understood, and Jon's code certainly doesn't preclude such > an approach. > > > > Small point, but I'm not sure I buy the part about > pre-defined memory > > locations: that will be a parameter into the generic code. > I do agree SoC > > specific code provides the context pointer regardless of > where the restore > > happens. The approach we're working on is also intended to respect > > multiple CPU and SoC level TrustZone scenarios: there will > clearly be SoC > > and CPU state that can't be Saved/Restored by the OS. (The > bulk of that > > non-OS code may or may not be in ROM, depends on the SoC.) > > > The pre-defined locations are needed because not every registers needs to > be saved. For example in GIC, pending. Clear, Set sets of register are > pretty much same with inverted logic and can be easily decoded without > saving all of them but just one type of it. Hence the Save layout > is not linear on OMAP4 and restore is handled in by Secure CODE which > is fixed for a SOC > > > Out of interest, in the OMAP4 implementation, when a single core is > > powered down (but Fabric/DMC, cluster, and potentially > another CPU stays > > up), does that core end up calling into non-OS code to save > and restore > > its state? > > > Yes... Again I am not saying that you can't have generic code > doing that. > It's doable but it will end up with some SOC specific execeptions. > > > > Having said that, would be good to see your patches. > > > > Certainly interested in your comments when we make it > public. (I know, I > > know .. soon!) > > > Ok > -- 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. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
