• State Accepted Answer
  • Replies 3 replies
  • Subscribers 141 subscribers
  • Views 11864 views
  • Users 0 members are here
Options
Related
How was your experience today?

GICv2 deactivation feature.

Jorge

Hello all,

There is one thing which is unclear for me in GICv2.

GICv3 spec. explicitly says "SGIs and PPIs must be deactivated by the PE that activated the interrupt. SPIs can be deactivated by a different PE. "

In GICv2 I don't find anything related to this. Can I rely in the same behavior for SPIs of GICv3? or in GICv2 an SPI must be deactivated by the PE that previously activated it?

Cheers,

Jorge

Parents
  • +1

    Good question, I will look into why there's not statement in GICv2.

    Priority drop must be done from the same core as did the activation, as it is how the GIC manages the core's running priority.

    For Deactivation, it's updating the state of the SPI (which is global) rather the state of the core.  Hence, the deactivation can come from any core.

Reply
  • +1

    Good question, I will look into why there's not statement in GICv2.

    Priority drop must be done from the same core as did the activation, as it is how the GIC manages the core's running priority.

    For Deactivation, it's updating the state of the SPI (which is global) rather the state of the core.  Hence, the deactivation can come from any core.

Children