* gic_write_grpen1 in hotplug flow
@ 2017-05-04 1:30 Sodagudi Prasad
2017-05-04 9:17 ` Sudeep Holla
0 siblings, 1 reply; 2+ messages in thread
From: Sodagudi Prasad @ 2017-05-04 1:30 UTC (permalink / raw)
To: marc.zyngier, sudeep.holla, will.deacon
Cc: Jason Cooper, Thomas Gleixner, linux-kernel
Hi All,
This is regarding the usage of gic_write_grpen1 API usage in irq-gic-v3
driver.
Here my understanding about ICC_IGRPEN1_EL1.
ICC_IGRPEN1_EL1 is banked between secure and non-secure states. If two
secure states are implemented, Secure side Group bit is set by the
platform firmware (PSCI) and kernel need to set in non secure state.
https://mail.codeaurora.org/?_task=mail&_action=compose&_id=676833541590a775943df6#
1) Currently gic_write_grpen1(0) is getting called from
gic_cpu_pm_notifier() for CPU_PM_ENTER in single security state only.
But enabling of group1 non-secure interrupts are done in CPU_PM_EXIT
path unconditionally. Why are we not disabling group1 non-secure
interrupts unconditionally in CPU_PM_ENTER(and disabling only in single
security state)?
2) Why group1 non-secure interrupts are not disabled in kernel during
cpu hotplug path? Spurious interrupt can still come if we dont disable
group1 non-secure interrupts, right?
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: gic_write_grpen1 in hotplug flow
2017-05-04 1:30 gic_write_grpen1 in hotplug flow Sodagudi Prasad
@ 2017-05-04 9:17 ` Sudeep Holla
0 siblings, 0 replies; 2+ messages in thread
From: Sudeep Holla @ 2017-05-04 9:17 UTC (permalink / raw)
To: Sodagudi Prasad
Cc: marc.zyngier, will.deacon, Sudeep Holla, Jason Cooper,
Thomas Gleixner, linux-kernel
Hi Prasad,
On 04/05/17 02:30, Sodagudi Prasad wrote:
> Hi All,
>
> This is regarding the usage of gic_write_grpen1 API usage in
> irq-gic-v3 driver.
>
> Here my understanding about ICC_IGRPEN1_EL1. ICC_IGRPEN1_EL1 is
> banked between secure and non-secure states. If two secure states are
> implemented, Secure side Group bit is set by the platform firmware
> (PSCI) and kernel need to set in non secure state.
> https://mail.codeaurora.org/?_task=mail&_action=compose&_id=676833541590a775943df6#
>
Are you referring to something with the above link ? If so, it's not
accessible
> 1) Currently gic_write_grpen1(0) is getting called from
> gic_cpu_pm_notifier() for CPU_PM_ENTER in single security state
> only. But enabling of group1 non-secure interrupts are done in
> CPU_PM_EXIT path unconditionally. Why are we not disabling group1
> non-secure interrupts unconditionally in CPU_PM_ENTER(and disabling
> only in single security state)?
>
If you read the log in commit ccd9432a5c85 ("irqchip/gicv3: Remove
disabling redistributor and group1 non-secure interrupts"), it clearly
states the reason. In fact it was required to support RETENTION states
on some Qualcomm parts itself. So in short, we enable in CPU_PM_EXIT
path unconditionally just to be sure. It can be made conditional but
not a hard requirement while not disabling in CPU_PM_ENTER is.
> 2) Why group1 non-secure interrupts are not disabled in kernel
> during cpu hotplug path? Spurious interrupt can still come if we dont
> disable group1 non-secure interrupts, right?
>
As per PSCI specification: "Unlike CPU_SUSPEND , CPU_OFF is not expected
to return". We disable local CPI interrupt mask before CPU_OFF. We can
re-enter only with CPU_ON call, so I don't see possibility of any issues
with that. Are you observing any issues ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-05-04 9:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-04 1:30 gic_write_grpen1 in hotplug flow Sodagudi Prasad
2017-05-04 9:17 ` Sudeep Holla
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).