Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1635366 > unrolled thread

gic_write_grpen1 in hotplug flow

Back to article view | Back to linux.kernel

Contents

  gic_write_grpen1 in hotplug flow Sodagudi Prasad <psodagud@codeaurora.org> - 2017-05-04 03:40 +0200
    Re: gic_write_grpen1 in hotplug flow Sudeep Holla <sudeep.holla@arm.com> - 2017-05-04 11:20 +0200

#1635366 — gic_write_grpen1 in hotplug flow

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

[toc] | [next] | [standalone]

#1635556

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web