From: "Russell McGuire" <rmcguire@videopresence.com>
To: "'Kumar Gala'" <galak@kernel.crashing.org>
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: 8360E - PCI / DTC Blob Setup
Date: Thu, 1 Feb 2007 09:48:18 -0800 [thread overview]
Message-ID: <001101c74629$28797380$6405a8c0@absolut> (raw)
In-Reply-To: <974C77BD-19A0-4843-8E7B-3B430DB4ADE9@kernel.crashing.org>
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
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
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.
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?
2) What does the '14' map to?
3) What does the '8' map to?
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?
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... :-)
-Russ
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, February 01, 2007 6:33 AM
To: rmcguire@videopresence.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8360E - PCI / DTC Blob Setup
On Feb 1, 2007, at 8:27 AM, Russell McGuire wrote:
> Since I am hip deep in debugging the PCI system.
>
> In the .dts files there is the section for the PCI setup.
>
> The interrupt-map = < >
>
> Does this need to include:
> 1) A mapping for every IDSEL line in the system?
> 2) Only those IDSELs that are used on the slots on the motherboard?
I'm not sure I follow the difference between 1/2. The map needs to
cover every IDSEL that has an IRQ line wired to it.
> 3) A custom entry for every card we want to support?
See above.
> 4) How does a bridge chip and slave busses affect the entries, if
> at all?
Uugh, I'm not sure how bridges are handled at this point.
> Looking at the mpc8360 / 8349 setups that are part of the latest
> kernel
> trees, some are place many and some are placing just a single entry?
>
> Which should be the preferred method?
It depends on your HW setup, the 8360/49 boards have some 'odd' IDSEL
irq mapping.
- k
next prev parent reply other threads:[~2007-02-01 17:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1454.1170226011.9285.linuxppc-embedded@ozlabs.org>
2007-01-31 12:14 ` Audigy SE / ca0106 driver for PowerPC? Russell McGuire
2007-01-31 14:52 ` Kumar Gala
2007-01-31 15:20 ` Russell McGuire
2007-01-31 15:34 ` Kumar Gala
2007-01-31 21:00 ` Russell McGuire
2007-01-31 21:55 ` Kumar Gala
2007-01-31 22:27 ` Russell McGuire
2007-01-31 22:40 ` Kumar Gala
2007-01-31 23:01 ` Russell McGuire
2007-01-31 23:19 ` Kumar Gala
2007-01-31 23:42 ` Russell McGuire
2007-01-31 23:49 ` Kumar Gala
2007-02-01 14:27 ` 8360E - PCI / DTC Blob Setup Russell McGuire
2007-02-01 14:33 ` Kumar Gala
2007-02-01 17:48 ` Russell McGuire [this message]
2007-02-01 18:11 ` Kumar Gala
2007-02-02 2:49 ` Russell McGuire
2007-02-02 6:20 ` Kumar Gala
2007-02-02 13:36 ` Russell McGuire
2007-02-02 15:48 ` Kumar Gala
2007-02-03 5:32 ` Russell McGuire
2007-02-05 1:45 ` Benjamin Herrenschmidt
2007-02-08 3:07 ` Andy Fleming
[not found] ` <000501c74592$2229e060$6405a8c0@absolut>
[not found] ` <53119C53-A3A7-4808-849A-09226BBEAC3B@kernel.crashing.org>
2007-02-01 9:00 ` Audigy SE / ca0106 driver for PowerPC? Russell McGuire
2007-02-01 14:22 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001101c74629$28797380$6405a8c0@absolut' \
--to=rmcguire@videopresence.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).