Hello Abel,
What is the status of this workaround? I saw that you had a similar discussion at the kernel mailing list (https://lkml.org/lkml/2019/3/27/542) which, however, has been inactive for some time.
Do you still intend to pursue that solution? If you do so, please submit your patches to review.trustedfirmware.org under the "TF-A/trusted-firmware-a" project. To login you just need your GitHub account. You can find further information about contributions in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proce..., especially the "Submitting Changes" section, or contact us here.
Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: john.tsichritzis@arm.commailto:john.tsichritzis@arm.com 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom https://www.arm.com/
On 2019-03-27 15:35, Abel Vesa via TF-A wrote:
On 19-03-27 13:45:21, Soby Mathew wrote:
Hi Abel, Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams.
I know this might be a pain. That's why I'm just asking for as many opinions on this as possible.
Just to summarize my understanding: Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time.
That errata is specifically for IPIs. If all the cores are in suspend, any interrupt will be able to wake one of the cores. That's why the workaround suggested in that document works. But that workaround is waking up all the cores, that's why I added this poking mechanism which is per-core.
Adding the kernel team for their input.
JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
Currently the project is in github but we expect to migrate to trustedfirmware.org in April.
Hmm, ok. Good to know.
Best Regards Soby Mathew
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org On Behalf Of Abel Vesa via TF-A Sent: 27 March 2019 12:16 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation
This is more like a workaround for platforms like i.MX8MQ that have an issue related to the wake_request GIC signal integration.
See E11171 here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co...
The workaround mentioned in the document has the dissadvantage of waking up all the sleeping cores instead of just one.
This patchset adds another psci op for core 'poking' (waking up). On i.MX8MQ, the plat specific implementation writes the corresponding bits in GPC to wake up independently each core.
Abel Vesa (2): psci: Add cpu wake operation plat: imx8mq: Trigger SW power up per core
include/lib/psci/psci.h | 3 +++ lib/psci/psci_main.c | 17 +++++++++++++++++ lib/psci/psci_setup.c | 2 ++ plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++ plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++ plat/imx/imx8m/include/gpc.h | 2 ++ 6 files changed, 39 insertions(+)
-- 2.7.4
-- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
On 19-06-10 13:14:49, John Tsichritzis wrote:
Hello Abel,
Hi John,
What is the status of this workaround? I saw that you had a similar discussion at the kernel mailing list ([1]https://lkml.org/lkml/2019/3/27/542) which, however, has been inactive for some time. Do you still intend to pursue that solution? If you do so, please submit your patches to review.trustedfirmware.org under the "TF-A/trusted-firmware-a" project. To login you just need your GitHub account. You can find further information about contributions in [2]https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proce..., especially the "Submitting Changes" section, or contact us here.
I just sent today another (different) approach for the kernel part.
The TF-A part will be sent after I get a feedback about the possibility of getting it in from the kernel irqchip maintainers.
BTW, this new approach does not use the PSCI. Instead, it uses a newly added vendor SIP.
Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: [3]john.tsichritzis@arm.com 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom [4]https://www.arm.com/
On 2019-03-27 15:35, Abel Vesa via TF-A wrote:
On 19-03-27 13:45:21, Soby Mathew wrote:
Hi Abel, Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams.
I know this might be a pain. That's why I'm just asking for as many opinions on this as possible.
Just to summarize my understanding: Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time.
That errata is specifically for IPIs. If all the cores are in suspend, any interrupt will be able to wake one of the cores. That's why the workaround suggested in that document works. But that workaround is waking up all the cores, that's why I added this poking mechanism which is per-core.
Adding the kernel team for their input.
JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here: [5]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
Currently the project is in github but we expect to migrate to trustedfirmware.org in April.
Hmm, ok. Good to know.
Best Regards Soby Mathew
-----Original Message----- From: TF-A [6]tf-a-bounces@lists.trustedfirmware.org On Behalf Of Abel Vesa via TF-A Sent: 27 March 2019 12:16 To: [7]tf-a@lists.trustedfirmware.org Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation
This is more like a workaround for platforms like i.MX8MQ that have an issue related to the wake_request GIC signal integration.
See E11171 here: [8]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co...
The workaround mentioned in the document has the dissadvantage of waking up all the sleeping cores instead of just one.
This patchset adds another psci op for core 'poking' (waking up). On i.MX8MQ, the plat specific implementation writes the corresponding bits in GPC to wake up independently each core.
Abel Vesa (2): psci: Add cpu wake operation plat: imx8mq: Trigger SW power up per core
include/lib/psci/psci.h | 3 +++ lib/psci/psci_main.c | 17 +++++++++++++++++ lib/psci/psci_setup.c | 2 ++ plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++ plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++ plat/imx/imx8m/include/gpc.h | 2 ++ 6 files changed, 39 insertions(+)
-- 2.7.4
-- TF-A mailing list [9]TF-A@lists.trustedfirmware.org [10]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
References
Visible links
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2...
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...
- mailto:john.tsichritzis@arm.com
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arm.co...
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
- mailto:tf-a-bounces@lists.trustedfirmware.org
- mailto:tf-a@lists.trustedfirmware.org
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co...
- mailto:TF-A@lists.trustedfirmware.org
- https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
Hello again,
I just sent today another (different) approach for the kernel part.
The TF-A part will be sent after I get a feedback about the possibility of getting it in from the kernel irqchip maintainers.
BTW, this new approach does not use the PSCI. Instead, it uses a newly added vendor SIP.
Good to know, thanks for the update!
John
On 2019-06-10 14:21, Abel Vesa wrote:
On 19-06-10 13:14:49, John Tsichritzis wrote:
Hello Abel,
Hi John,
What is the status of this workaround? I saw that you had a similar discussion at the kernel mailing list ([1]https://lkml.org/lkml/2019/3/27/542) which, however, has been inactive for some time. Do you still intend to pursue that solution? If you do so, please submit your patches to review.trustedfirmware.org under the "TF-A/trusted-firmware-a" project. To login you just need your GitHub account. You can find further information about contributions in [2]https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proce..., especially the "Submitting Changes" section, or contact us here.
I just sent today another (different) approach for the kernel part.
The TF-A part will be sent after I get a feedback about the possibility of getting it in from the kernel irqchip maintainers.
BTW, this new approach does not use the PSCI. Instead, it uses a newly added vendor SIP.
Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: [3]john.tsichritzis@arm.commailto:3]john.tsichritzis@arm.com 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom [4]https://www.arm.com/
On 2019-03-27 15:35, Abel Vesa via TF-A wrote:
On 19-03-27 13:45:21, Soby Mathew wrote:
Hi Abel, Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams.
I know this might be a pain. That's why I'm just asking for as many opinions on this as possible.
Just to summarize my understanding: Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time.
That errata is specifically for IPIs. If all the cores are in suspend, any interrupt will be able to wake one of the cores. That's why the workaround suggested in that document works. But that workaround is waking up all the cores, that's why I added this poking mechanism which is per-core.
Adding the kernel team for their input.
JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here: [5]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
Currently the project is in github but we expect to migrate to trustedfirmware.org in April.
Hmm, ok. Good to know.
Best Regards Soby Mathew
-----Original Message----- From: TF-A [6]tf-a-bounces@lists.trustedfirmware.orgmailto:tf-a-bounces@lists.trustedfirmware.org On Behalf Of Abel Vesa via TF-A Sent: 27 March 2019 12:16 To: [7]tf-a@lists.trustedfirmware.orgmailto:7]tf-a@lists.trustedfirmware.org Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation
This is more like a workaround for platforms like i.MX8MQ that have an issue related to the wake_request GIC signal integration.
See E11171 here: [8]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co...
The workaround mentioned in the document has the dissadvantage of waking up all the sleeping cores instead of just one.
This patchset adds another psci op for core 'poking' (waking up). On i.MX8MQ, the plat specific implementation writes the corresponding bits in GPC to wake up independently each core.
Abel Vesa (2): psci: Add cpu wake operation plat: imx8mq: Trigger SW power up per core
include/lib/psci/psci.h | 3 +++ lib/psci/psci_main.c | 17 +++++++++++++++++ lib/psci/psci_setup.c | 2 ++ plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++ plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++ plat/imx/imx8m/include/gpc.h | 2 ++ 6 files changed, 39 insertions(+)
-- 2.7.4
-- TF-A mailing list [9]TF-A@lists.trustedfirmware.orgmailto:9]TF-A@lists.trustedfirmware.org [10]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
References
Visible links 1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2... 2. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste... 3. mailto:john.tsichritzis@arm.com 4. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arm.co... 5. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... 6. mailto:tf-a-bounces@lists.trustedfirmware.org 7. mailto:tf-a@lists.trustedfirmware.org 8. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co... 9. mailto:TF-A@lists.trustedfirmware.org 10. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
tf-a@lists.trustedfirmware.org