RE: 8360E - PCI / DTC Blob Setup

["Russell McGuire" <rmcguire@videopresence.com>]

Kumar,

THANK you, for pointing me in the right direction. I might have scratched my
head another 10 years finding this bug. And an apology for thinking I had a
software issue, when it was a hardware issue.

This is helping me greatly, all the while I had this sinking feeling, like I
didn't route any 'incoming' interrupt lines to the CPU. Something about the
8360 being able to get configured as an agent device, so I over looked the
use of the INTA pin on the CPU as incoming vs outgoing.

SO it would seem I didn't have ANY incoming pins, and thus the IRQ4-7 pins
that occur in the 8360E-MDS board were floating on my board. So as soon as
the sound driver enabled the interrupt, it was low all the time.

><HOST IRQ specifier> (on 83xx):>
>
>[linux,phandle for interrupt controller] [IRQ #] [sense]

I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17 would
correspond to external IRQ4-7 in the MPC8360E. I will wire this up and give
it a shot, guess it works better when they are connected.

><PCI DEV specifier>:
>
>[(bus << 16) | (idsel << 11)] 0 0

Well I think this is definitely part of my problem.
So I am mapping interrupts from bus 1 and 2, I would need something like?
Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are the bus 

> Bus 1, Slot 1, IDSEL = AD20 
1a000 0 0 1 700 14 8
1a000 0 0 1 700 15 8
1a000 0 0 1 700 16 8
1a000 0 0 1 700 17 8
> Bus 1, Slot 2, IDSEL = AD24 
1c000 0 0 1 700 15 8
1c000 0 0 1 700 16 8
1c000 0 0 1 700 17 8
1c000 0 0 1 700 18 8
> Bus 2, Slot 1, IDSEL = AD20 
2a000 0 0 1 700 16 8
2a000 0 0 1 700 17 8
2a000 0 0 1 700 18 8
2a000 0 0 1 700 19 8

-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org] 
Sent: Thursday, February 01, 2007 10:11 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8360E - PCI / DTC Blob Setup


On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote:

> This might be the wrong forum to discuss HW routing, but I am not  
> sure of
> many HW guys that would understand blob setups. I know I still don't.
>
> I read through the booting-without-of-tree.txt and it doesn't  
> explain this
> other than the interrupt routing needs to be present. Perhaps some  
> of the
> maintainers of the 83xx platforms can explain how this blob is  
> developed?
> I assume their board work with the submitted mp38360emds.dts files,  
> as an
> example.
>
> Let me see if I can simplify this, I had this schematic reviewed by  
> Pericom
> <a PCI bridge MFG> and they recommended these IDSEL lines. And I  
> know the
> card detection works great, in U-boot.
>
> My external PCI bridge is the only thing routed directly to the  
> 8360 Host
> bridge. The PCI Host bridge in my system is connected on IDSEL- 
> >AD25,0x19
> Perhaps I shouldn't use any interrupt routing for this, as there is  
> no true
> /INTA line tied directly to the bridge?
>
> My Three PCI slots are routed as follows:
>
> Bus 0, Bridge Chip, IDSEL = AD25

Huh, this is only describes one slot/connection.  If you have 3  
slots, they'd have 3 unique IDSELs

> Other side of the Host bridge, all are routed to INTA directly to the
> CPU.
> Bus 1, Slot 1, IDSEL = AD20 <card would be ID'd as 1.04 (Bus.Dev)>
> Bus 1, Slot 2, IDSEL = AD24 <card would be ID'd as 1.08 (Bus.Dev)>
> Bus 2, Slot 1, IDSEL = AD20 <card would be ID'd as 2.04 (Bus.Dev)>
>
> That being said:
> /* IDSEL 0x19 AD25*/
>  c800 0 0 1 700 14 8

so the way you read this:

<PCI DEV specifier> <INT A-D> <HOST IRQ specifier>

Do break it down further:

<PCI DEV specifier>:

[(bus << 16) | (idsel << 11)] 0 0

<INT A-D>:
INTA - 1
INTB - 2
INTC - 3
INTD - 4

<HOST IRQ specifier> (on 83xx):

[linux,phandle for interrupt controller] [IRQ #] [sense]

> I see in the c800 directly corresponds to the 83xx manual for PCI  
> CONFIG
> address mapping for AD25.
>
> I think the '1' is mapped to /INTA, which is the only PCI INT  
> available in
> the 8360E.

INTA..INTD is more about the device, not host.

> I understand the 700 in this case is the address of the PIC@700.
>
> That leaves 5 fields/questions.
> 1) What do the first two '0's after c800 mean?

There always 0 0, since the int masks them away (they normally  
describe the address the device is at)

> 2) What does the '14' map to?

0x14 is the external IRQ # its wired to.

> 3) What does the '8' map to?

Sense of IRQ, should always be level for PCI.

> 4) Why would some boards map multiple interrupts to a single IDSEL,  
> like the
> mpc8360emds.dts file? Is this to handle extra bridges that might be  
> plugged
> in at a later time?

This is to handle the fact that a PCI add on card put into a slot  
might use multiple interrupts (INTA, INTB), so it lists multiple  
entries to cover the 4 PCI defined interrupts.

> If I understand the mapping correctly then I think I can hard code  
> in the
> interrupts for the PCI slots.
>
> So I don't drive everybody nuts, is there actual documentation on  
> this. I
> would be happy to stop spamming this list... :-)

There is, but its scattered in places.

Its good to ask these questions so the answers will get archived and  
other people can figure it out as well.

- k