From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout10-04.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by ozlabs.org (Postfix) with SMTP id 6814ADDDDB for ; Fri, 2 Feb 2007 13:49:05 +1100 (EST) From: "Russell McGuire" To: "'Kumar Gala'" References: <000601c74531$62220820$6405a8c0@absolut> <0ACC0A3E-9DF3-4927-8F67-E525BA0E6C13@kernel.crashing.org> <000001c7454b$69a25ae0$6405a8c0@absolut> <0A655A39-4101-48B4-BE9C-50A30163679C@kernel.crashing.org> <000701c7457a$d180e300$6405a8c0@absolut> <183E66A5-E983-4D17-96E9-2EEAE6FDF7B6@kernel.crashing.org> <000f01c74587$10bc5cf0$6405a8c0@absolut> <1546691E-0CCF-41C9-8B8A-7C6326CEEF7E@kernel.crashing.org> <000301c7458b$b9eb1330$6405a8c0@absolut> <829261C6-F534-4B85-A04D-8D280E46B2CF@kernel.crashing.org> <000401c74591$8a3a4ec0$6405a8c0@absolut> <000801c7460d$211e46e0$6405a8c0@absolut> <974C77BD-19A0-4843-8E7B-3B430DB4ADE9@kernel.crashing.org> <001101c74629$28797380$6405a8c0@absolut> Subject: RE: 8360E - PCI / DTC Blob Setup Date: Thu, 1 Feb 2007 18:49:00 -0800 Message-ID: <001001c74674$b17bf4f0$6405a8c0@absolut> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" In-Reply-To: Cc: linuxppc-embedded@ozlabs.org Reply-To: rmcguire@videopresence.com List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. > (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. >: > >[(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 > 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 > Bus 1, Slot 2, IDSEL = AD24 > Bus 2, Slot 1, IDSEL = AD20 > > That being said: > /* IDSEL 0x19 AD25*/ > c800 0 0 1 700 14 8 so the way you read this: Do break it down further: : [(bus << 16) | (idsel << 11)] 0 0 : INTA - 1 INTB - 2 INTC - 3 INTD - 4 (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