From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p15137414.pureserver.info (matrixvision.de [217.160.213.229]) by ozlabs.org (Postfix) with ESMTP id 62ACEDDFB6 for ; Wed, 19 Mar 2008 03:44:29 +1100 (EST) Message-ID: <47DFF160.4060600@matrix-vision.de> Date: Tue, 18 Mar 2008 17:44:16 +0100 From: Andre Schwarz MIME-Version: 1.0 To: Grant Likely Subject: Re: simple MPC5200B system References: <47DD71D0.2010203@matrix-vision.de> <47DF821B.6090600@matrix-vision.de> <47DF9ABB.2020607@matrix-vision.de> <47DFDC5B.90304@matrix-vision.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080501050401080003000307" Cc: linux-ppc list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------080501050401080003000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Grant Likely schrieb: > On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz > wrote: > >> I've read some discussions about the "interrupt-map" attribute of the pci >> node. I tried to follow Ben and David in their explanations - obviously I >> didn't really get it. >> Looks like there are a lot of people outside who need some enlightenment >> ... including me, of course. >> >> Maybe you can clarify this ? >> >> Taken from motionpro.dts ... >> >> > > First, you also need to look at interrupt-map-mask to interpret these > values; from motionpro.dts: > > interrupt-map-mask = ; > > which is applied to the unit interrupt specifier to figure out how to > map onto the interrupt controller. The /size/ of this field is > obtained by adding #address-cells with #interrupt-cells. (3+1=4). > > 'f8' refers to the upper 5 bits of the interrupt identifier which is a > number from 0-31 which relates to the IDSEL line as you guessed. The > '7' covers the lower 3 bits of the interrupt specifier which can be 1, > 2, 3 or 4. > > The 120 bits in the middle are irrelevant, so interrupt-map-mask > leaves them as zeros. > > ok. >> interrupt-map = > c000 0 0 2 &mpc5200_pic 1 1 3 >> c000 0 0 3 &mpc5200_pic 1 2 3 >> c000 0 0 4 &mpc5200_pic 1 3 3 >> >> c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot >> c800 0 0 2 &mpc5200_pic 1 2 3 >> c800 0 0 3 &mpc5200_pic 1 3 3 >> c800 0 0 4 &mpc5200_pic 0 0 3>; >> >> >> First parameter seems to be the slot number, i.e. IDSEL line of the PCI >> device. >> How is this value coded ? Are these the bits 15..11 of the configuration >> address ? >> > > I don't remember how this is encoded. On the lite5200, idsel is wired > to d0 and d1 for slots 1 and 2 respectively, yet these values suggest > slots 24 and 25. I'll need to look at this again later. > > "pci info" from u-boot shows both devices (e1000 NIC + FPGA) 00 0a 4d56 1000 ff00 03 -> bus "0" , slot "0a", "irq 3" 00 0b 8086 1078 0200 02 -> bus "0" , slot "0b", "irq 2" IDSEL mapping of MPC5200 is "0b0_1011" for slot 0xb and "0b0_1010" for slot 0xa. Using those 5 bits <<= 3 for the first cell gives "5800" and "5000" >> 2nd + 3rd paramter : no clue ! can you explain ? >> > > first 3 cells are the unit address and is #address-cells large. Only > the first cell contains real data. > > ok. >> 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only >> INT_A. Do we need 4 entries in any case ? >> > > you only need entries for irq lines that are wired up. If your board > does not wire up _B, _C and _D, then don't have an entry for them. > However, if they are wired up then you should describe them. > > ok. I only have INT_A. >> 5th : ok - parent pic >> > > Correct. > > >> 6th ... 8th : IRQ representation of the parent pic, which gives : >> >> 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins >> 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have >> number 1..3 inside MAIN level. >> 8th : should be 3 = "level low" which is default for PCI. >> > > Correct. > > There is also some good information here: > http://playground.sun.com/1275/practice/imap/imap0_9d.pdf > > Cheers, > g. > > using the following "interrupt-map" give me two working PCI devices with working interrupts ... :-) interrupt-map = <5800 0 0 1 &mpc5200_pic 1 2 3 // e1000 5000 0 0 1 &mpc5200_pic 1 3 3>;// FPGA Thanks for your explanations ! regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner --------------080501050401080003000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Grant Likely schrieb:
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
  
 I've read some discussions about the "interrupt-map" attribute of the pci
node. I tried to follow Ben and David in their explanations - obviously I
didn't really get it.
 Looks like there are a lot of people outside who need some enlightenment
... including me, of course.

 Maybe you can clarify this ?

 Taken from motionpro.dts ...

    

First, you also need to look at interrupt-map-mask to interpret these
values; from motionpro.dts:

interrupt-map-mask = <f800 0 0 7>;

which is applied to the unit interrupt specifier to figure out how to
map onto the interrupt controller.  The /size/ of this field is
obtained by adding #address-cells with #interrupt-cells. (3+1=4).

'f8' refers to the upper 5 bits of the interrupt identifier which is a
number from 0-31 which relates to the IDSEL line as you guessed.  The
'7' covers the lower 3 bits of the interrupt specifier which can be 1,
2, 3 or 4.

The 120 bits in the middle are irrelevant, so interrupt-map-mask
leaves them as zeros.

  

ok.

  
     interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
                                  c000 0 0 2 &mpc5200_pic 1 1 3
                                  c000 0 0 3 &mpc5200_pic 1 2 3
                                  c000 0 0 4 &mpc5200_pic 1 3 3

                                  c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
                                  c800 0 0 2 &mpc5200_pic 1 2 3
                                  c800 0 0 3 &mpc5200_pic 1 3 3
                                  c800 0 0 4 &mpc5200_pic 0 0 3>;


 First parameter seems to be the slot number, i.e. IDSEL line of the PCI
device.
 How is this value coded ? Are these the bits 15..11 of the configuration
address ?
    

I don't remember how this is encoded.  On the lite5200, idsel is wired
to d0 and d1 for slots 1 and 2 respectively, yet these values suggest
slots 24 and 25.  I'll need to look at this again later.

  
"pci info" from u-boot shows both devices (e1000 NIC + FPGA)
       00  0a  4d56  1000  ff00  03    -> bus "0" , slot "0a", "irq 3"
       00  0b  8086  1078  0200  02   -> bus "0" , slot "0b", "irq 2"

IDSEL mapping of MPC5200 is "0b0_1011" for slot 0xb and "0b0_1010" for slot 0xa.
Using those 5 bits <<= 3  for the first cell gives "5800" and "5000"


  
 2nd + 3rd paramter : no clue ! can you explain ?
    

first 3 cells are the unit address and is #address-cells large.  Only
the first cell contains real data.

  
ok.

  
 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
INT_A. Do we need 4 entries in any case ?
    

you only need entries for irq lines that are wired up.  If your board
does not wire up _B, _C and _D, then don't have an entry for them.
However, if they are wired up then you should describe them.

  
ok. I only have INT_A.

  
 5th : ok - parent pic
    

Correct.

  
 6th ... 8th  : IRQ representation of the parent pic, which gives :

     6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
     7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
number 1..3 inside MAIN level.
     8th : should be 3 = "level low" which is default for PCI.
    

Correct.

There is also some good information here:
http://playground.sun.com/1275/practice/imap/imap0_9d.pdf

Cheers,
g.

  
using the following "interrupt-map" give me two working PCI devices with working interrupts ... :-)

interrupt-map = <5800 0 0 1 &mpc5200_pic 1 2 3  // e1000
                             5000 0 0 1 &mpc5200_pic 1 3 3>;// FPGA


Thanks for your explanations !


regards,
Andre


MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--------------080501050401080003000307--