8360E - PCI / DTC Blob Setup

[Russell McGuire]

Well I am getting smarter on this:

I have read through the PCI Bridge Specs and found another issue that might
have been causing a problem with the IDSEL lines. Unless you are interested
I'll forgo that explanation and just go with fact that I have changed the
IDSEL mappings to be legal when they are issued from the 83xx.

I have changed the IDSELs to be as follows, does this look correct?
I agree with placing the NODE for the bridge into the dts file to be
correct. Except I get stuck immediately at trying to come up with an
address. I.e. the PCI host has a PCI at 8500, which makes sense. But the Bridge
chip doesn't have a mapped address to place in the file. I did read the PCI
OF node spec <dated 1996> it hints that PCI-PCI bridges are essentially the
same domain and may not need translation.

Another concern I have now is that the interrupt mask may be incorrect.
i.e. currently it is <f800 0 0 7>, should I change this to <3f800 0 0 7>
since I am using an extra 2 bits to indicate bus? This would make sense if
the ((Bus << 16) | Dev << 11))

>> Bus 1, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
> 15800 0 0 1 700 14 8 //Int A always to IRQ 20
> 15800 0 0 2 700 15 8 //Int B always to IRQ 21
> 15800 0 0 3 700 16 8 //Int C always to IRQ 22
> 15800 0 0 4 700 17 8 //Int D always to IRQ 23
>> Bus 1, Slot 2, (Bridge IDSEL = AD30 mapped to IDSEL AD13 on host)
> 17000 0 0 1 700 14 8
> 17000 0 0 2 700 15 8
> 17000 0 0 3 700 16 8
> 17000 0 0 4 700 17 8
>> Bus 2, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host)
> 25800 0 0 1 700 14 8
> 25800 0 0 2 700 15 8
> 25800 0 0 3 700 16 8
> 25800 0 0 4 700 17 8

These IDSEL mappings seem to match exactly what U-boot will report
i.e. Bus.Dev = 1.0b, 1.0e, 2.0b. 

I have not placed any reference to the Bridge chip's IDSEL line, since it
cannot activate any IRQ lines directly. Well try it both ways perhaps and
see what happens.

The good news is with this configuration, the ca0106 driver will load. I can
get all the way into linux, and see the associated creations under the
/proc/ file system. To me all this really proves to me is that the IRQ
hasn't been toggled. Now I have to figure out how to get the /dev/dsp
devices in the /dev directory. If ALSA still uses this, I am used to OSS.

I am trying a PCI USB 2.0 card now, with various drivers and devices plugged
in I get varying results from 'try irqpoll' to boot hanging. Not sure if
this is an IRQ problem or a another related PCI bug.

What fun this is.

-Russ

-----Original Message-----
From: Kumar Gala [mailto:galak at kernel.crashing.org] 
Sent: Thursday, February 01, 2007 10:21 PM
To: rmcguire at videopresence.com
Cc: linuxppc-embedded at ozlabs.org ((((E-Mail)))); Benjamin Herrenschmidt
Subject: 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 :)

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