Polarity of PCI Express INTx/IRQn sharing

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Polarity of PCI Express INTx/IRQn sharing

Jump to solution
1,337 Views
zy_mooncity
Contributor III

I'm working on a P2020 BSP. According to P2020RM section 9.4.6, these information can be founded:

   "The internal INTx signals from the PCI Express controller are logically combined with the interrupt request (IRQn) signals so that they share the same OpenPIC external interrupt controlled by the associated EIVPRn and EIDRn registers."

   And "If a PCI Express INTx signal is being used, the PIC must be configured so that external interrupts are level sensitive (EIVPRn[S] = 1). If an IRQn signal is being used as edge-triggered (EIVPRn[S]= 0), the system must not allow inbound PCI Express INTx transactions."

In P2020RM section 9.3.43 External interrupt n (IRQn) vector/priority register (PIC_EIVPRn),

"bit 8, P: Polarity. Specifies the polarity for the external interrupt.
NOTE: If any of IRQ[0:11] are used to receive INTx signals from one of the PCI Express ports as a root complex, the polarity must be set to be active-high.
0 Polarity is active-low or negative edge-triggered.
1 Polarity is active-high or positive edge-triggered.


bit 9, S: Sense. Specifies the sense for external interrupts.
NOTE: If an IRQn signal is used to receive INT x signals from one of the PCI Express ports as a root complex, S must be set to be level-sensitive.
0 The external interrupt is edge sensitive.
1 The external interrupt is level sensitive. This setting must be used to direct the interrupt to IRQ_OUT_B or cint."

In my system, there is no IRQn signal,  only PCI-E INTx signal exist. It's clear to me that the PCI Express INTx should be configured with level sensitive. My concern is about the polarity of the PCI-E INTx.The polarity of the PCI-E INTx usually is set to be active-low. Actually speaking, in my current system, active-low polarity works fine so far. But according to the Note above, the PCI-E INTx must be set to be active-high. The note confused me. Can I get any clarification about the setting of the polarity in this situation (PCI Express INTx/IRQn sharing)?

Thanks in avdance!

Labels (1)
0 Kudos
1 Solution
916 Views
ufedor
NXP Employee
NXP Employee

The P2020RM note concerning Polarity is not fully correct - please refer to the P1022RM which contains the correct one:

"If any of IRQ[0:11] are used to receive INTx signals from one of the PCI Express ports as a root complex, the polarity must be set to 1, if pin is not configured as IRQ. In case pin is configured as IRQ, then polarity can be set to either active high or active low provided corresponding inactive value is driven on IRQ pads."

By design when PCI Express controller receives INTx Asserted message it starts driving internal request with the level specified in the EIVPRn[P]. When IRQ signal is configured as GPIO corresponding internal request have low level - this is why it is required to set EIVPRn[P]=1 in this case.

View solution in original post

3 Replies
917 Views
ufedor
NXP Employee
NXP Employee

The P2020RM note concerning Polarity is not fully correct - please refer to the P1022RM which contains the correct one:

"If any of IRQ[0:11] are used to receive INTx signals from one of the PCI Express ports as a root complex, the polarity must be set to 1, if pin is not configured as IRQ. In case pin is configured as IRQ, then polarity can be set to either active high or active low provided corresponding inactive value is driven on IRQ pads."

By design when PCI Express controller receives INTx Asserted message it starts driving internal request with the level specified in the EIVPRn[P]. When IRQ signal is configured as GPIO corresponding internal request have low level - this is why it is required to set EIVPRn[P]=1 in this case.

916 Views
zy_mooncity
Contributor III

Hi ufedor,

Thanks for this your clear explanation. The last thing I want to confirm is the meaning of "If pin is not configured as IRQ". Does it mean the pin is configured as GPIO?

Regards

Yun

0 Kudos
916 Views
ufedor
NXP Employee
NXP Employee

Yes.

0 Kudos