MPC8572 - IPR Register

MPC8572 - IPR Register

[Morrison, Tom]

We are having a problem with an external interrupt not actually being
received / detected on the MPC8572.=20

This external device 'believes' that it has sent an interrupt
(over PCIe) to the MPC8572 and we believe that the associated
ExVPR register has correctly unmasked/configured this correctly.

But, still NO interrupt...

If you read the documentation about this configuration register, it
indicates that there is some type of "IPR" register internal to the
8572 that indicates if an interrupt has been received by the PIC...

We want to read that IPR register to verify that:
   a) the external device has sent the interrupt=20
	and we have configured something wrong in the chip

   b) there is no pending interrupt (thus none received) from
	this external device...

Is there any way (hook (indirection) or crook (aka: secret register))
that would allow us to read this register? From all my investigations
it looks like there isn't a 'straight forward' / documented way to=20
do so...I am hoping you guys have gone beyond the 'straight forward'=20
means and have found a way...

Thanks in Advance...

Sincerely...

Tom Morrison
Principal S/W Engineer=20
Tmorrison (at) empirix (dot) com
www.empirix.com

Re: MPC8572 - IPR Register

[Kumar Gala]

On Dec 16, 2008, at 1:54 PM, Morrison, Tom wrote:

> We are having a problem with an external interrupt not actually being
> received / detected on the MPC8572.
>
> This external device 'believes' that it has sent an interrupt
> (over PCIe) to the MPC8572 and we believe that the associated
> ExVPR register has correctly unmasked/configured this correctly.
>
> But, still NO interrupt...
>
> If you read the documentation about this configuration register, it
> indicates that there is some type of "IPR" register internal to the
> 8572 that indicates if an interrupt has been received by the PIC...
>
> We want to read that IPR register to verify that:
>   a) the external device has sent the interrupt
> 	and we have configured something wrong in the chip
>
>   b) there is no pending interrupt (thus none received) from
> 	this external device...
>
> Is there any way (hook (indirection) or crook (aka: secret register))
> that would allow us to read this register? From all my investigations
> it looks like there isn't a 'straight forward' / documented way to
> do so...I am hoping you guys have gone beyond the 'straight forward'
> means and have found a way...
>
> Thanks in Advance...

1. Which PCIe port is the device on?
2. is this a INT-X style or MSI interrupt?
3. if INT-X is INT-A, B, C, D?

- k

Re: MPC8572 - IPR Register

[bterrell]

Kumar Gala-3 wrote:
> 
> 
> <1. Which PCIe port is the device on?
> 2. is this a INT-X style or MSI interrupt?
> 3. if INT-X is INT-A, B, C, D?
> 
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

He was posting a question for me.  The external device (PLX8616
non-transparent bridge) which is sending the interrupt is connected to the
first PCIE controller.  The PCIE controller is configured in RC mode and is
"x4".  I'm using legacy (INTx) interrupts from the external switch NTB port. 
The NTB port always generates INTA, but is swizzled by the upstream port of
the PLX8616 switch, so it comes to the PCIE controller as INTB I believe.

It works fine when the the 8572 and 8616 both start after power-on reset. 
Can send multiple interrupts and each is acknowledged properly.  However,
after I generate a "hot reset" event from the PCIE controller to the
upstream port on the 8616 (or link goes down/up), it no longer seems to
propagate the INTx interrupt to the CPU.  Either the 8616 is not sending the
interrrupt or the 8572 is ignoring/masking it.  I'm trying to determine
which device is at fault.  I don't have access to a PCIE analyzer at the
moment.  Looking for some more visibility into received interrupts within
the 8572 PCIE or MPIC.  

FYI, I have not tried MSI yet but will soon.

thanks,
Bill
-- 
View this message in context: http://www.nabble.com/MPC8572---IPR-Register-tp21040440p21042870.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: MPC8572 - IPR Register

[Kumar Gala]

On Dec 16, 2008, at 4:08 PM, bterrell wrote:

>
>
> Kumar Gala-3 wrote:
>>
>>
>> <1. Which PCIe port is the device on?
>> 2. is this a INT-X style or MSI interrupt?
>> 3. if INT-X is INT-A, B, C, D?
>>
>> - k
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>
> He was posting a question for me.  The external device (PLX8616
> non-transparent bridge) which is sending the interrupt is connected  
> to the
> first PCIE controller.  The PCIE controller is configured in RC mode  
> and is
> "x4".  I'm using legacy (INTx) interrupts from the external switch  
> NTB port.
> The NTB port always generates INTA, but is swizzled by the upstream  
> port of
> the PLX8616 switch, so it comes to the PCIE controller as INTB I  
> believe.
>
> It works fine when the the 8572 and 8616 both start after power-on  
> reset.
> Can send multiple interrupts and each is acknowledged properly.   
> However,
> after I generate a "hot reset" event from the PCIE controller to the
> upstream port on the 8616 (or link goes down/up), it no longer seems  
> to
> propagate the INTx interrupt to the CPU.  Either the 8616 is not  
> sending the
> interrrupt or the 8572 is ignoring/masking it.  I'm trying to  
> determine
> which device is at fault.  I don't have access to a PCIE analyzer at  
> the
> moment.  Looking for some more visibility into received interrupts  
> within
> the 8572 PCIE or MPIC.
>
> FYI, I have not tried MSI yet but will soon.

So I'll ask the same questions.  I can point you at some registers to  
look at but wanted the details I asked about earlier.

- k

Re: MPC8572 - IPR Register

[bterrell]

On Dec 16, 2008, at 4:08 PM, bterrell wrote:

>
>
> Kumar Gala-3 wrote:
>>
>>
>> <1. Which PCIe port is the device on?
>> 2. is this a INT-X style or MSI interrupt?
>> 3. if INT-X is INT-A, B, C, D?

1. Non-transparent bridge device is on port 1 of the PLX8616 switch, which
is connected to first PCIE controller.
2. Using INTx style interrupts.
3. NT device asserts INTA, but this is swizzled by the upstream port of the
switch to be INTB before sending to 8572.

The problem also occurs when a hot-reset is sent inband from the PCIE
controller on 8572.  I see the following differences in 8572 PCIE registers
in configuration space before/after the "hot reset" is sent:

PEX Config Space Register 0x414: before 0x00000000 after 0x000000001 <==
undocumented reg??

PEX Config Space Register 0x43C: before 0x00C2DC76 after 0x00013014 <==
undocumented reg??

PEX Config Space Register 0x4E8: before 0x00004D4D after 0x00000101 <==
undocumented reg??

Any idea what these registers are?

thanks,
Bill Terrell
Empirix, Inc.


-- 
View this message in context: http://www.nabble.com/MPC8572---IPR-Register-tp21040440p21058850.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.