linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Gerhard Pircher" <gerhard_pircher@gmx.net>
To: "Roderick Colenbrander" <thunderbird2k@gmx.net>, linuxppc-dev@ozlabs.org
Subject: Re: DTS file PCI / i8259 for Xilinx ML510
Date: Sat, 14 Mar 2009 22:54:39 +0100	[thread overview]
Message-ID: <20090314215439.8080@gmx.net> (raw)
In-Reply-To: <20090312103219.228100@gmx.net>


-------- Original-Nachricht --------
> Datum: Thu, 12 Mar 2009 11:32:19 +0100
> Von: "Roderick Colenbrander" <thunderbird2k@gmx.net>
> An: linuxppc-dev@ozlabs.org
> Betreff: DTS file PCI / i8259 for Xilinx ML510

> ...
> The freescale boards define the pci bus like below and connect ULI M1575
> peripherals to the i8259 controller. Regarding the entries in the pci
> interrupt-map what does the fourth column mean? According to source code
> it means 'interrupt specifier' but what does it mean? In a lot of cases
> it is 1.
IIRC the fourth column is the PCI interrupt line (INTA..D = 1..4). The
Freescale boards may have a number of onboard PCI devices, which are
usually connected to a single PCI interrupt line only (INTA). In this
case a PCI unit address (1. column) is specified only once within the
interrupt-map table and the corresponding interrupt specifier is set
to 1 for INTA.
On the other side PCI slots can have up to four entries (INTA..D) for a
specific PCI unit address.

Please take a look at this document here:
http://playground.sun.com/1275/practice/imap/imap0_9d.html

> Further I believe in this case the entries behind 'mpic' correspond to
> the inta/b/c/d lines, is that correct? On my board inta is connected to
> interrupt 5 (intb=4, intc=3, intd=2) of the xilinx intc, so I would need
> to use those numbers there for my board?
No, the last two columns specify the real interrupt (IRQ line, level or
edge triggered). They're values depend on the type of interrupt
controller and its #interrupt-cells property.

> 	pci0: pcie@f8008000
> 	{
> 		device_type = "pci";
> 		#interrupt-cells = <1>;
> 		#size-cells = <2>;
> 		#address-cells = <3>;
> 		..
> 		..
> 		interrupt-map-mask = <0xff00 0 0 7>;
> 		interrupt-map = <
> 			/* IDSEL 0x11 func 0 - PCI slot 1 */
> 			0x8800 0 0 1 &mpic 2 1
> 			0x8800 0 0 2 &mpic 3 1
> 			0x8800 0 0 3 &mpic 4 1
> 			0x8800 0 0 4 &mpic 1 1
> 			..
> 			..
> 			// IDSEL 0x1c  USB
> 			0xe000 0 0 1 &i8259 12 2
> 			0xe100 0 0 2 &i8259 9 2
> 		>;
> 
> At some point in the file they create some (dummy?) pcie section in
> which they define a uli1575, an isa bus and attached to that isa bus a
> i8259. Is this the correct way of doing things? The i8259 driver seems
> to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined
> below but how are those mapped to the south bridge? I have seen some
> code in kernel/isa-bridge, is that code indeed responsible for setting
> up these ports?
Yes, the pcie node is the PCI host bridge node and the uli1571 node acts
as PCI2ISA bridge node. AFAIK their ranges properties are parsed by
pci_process_bridge_OF_ranges().
IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
for now. The I/O addresses for the i8259 PIC are currently hardcoded and
setup (request_resource()) in sysdev/i8259.c.

> 		pcie@0 {
> 			reg = <0 0 0 0 0>;
> 			#size-cells = <2>;
> 			#address-cells = <3>;
> 			device_type = "pci";
> 			ranges = <0x02000000 0x0 0x80000000
> 				  0x02000000 0x0 0x80000000
> 				  0x0 0x20000000
> 
> 				  0x01000000 0x0 0x00000000
> 				  0x01000000 0x0 0x00000000
> 				  0x0 0x00100000>;
> 			uli1575@0 {
> 				reg = <0 0 0 0 0>;
> 				#size-cells = <2>;
> 				#address-cells = <3>;
> 				ranges = <0x02000000 0x0 0x80000000
> 					  0x02000000 0x0 0x80000000
> 					  0x0 0x20000000
> 					  0x01000000 0x0 0x00000000
> 					  0x01000000 0x0 0x00000000
> 					  0x0 0x00100000>;
> 				isa@1e {
> 					device_type = "isa";
> 					#interrupt-cells = <2>;
> 					#size-cells = <1>;
> 					#address-cells = <2>;
> 					reg = <0xf000 0 0 0 0>;
> 					ranges = <1 0 0x01000000 0 0
> 						  0x00001000>;
> 					interrupt-parent = <&i8259>;
> 
> 					i8259: interrupt-controller@20 {
> 						reg = <1 0x20 2
> 						       1 0xa0 2
> 						       1 0x4d0 2>;
> 						interrupt-controller;
> 						device_type = "interrupt-controller";
> 						#address-cells = <0>;
> 						#interrupt-cells = <2>;
> 						compatible = "chrp,iic";
> 						interrupts = <9 2>;
> 						interrupt-parent = <&mpic>;
> 					};
> 				};
> 			};
> 		};
> 
> Thanks,
> Roderick Colenbrander

best regards,

Gerhard
-- 
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

  reply	other threads:[~2009-03-14 21:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 10:32 DTS file PCI / i8259 for Xilinx ML510 Roderick Colenbrander
2009-03-14 21:54 ` Gerhard Pircher [this message]
2009-03-15  8:38   ` Roderick Colenbrander
2009-03-15 10:43     ` Gerhard Pircher
2009-03-15 11:00       ` Roderick Colenbrander
2009-03-15 13:40         ` Gerhard Pircher
2009-03-16  8:18       ` Roderick Colenbrander
2009-03-16  9:42         ` Roderick Colenbrander
  -- strict thread matches above, loose matches on Subject: below --
2009-03-12 10:43 Roderick Colenbrander

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=20090314215439.8080@gmx.net \
    --to=gerhard_pircher@gmx.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=thunderbird2k@gmx.net \
    /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).