Re: gic_write_grpen1 in hotplug flow

[Sudeep Holla]

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