Re: 8360E - PCI / DTC Blob Setup

On Feb 1, 2007, at 8:49 PM, Russell McGuire wrote:

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.

No problem, this pretty much comes out of the PCI OF spec, but it  
takes a while to grok how we actually use it.

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.

That would definitely be a HW issue :)

quoted

<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.

Yeah all numbers are hex, I forget if you can put a leading 0x or  
not.. its kinda annoying.

quoted

<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?

Truthfully you should probably have child nodes that describe the  
bridges and have their interrupt mappings described there.

The code is going to end up using the Bus #, IDSEL for the pci device  
to try and determine the CPU ext interrupt its mapped to.

Unfortunately, we don't really have an example of this.

Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are  
the bus

not following the question.

quoted

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

quoted

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

quoted

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:

quoted

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-

quoted

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

quoted

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]

quoted

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.

quoted

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)

quoted

2) What does the '14' map to?

0x14 is the external IRQ # its wired to.

quoted

3) What does the '8' map to?

Sense of IRQ, should always be level for PCI.

quoted

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.

quoted

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