Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
Jon. -- I work Tue/Wed/Fri only Jon Callan, Staff Software Engineer, Processor Division ARM Cambridge / +44 1223 400814
-- 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.
Hi Jon,
That is a nice follow up to the OMAP idle code clean up, cf. http://lists.linaro.org/pipermail/linaro-dev/2010-October/001084.html. It would be nice to see how the code is organized and the impact of integrating it into the kernel.
Regards, Jean
On Tue, Oct 12, 2010 at 12:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
Jon.
I work Tue/Wed/Fri only Jon Callan, Staff Software Engineer, Processor Division ARM Cambridge / +44 1223 400814
-- 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
Jean,
Yes, it is basically doing the same stuff as the OMAP idle code, but in a more generic way. It is mostly C, with assembler helper functions.
I need to find out whether I can release the code.
Jon.
-----Original Message----- From: Jean Pihet [mailto:jean.pihet@newoldbits.com] Sent: 12 October 2010 11:48 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Hi Jon,
That is a nice follow up to the OMAP idle code clean up, cf. http://lists.linaro.org/pipermail/linaro-dev/2010-October/001084.html. It would be nice to see how the code is organized and the impact of integrating it into the kernel.
Regards, Jean
On Tue, Oct 12, 2010 at 12:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
Jon.
I work Tue/Wed/Fri only Jon Callan, Staff Software Engineer, Processor Division ARM Cambridge / +44 1223 400814
-- 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
-- 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.
Jon
-----Original Message----- From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev- bounces@lists.linaro.org] On Behalf Of Jon Callan Sent: Tuesday, October 12, 2010 4:10 PM To: linaro-dev@lists.linaro.org Subject: Common ARM context save/restore code
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
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.
VFP save/restore isn't needed because the generic code already takes care of it.
Infact on OMAP4 I need to save/restore only 14 CP15 registers (only needed ones) to get things working. Rest all is handles as mentioned using secure code.
Having said that, would be good to see your patches.
Regards, Santosh
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.)
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?
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!)
Thanks,
-Bobby
-----Original Message----- From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Shilimkar, Santosh Sent: 12 October 2010 12:03 To: Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
Jon
-----Original Message----- From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev- bounces@lists.linaro.org] On Behalf Of Jon Callan Sent: Tuesday, October 12, 2010 4:10 PM To: linaro-dev@lists.linaro.org Subject: Common ARM context save/restore code
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with
planned support
for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The
idea is the
kernel calls it from CPUidle, and it saves all CPU context
and cuts the power.
Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite
platform-specific.
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.
VFP save/restore isn't needed because the generic code already takes care of it.
Infact on OMAP4 I need to save/restore only 14 CP15 registers (only needed ones) to get things working. Rest all is handles as mentioned using secure code.
Having said that, would be good to see your patches.
Regards, Santosh
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- 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.
Bobby,
-----Original Message----- From: Bobby Batacharia [mailto:Bobby.Batacharia@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
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.shilimkar@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.Batacharia@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.
-----Original Message----- From: Bobby Batacharia [mailto:Bobby.Batacharia@arm.com] Sent: Monday, October 18, 2010 12:33 PM To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
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.
Space as well as time. Space is more important factor.
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. But other SOCs can implement such model as well.
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.
Space as well as time. Space is more important factor.
Got it. Presumably you're saving to on-chip SRAM, not DRAM, even for non-secure state.
Generic code should care about both space & time too, but in cases where there's a trade-off between the two there's very clearly a need for SoC specific code (or generic code configurability of some description).
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. But other SOCs can implement such model as well.
Absolutely. (.. and sorry my mail was imprecise: the comment above referred to non-linear layout, not the fact that there's fixed secure code.)
-Bobby
-----Original Message----- From: Shilimkar, Santosh [mailto:santosh.shilimkar@ti.com] Sent: 18 October 2010 08:09 To: Bobby Batacharia; Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
-----Original Message----- From: Bobby Batacharia [mailto:Bobby.Batacharia@arm.com] Sent: Monday, October 18, 2010 12:33 PM To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org Subject: RE: Common ARM context save/restore code
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.
Space as well as time. Space is more important factor.
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. But other SOCs can implement such model as well.
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.
-- 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.
All, this could be a good topic at Linaro@UDS... Dave
Sent from yet another ARM powered mobile device
On 18 Oct 2010, at 06:18, "Shilimkar, Santosh" santosh.shilimkar@ti.com wrote:
Bobby,
-----Original Message----- From: Bobby Batacharia [mailto:Bobby.Batacharia@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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
So you need to refactor these to an ARM-common driver and SoC-specific stubs?
/Amit
Well, my plan was to... er... post a message on linaro-dev and see happened!
And yes, refactor as an ARM-common driver + SoC-specific stubs, that sounds about right.
I plan to work on the Linux integration from 1st December. I have done some Linux kernel work before but I'm a little rusty.
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 12:04 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
So you need to refactor these to an ARM-common driver and SoC-specific stubs?
/Amit
-- 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.
:)
As you can see, if you make the source available somewhere, there is plenty of people interested in dissecting it.
Jon, if you start working on them in December, we'll almost certainly miss the 2.6.38 merge window to get it integrated to mainline.
/Amit p.s. /me makes a note to talk to Bobby@ARM et al. regarding this.
On 10 Oct 12, Jon Callan wrote:
Well, my plan was to... er... post a message on linaro-dev and see happened!
And yes, refactor as an ARM-common driver + SoC-specific stubs, that sounds about right.
I plan to work on the Linux integration from 1st December. I have done some Linux kernel work before but I'm a little rusty.
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 12:04 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
So you need to refactor these to an ARM-common driver and SoC-specific stubs?
/Amit
-- 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.
Amit,
Yes, it does seem a little tight doesn't it? Bobby is who I'm working with on this, btw.
Maybe I could get the source code tidied and open it up in 2-3 weeks time? Then we can all work on it together :-)
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 13:32 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
:)
As you can see, if you make the source available somewhere, there is plenty of people interested in dissecting it.
Jon, if you start working on them in December, we'll almost certainly miss the 2.6.38 merge window to get it integrated to mainline.
/Amit p.s. /me makes a note to talk to Bobby@ARM et al. regarding this.
On 10 Oct 12, Jon Callan wrote:
Well, my plan was to... er... post a message on linaro-dev and see happened!
And yes, refactor as an ARM-common driver + SoC-specific stubs, that sounds about right.
I plan to work on the Linux integration from 1st December. I have done some Linux kernel work before but I'm a little rusty.
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 12:04 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
So you need to refactor these to an ARM-common driver and SoC-specific stubs?
/Amit
-- 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.
-- 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.
Jon,
Yes, the earlier the better to starting incorporating the changes in Linux. Especially if you're interested in seeing this included in the kernel in 6 months time.
/Amit
On Tue, Oct 12, 2010 at 3:57 PM, Jon Callan Jon.Callan@arm.com wrote:
Amit,
Yes, it does seem a little tight doesn't it? Bobby is who I'm working with on this, btw.
Maybe I could get the source code tidied and open it up in 2-3 weeks time? Then we can all work on it together :-)
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 13:32 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
:)
As you can see, if you make the source available somewhere, there is plenty of people interested in dissecting it.
Jon, if you start working on them in December, we'll almost certainly miss the 2.6.38 merge window to get it integrated to mainline.
/Amit p.s. /me makes a note to talk to Bobby@ARM et al. regarding this.
On 10 Oct 12, Jon Callan wrote:
Well, my plan was to... er... post a message on linaro-dev and see happened!
And yes, refactor as an ARM-common driver + SoC-specific stubs, that sounds about right.
I plan to work on the Linux integration from 1st December. I have done some Linux kernel work before but I'm a little rusty.
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 12:04 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific code somehow.
So you need to refactor these to an ARM-common driver and SoC-specific stubs?
/Amit
-- 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.
-- 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.
Hi Amit,
Apologies for the delayed response.
Yes, the earlier the better to starting incorporating the changes in Linux.
Agreed - this is a priority for ARM. (We're at least a little behind the curve on putting the arch and CPU-centric stuff in shared arch code, given the device-specific code understandably proliferating now in mach trees.)
That said, I suspect Jon's 2-3 weeks is a little optimistic, as we need to pass some review barriers before releasing it under GPL. I won't go into the details on-list, but there are restrictions in the current BSD-augmented license terms that won't work well for you guys.
Our plan is definitely to get this into the Linaro kernel for the 11.05 release. My preferred approach is to get it into Catalin's public tree by early Q1, so that we stand a chance of merging it into the Linaro consolidated kernel. ARM will push it further upstream ASAP from Catalin's tree, but no guarantee that'll happen prior to 11.05. I think the staged approach is necessary, as Linaro is the place to prove the code integrated for multiple platforms.
Of course, let me know if you don't think we can make this work in time..
-Bobby
-----Original Message----- From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Amit Kucheria Sent: 13 October 2010 09:42 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
Yes, the earlier the better to starting incorporating the changes in Linux. Especially if you're interested in seeing this included in the kernel in 6 months time.
/Amit
On Tue, Oct 12, 2010 at 3:57 PM, Jon Callan Jon.Callan@arm.com wrote:
Amit,
Yes, it does seem a little tight doesn't it? Bobby is who
I'm working with on this, btw.
Maybe I could get the source code tidied and open it up in
2-3 weeks
time? Then we can all work on it together :-)
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 13:32 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
:)
As you can see, if you make the source available somewhere,
there is
plenty of people interested in dissecting it.
Jon, if you start working on them in December, we'll almost
certainly
miss the 2.6.38 merge window to get it integrated to mainline.
/Amit p.s. /me makes a note to talk to Bobby@ARM et al. regarding this.
On 10 Oct 12, Jon Callan wrote:
Well, my plan was to... er... post a message on linaro-dev
and see happened!
And yes, refactor as an ARM-common driver + SoC-specific
stubs, that sounds about right.
I plan to work on the Linux integration from 1st December.
I have done some Linux kernel work before but I'm a little rusty.
Jon.
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 12 October 2010 12:04 To: Jon Callan Cc: linaro-dev@lists.linaro.org Subject: Re: Common ARM context save/restore code
Jon,
I'm sure you anticipated this - What is your plan for pushing this out to the kernel? :)
And how can we help?
On Tue, Oct 12, 2010 at 1:39 PM, Jon Callan
Jon.Callan@arm.com wrote:
Vishwa,
I have a more-or-less complete set of example code for
CPU context save/restore, currently supporting A5/A8/A9 and with planned support for Eagle.
It is structured as "firmware" at the moment, but it
would be much better if it was integrated into the ARM Linux kernel. The idea is the kernel calls it from CPUidle, and it saves all CPU context and cuts the power. Then when power returns, it restores all CPU context and returns to the kernel as if nothing has happened.
It handles just the CPU and cluster context, which on
A9mpcore includes MMU, GIC, VFP, SCU, L2cc, Debug, etc. It takes care of cleaning caches and entering/leaving the coherency domain. There is also support for TrustZone, but as you say that's quite platform-specific.
So we would need to integrate this with the SoC-specific
code somehow.
So you need to refactor these to an ARM-common driver and
SoC-specific stubs?
/Amit
-- 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.
-- 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
-- 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.
On Sat, 2010-10-16 at 18:21 +0100, Bobby Batacharia wrote:
Yes, the earlier the better to starting incorporating the changes in Linux.
[...]
Our plan is definitely to get this into the Linaro kernel for the 11.05 release. My preferred approach is to get it into Catalin's public tree by early Q1, so that we stand a chance of merging it into the Linaro consolidated kernel.
Another step before this would be posting the proposed patches on the ARM Linux kernel mailing list for wider review.
Hi Catalin,
Our plan is definitely to get this into the Linaro kernel for the 11.05 release. My preferred approach is to get it into Catalin's public tree by early Q1, so that we stand a chance of merging it into the Linaro consolidated kernel.
Another step before this would be posting the proposed patches on the ARM Linux kernel mailing list for wider review.
Of course - thanks for making that explicit.
-Bobby
-- 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.
-
Amit Kucheria -
Bobby Batacharia -
Catalin Marinas -
David Rusling -
Jean Pihet -
Jon Callan -
Shilimkar, Santosh