8360E - PCI / DTC Blob Setup

[Kumar Gala]

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 :)

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

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

>
>> 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 at kernel.crashing.org]
> Sent: Thursday, February 01, 2007 10:11 AM
> To: rmcguire at videopresence.com
> Cc: linuxppc-embedded at 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 at 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