On Feb 2, 2007, at 7:36 AM, Russell McGuire wrote: > > 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?
Not sure, I'm a little confused as to how exactly things are wired on your board. It would seem like you have 2 P2P bridges connected to the processor. Behind one bridge is 2 slots and behind the second is 1 slot? > 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 [EMAIL PROTECTED], 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)) Yes that makes sense. > >>> 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:[EMAIL PROTECTED] > Sent: Thursday, February 01, 2007 10:21 PM > To: [EMAIL PROTECTED] > Cc: [email protected] ((((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:[EMAIL PROTECTED] >> Sent: Thursday, February 01, 2007 10:11 AM >> To: [EMAIL PROTECTED] >> Cc: [email protected] >> 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 [EMAIL PROTECTED] >>> >>> 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 > _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
