ARCH=ppc -> ARCH=powerpc : help needed for dts file

ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi all,

I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).

Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.

I have copied the mpc8540ads.dts file to a new dts file, and added the
following :

			i2c@3000 {
	+                       #address-cells = <1>;
	+                       #size-cells = <0>;
				device_type = "i2c";
				compatible = "fsl-i2c";
				reg = <3000 100>;
				interrupts = <2b 2>;
				interrupt-parent = <&mpic>;
				dfsrr;
	+
	+                       rtc@68 {
	+                               compatible = "stm,m41t81";
	+                               reg = <68>;
	+                       };
			};

and I see in the boot log that my RTC chip is now working.


My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :

	Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
	Yenta: Using CSCINT to route CSC interrupts to PCI
	Yenta: Routing CardBus interrupts to PCI
	Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
	irq 18: nobody cared (try booting with the "irqpoll" option)
	Call Trace:
	[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
	[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
	[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
	[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8

but my boot finally fails with :

	VFS: Cannot open root device "hda1" or unknown-block(0,0)
	Please append a correct "root=" boot option; here are the
	available partitions:
	1f00       8192 mtdblock0 (driver?)
	Kernel panic - not syncing: VFS: Unable to mount root fs
	on unknown-block(0,0)

Is there an easy way to use values found in /proc or even in the sources
in my working ppc setup to put them in the dts file to make my new powerpc
configuration work ?

Thanks for listening

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Grant Likely]

On Mon, Mar 3, 2008 at 7:47 AM, Philippe De Muyter <phdm@macqel.be> wrote:
>  My root device is on a compact-flash connected to a PCI yenta chip from TI,
>  and this one is not working, altough it seems to be discovered :
>
>         Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
>         Yenta: Using CSCINT to route CSC interrupts to PCI
>         Yenta: Routing CardBus interrupts to PCI
>         Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
>         irq 18: nobody cared (try booting with the "irqpoll" option)
>         Call Trace:
>         [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
>         [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
>         [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
>         [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
>
>  but my boot finally fails with :
>
>         VFS: Cannot open root device "hda1" or unknown-block(0,0)
>         Please append a correct "root=" boot option; here are the
>         available partitions:
>         1f00       8192 mtdblock0 (driver?)
>         Kernel panic - not syncing: VFS: Unable to mount root fs
>         on unknown-block(0,0)
>
>  Is there an easy way to use values found in /proc or even in the sources
>  in my working ppc setup to put them in the dts file to make my new powerpc
>  configuration work ?

It does not look like you are having dts problems.  Once your in the
PCI domain, Linux will probe the devices (as your boot log shows).
Rather, your boot failure is due to the yenta device failure.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Scott Wood]

On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> My root device is on a compact-flash connected to a PCI yenta chip from TI,
> and this one is not working, altough it seems to be discovered :
> 
> 	Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> 	Yenta: Using CSCINT to route CSC interrupts to PCI
> 	Yenta: Routing CardBus interrupts to PCI
> 	Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> 	irq 18: nobody cared (try booting with the "irqpoll" option)
> 	Call Trace:
> 	[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> 	[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> 	[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> 	[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8

Maybe your PCI interrupt-map is wrong...

-Scott

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Scott,

On Mon, Mar 03, 2008 at 11:07:20AM -0600, Scott Wood wrote:
> On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> > My root device is on a compact-flash connected to a PCI yenta chip from TI,
> > and this one is not working, altough it seems to be discovered :
> > 
> > 	Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> > 	Yenta: Using CSCINT to route CSC interrupts to PCI
> > 	Yenta: Routing CardBus interrupts to PCI
> > 	Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> > 	irq 18: nobody cared (try booting with the "irqpoll" option)
> > 	Call Trace:
> > 	[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> > 	[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> > 	[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> > 	[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
> 
> Maybe your PCI interrupt-map is wrong...

Is the PCI-interrupt map that part of the dts file :

                interrupt-map = <

                        /* IDSEL 0x02 */
                        1000 0 0 1 &mpic 1 1
                        1000 0 0 2 &mpic 2 1
                        1000 0 0 3 &mpic 3 1
                        1000 0 0 4 &mpic 4 1

                        /* IDSEL 0x03 */
                        1800 0 0 1 &mpic 4 1
                        1800 0 0 2 &mpic 1 1
                        1800 0 0 3 &mpic 2 1
                        1800 0 0 4 &mpic 3 1

			...

I do not understand anything there :(

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Scott Wood]

Philippe De Muyter wrote:
> Is the PCI-interrupt map that part of the dts file :
> 
>                 interrupt-map = <
> 
>                         /* IDSEL 0x02 */
>                         1000 0 0 1 &mpic 1 1
>                         1000 0 0 2 &mpic 2 1
>                         1000 0 0 3 &mpic 3 1
>                         1000 0 0 4 &mpic 4 1
> 
>                         /* IDSEL 0x03 */
>                         1800 0 0 1 &mpic 4 1
>                         1800 0 0 2 &mpic 1 1
>                         1800 0 0 3 &mpic 2 1
>                         1800 0 0 4 &mpic 3 1
> 
> 			...

Yes.

> I do not understand anything there :(

It maps PCI interrupts to mpic interrupts.  The first three cells are 
the PCI address (only the device number is unmasked), then the PCI 
interrupt (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt 
controller, then the interrupt specifier for the parent controller.

-Scott

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Scott,

On Mon, Mar 03, 2008 at 03:11:08PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> Is the PCI-interrupt map that part of the dts file :
>>                 interrupt-map = <
>>                         /* IDSEL 0x02 */
>>                         1000 0 0 1 &mpic 1 1
>>                         1000 0 0 2 &mpic 2 1
>>                         1000 0 0 3 &mpic 3 1
>>                         1000 0 0 4 &mpic 4 1
>>                         /* IDSEL 0x03 */
>>                         1800 0 0 1 &mpic 4 1
>>                         1800 0 0 2 &mpic 1 1
>>                         1800 0 0 3 &mpic 2 1
>>                         1800 0 0 4 &mpic 3 1
>> 			...
>
> Yes.
>
>> I do not understand anything there :(
>
> It maps PCI interrupts to mpic interrupts.  The first three cells are the 
> PCI address (only the device number is unmasked), then the PCI interrupt 
> (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt controller, 
> then the interrupt specifier for the parent controller.

Thanks

The following seems important also :

/*
                interrupts = <18 2>;
*/
                /* interrupts number are coded in hexa ! */
                interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;

I have replaced the interrupts spec in comments by the longer interrupts spec
below, and it seems to have some positive effect, but I do not know
precisely what I have described there.

I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
interrupts numbers that I had in the ARCH=ppc version.  I added 18 because
of the error message, but it did not help.

What should be described here and how ?

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

> Thanks
> 
> The following seems important also :
> 
> /*
>                 interrupts = <18 2>;
> */
>                 /* interrupts number are coded in hexa ! */
>                 interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
> 
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below, and it seems to have some positive effect, but I do not know
> precisely what I have described there.
> 
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version.  I added 18 because
> of the error message, but it did not help.

Where is this ? (What node ?) The above looks like the interrupt spec
for a single device with 7 interrupts, is that what you are trying to
do ?

If not, then it's incorrect, you have to figure the interrupt-map out
(it's really not -that- hard).

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

On Tue, Mar 04, 2008 at 08:41:33AM +1100, Benjamin Herrenschmidt wrote:
> 
> > Thanks
> > 
> > The following seems important also :
> > 
> > /*
> >                 interrupts = <18 2>;
> > */
> >                 /* interrupts number are coded in hexa ! */
> >                 interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
> > 
> > I have replaced the interrupts spec in comments by the longer interrupts spec
> > below, and it seems to have some positive effect, but I do not know
> > precisely what I have described there.
> > 
> > I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> > interrupts numbers that I had in the ARCH=ppc version.  I added 18 because
> > of the error message, but it did not help.
> 
> Where is this ? (What node ?) The above looks like the interrupt spec
> for a single device with 7 interrupts, is that what you are trying to
> do ?

Well, the yenta device is a multi-function PCI peripheral that has two
pcmcia/pccard/compactflash slots and one ohci1394 interface.

Here's what uboot shows :
	PCI Scan: Found Bus 0, Device 18, Function 0
		00  12  104c  ac46  0607  ff
	PCI Scan: Found Bus 0, Device 18, Function 1
		00  12  104c  ac46  0607  ff
	PCI Scan: Found Bus 0, Device 18, Function 2
		00  12  104c  802a  0c00  00

and here is what /proc/interrupts shows in my ARCH=ppc dts-less running linux :
	root:~# cat /proc/interrupts
		   CPU0
	 25:          0   OpenPIC   Level     gfar_interrupt
	 26:        245   OpenPIC   Level     serial
	 27:          0   OpenPIC   Level     i2c-mpc
	 55:      18797   OpenPIC   Level     yenta, ide0
	 54:          1   OpenPIC   Level     yenta
	 55:         79   OpenPIC   Level     ohci1394
	BAD:          0
> 
> If not, then it's incorrect, you have to figure the interrupt-map out
> (it's really not -that- hard).

If I knew where to look at, and what I must produce, I'd agree with you :)

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Scott Wood]

Philippe De Muyter wrote:
> The following seems important also :
> 
> /*
>                 interrupts = <18 2>;
> */
>                 /* interrupts number are coded in hexa ! */
>                 interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
> 
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below,

Why?

> and it seems to have some positive effect,

What kind of positive effect?  I'd think the extra interrupts would just 
be ignored.  The interrupts property for the PCI node itself is 
generally for error reporting.

> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version.  I added 18 because
> of the error message, but it did not help.

What ARCH=ppc version?  There are no device trees for non-OF boards in 
arch/ppc.

-Scott

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Scott,

On Mon, Mar 03, 2008 at 03:55:26PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> The following seems important also :
>> /*
>>                 interrupts = <18 2>;
>> */
>>                 /* interrupts number are coded in hexa ! */
>>                 interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>> I have replaced the interrupts spec in comments by the longer interrupts 
>> spec
>> below,
>
> Why?

because of the error message regarding unhandled interrupt.  As I wrote I do
not know anything about dts files, just that it is needed to have one
for a non OF board if I want to use the ARCH=powerpc tree.

>
>> and it seems to have some positive effect,
>
> What kind of positive effect?  I'd think the extra interrupts would just be 
> ignored.  The interrupts property for the PCI node itself is generally for 
> error reporting.

My compact-flash device is discovered, but interrupts still do not work.
In the log, at the end of the boot,
this :

	rtc-m41t80 0-0068: hctosys: invalid date/time
	Waiting 3sec before mounting root device...
	VFS: Cannot open root device "hda1" or unknown-block(0,0)
	Please append a correct "root=" boot option; here are the
	available partitions:
	1f00       1920 mtdblock0 (driver?)
	1f01       1920 mtdblock1 (driver?)
	1f02       1920 mtdblock2 (driver?)
	1f03       1920 mtdblock3 (driver?)
	1f04        512 mtdblock4 (driver?)
	Kernel panic - not syncing: VFS: Unable to mount root fs on
	unknown-block(0,0)
	Rebooting in 180 seconds.. 

is replaced by that :

	hda: TRANSCEND, CFA DISK drive
	ide0 at 0x000-0x007,0x00e on irq 18
	hda: max request size: 128KiB
	hda: 8077104 sectors (4135 MB) w/1KiB Cache, CHS=8013/16/63
	 hda:<4>hda: lost interrupt
	[same message repeated]
	hda: lost interrupt
	 hda1
	ide-cs: hda: Vpp = 0.0
	rtc-m41t80 0-0068: hctosys: invalid date/time
	Waiting 3sec before mounting root device...
	hda: lost interrupt
	[same message repeated]
	EXT2-fs warning (device hda1): ext2_fill_super: mounting ext3 filesystem as ext2
	VFS: Mounted root (ext2 filesystem) readonly.
	Freeing unused kernel memory: 116k init
	hda: lost interrupt
	[same message repeated]
>
>> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are 
>> the
>> interrupts numbers that I had in the ARCH=ppc version.  I added 18 because
>> of the error message, but it did not help.
>
> What ARCH=ppc version?  There are no device trees for non-OF boards in 
> arch/ppc.

With ARCH=ppc, all those interrupt's info's are hardcoded in the .c files.
But I expected I could fill the dts file for ARCH=powerpc from info's I
could collect in /proc on a running ARCH=ppc linux without dts file
for the same board.

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

On Tue, 2008-03-04 at 09:08 +0100, Philippe De Muyter wrote:
> With ARCH=ppc, all those interrupt's info's are hardcoded in the .c
> files.
> But I expected I could fill the dts file for ARCH=powerpc from info's
> I
> could collect in /proc on a running ARCH=ppc linux without dts file
> for the same board.

Rather, look at the C file. Send it and we can help figuring things out.

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

[-- Attachment #1: Type: text/plain, Size: 3486 bytes --]

Hi Ben,

On Tue, Mar 04, 2008 at 07:22:19PM +1100, Benjamin Herrenschmidt wrote:
> 
> On Tue, 2008-03-04 at 09:08 +0100, Philippe De Muyter wrote:
> > With ARCH=ppc, all those interrupt's info's are hardcoded in the .c
> > files.
> > But I expected I could fill the dts file for ARCH=powerpc from info's
> > I
> > could collect in /proc on a running ARCH=ppc linux without dts file
> > for the same board.
> 
> Rather, look at the C file. Send it and we can help figuring things out.

Thanks in advance

Philippe

I also attach my current (not working) dts file attempt.  It is actually
a modified mpc8540ads.dts file.

I now thinks that the ide-cs (hda) discovery or not depends on the cold
or warm reboot.

Here are the patches for my config (MEIP_8540) relative to a vanilla
linux-2.6.24.  I hacked the MPC8540ADS config. The PCI4520 is the
multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port
phy)

--- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.cbk	2008-01-24 22:58:37.000000000 +0000
+++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.c	2008-02-20 16:54:33.000000000 +0000
@@ -58,6 +58,29 @@
 /* Internal interrupts are all Level Sensitive, and Positive Polarity */
 static u_char mpc85xx_ads_openpic_initsenses[] __initdata = {
 	MPC85XX_INTERNAL_IRQ_SENSES,
+#ifdef CONFIG_MEIP_8540
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 0 : nINTPFO
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 1 : nINTRTC
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 2 : nINTPLD
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 3 : nINTSTX
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 4 : nINTPHY
+#if defined(CONFIG_PCI)
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 5 : PCI4520 MFUNC 0 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 6 : PCI4520 MFUNC 1 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 7 : PCI4520 MFUNC 2 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 8 : PCI4520 MFUNC 3 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 9 : PCI4520 MFUNC 4 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 10 : PCI4520 MFUNC 5 */
+	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 11 : PCI4520 MFUNC 6 */
+#else
+	0x0,						/* External  6: */
+	0x0,						/* External  7: */
+	0x0,						/* External  8: */
+	0x0,						/* External  9: */
+	0x0,						/* External 10: */
+	0x0,						/* External 11: */
+#endif
+#else
 	0x0,						/* External  0: */
 #if defined(CONFIG_PCI)
 	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	/* External 1: PCI slot 0 */
@@ -77,6 +100,7 @@
 	0x0,				/* External  9: */
 	0x0,				/* External 10: */
 	0x0,				/* External 11: */
+#endif
 };
 
 /* ************************************************************************ */
--- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk	2008-01-24 22:58:37.000000000 +0000
+++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h	2008-02-20 16:36:07.000000000 +0000
@@ -29,10 +29,17 @@
 extern void mpc85xx_ads_map_io(void) __init;
 
 /* PCI interrupt controller */
+#ifdef CONFIG_MEIP_8540
+#define PIRQA		MPC85xx_IRQ_EXT5
+#define PIRQB		MPC85xx_IRQ_EXT6
+#define PIRQC		MPC85xx_IRQ_EXT7
+#define PIRQD		MPC85xx_IRQ_EXT8
+#else
 #define PIRQA		MPC85xx_IRQ_EXT1
 #define PIRQB		MPC85xx_IRQ_EXT2
 #define PIRQC		MPC85xx_IRQ_EXT3
 #define PIRQD		MPC85xx_IRQ_EXT4
+#endif
 
 #define MPC85XX_PCI1_LOWER_IO	0x00000000
 #define MPC85XX_PCI1_UPPER_IO	0x00ffffff

[-- Attachment #2: meip-8540.dts --]
[-- Type: text/plain, Size: 6576 bytes --]

/*
 * MEIP-8540 Device Tree Source
 *
 * Copyright 2008 Macq Electronique SA
 *
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */


/ {
	model = "MEIP8540";
	compatible = "MEIP8540", "MPC85xxADS";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,8540@0 {
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <20>;	// 32 bytes
			i-cache-line-size = <20>;	// 32 bytes
			d-cache-size = <8000>;		// L1, 32K
			i-cache-size = <8000>;		// L1, 32K
			timebase-frequency = <0>;	//  33 MHz, from uboot
			bus-frequency = <0>;	// 166 MHz
			clock-frequency = <0>;	// 825 MHz, from uboot
		};
	};

	memory {
		device_type = "memory";
		reg = <00000000 10000000>;	// 256M at 0x0
	};

	soc8540@e0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		device_type = "soc";
		ranges = <0 e0000000 00100000>;
		reg = <e0000000 00100000>;	// CCSRBAR 1M
		bus-frequency = <0>;

		memory-controller@2000 {
			compatible = "fsl,8540-memory-controller";
			reg = <2000 1000>;
			interrupt-parent = <&mpic>;
			interrupts = <12 2>;
		};

		l2-cache-controller@20000 {
			compatible = "fsl,8540-l2-cache-controller";
			reg = <20000 1000>;
			cache-line-size = <20>;	// 32 bytes
			cache-size = <40000>;	// L2, 256K
			interrupt-parent = <&mpic>;
			interrupts = <10 2>;
		};

		i2c@3000 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "i2c";
			compatible = "fsl-i2c";
			reg = <3000 100>;
			interrupts = <2b 2>;
			interrupt-parent = <&mpic>;
			dfsrr;

			rtc@68 {
				compatible = "stm,m41t81";
				reg = <68>;
			};
		};

		mdio@24520 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "mdio";
			compatible = "gianfar";
			reg = <24520 20>;
			phy0: ethernet-phy@0 {
				interrupt-parent = <&mpic>;
				interrupts = <5 1>;
				reg = <0>;
				device_type = "ethernet-phy";
			};
			phy1: ethernet-phy@1 {
				interrupt-parent = <&mpic>;
				interrupts = <5 1>;
				reg = <1>;
				device_type = "ethernet-phy";
			};
			phy3: ethernet-phy@3 {
				interrupt-parent = <&mpic>;
				interrupts = <7 1>;
				reg = <3>;
				device_type = "ethernet-phy";
			};
		};

		ethernet@24000 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "network";
			model = "TSEC";
			compatible = "gianfar";
			reg = <24000 1000>;
			/*
			 * address is deprecated and will be removed
			 * in 2.6.25.  Only recent versions of
			 * U-Boot support local-mac-address, however.
			 */
			address = [ 00 00 00 00 00 00 ];
			local-mac-address = [ 00 00 00 00 00 00 ];
			interrupts = <1d 2 1e 2 22 2>;
			interrupt-parent = <&mpic>;
			phy-handle = <&phy0>;
		};

		ethernet@25000 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "network";
			model = "TSEC";
			compatible = "gianfar";
			reg = <25000 1000>;
			/*
			 * address is deprecated and will be removed
			 * in 2.6.25.  Only recent versions of
			 * U-Boot support local-mac-address, however.
			 */
			address = [ 00 00 00 00 00 00 ];
			local-mac-address = [ 00 00 00 00 00 00 ];
			interrupts = <23 2 24 2 28 2>;
			interrupt-parent = <&mpic>;
			phy-handle = <&phy1>;
		};

		ethernet@26000 {
			#address-cells = <1>;
			#size-cells = <0>;
			device_type = "network";
			model = "FEC";
			compatible = "gianfar";
			reg = <26000 1000>;
			/*
			 * address is deprecated and will be removed
			 * in 2.6.25.  Only recent versions of
			 * U-Boot support local-mac-address, however.
			 */
			address = [ 00 00 00 00 00 00 ];
			local-mac-address = [ 00 00 00 00 00 00 ];
			interrupts = <29 2>;
			interrupt-parent = <&mpic>;
			phy-handle = <&phy3>;
		};

		serial@4500 {
			device_type = "serial";
			compatible = "ns16550";
			reg = <4500 100>; 	// reg base, size
			clock-frequency = <0>; 	// should we fill in in uboot?
/*
			interrupts = <2a 2>;
*/
			interrupts = <1a 2>;
			interrupt-parent = <&mpic>;
		};

		serial@4600 {
			device_type = "serial";
			compatible = "ns16550";
			reg = <4600 100>;	// reg base, size
			clock-frequency = <0>; 	// should we fill in in uboot?
/*
			interrupts = <2a 2>;
*/
			interrupts = <1a 2>;
			interrupt-parent = <&mpic>;
		};
		mpic: pic@40000 {
			clock-frequency = <0>;
			interrupt-controller;
			#address-cells = <0>;
			#interrupt-cells = <2>;
			reg = <40000 40000>;
			compatible = "chrp,open-pic";
			device_type = "open-pic";
			big-endian;
		};
	};

	pci@e0008000 {
		interrupt-map-mask = <f800 0 0 7>;
		interrupt-map = <

			/* IDSEL 0x02 */
			1000 0 0 1 &mpic 1 1
			1000 0 0 2 &mpic 2 1
			1000 0 0 3 &mpic 3 1
			1000 0 0 4 &mpic 4 1

			/* IDSEL 0x03 */
			1800 0 0 1 &mpic 4 1
			1800 0 0 2 &mpic 1 1
			1800 0 0 3 &mpic 2 1
			1800 0 0 4 &mpic 3 1

			/* IDSEL 0x04 */
			2000 0 0 1 &mpic 3 1
			2000 0 0 2 &mpic 4 1
			2000 0 0 3 &mpic 1 1
			2000 0 0 4 &mpic 2 1

			/* IDSEL 0x05 */
			2800 0 0 1 &mpic 2 1
			2800 0 0 2 &mpic 3 1
			2800 0 0 3 &mpic 4 1
			2800 0 0 4 &mpic 1 1

			/* IDSEL 0x0c */
			6000 0 0 1 &mpic 1 1
			6000 0 0 2 &mpic 2 1
			6000 0 0 3 &mpic 3 1
			6000 0 0 4 &mpic 4 1

			/* IDSEL 0x0d */
			6800 0 0 1 &mpic 4 1
			6800 0 0 2 &mpic 1 1
			6800 0 0 3 &mpic 2 1
			6800 0 0 4 &mpic 3 1

			/* IDSEL 0x0e */
			7000 0 0 1 &mpic 3 1
			7000 0 0 2 &mpic 4 1
			7000 0 0 3 &mpic 1 1
			7000 0 0 4 &mpic 2 1

			/* IDSEL 0x0f */
			7800 0 0 1 &mpic 2 1
			7800 0 0 2 &mpic 3 1
			7800 0 0 3 &mpic 4 1
			7800 0 0 4 &mpic 1 1

			/* IDSEL 0x12 */
			9000 0 0 1 &mpic 1 1
			9000 0 0 2 &mpic 2 1
			9000 0 0 3 &mpic 3 1
			9000 0 0 4 &mpic 4 1

			/* IDSEL 0x13 */
			9800 0 0 1 &mpic 4 1
			9800 0 0 2 &mpic 1 1
			9800 0 0 3 &mpic 2 1
			9800 0 0 4 &mpic 3 1

			/* IDSEL 0x14 */
			a000 0 0 1 &mpic 3 1
			a000 0 0 2 &mpic 4 1
			a000 0 0 3 &mpic 1 1
			a000 0 0 4 &mpic 2 1

			/* IDSEL 0x15 */
			a800 0 0 1 &mpic 2 1
			a800 0 0 2 &mpic 3 1
			a800 0 0 3 &mpic 4 1
			a800 0 0 4 &mpic 1 1>;
		interrupt-parent = <&mpic>;
		/* interrupts number are coded in hexa ! */
/*
		interrupts = <18 2>;
		interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
*/
		interrupts = <35 2 36 2 37 2>;
		bus-range = <0 0>;
		ranges = <02000000 0 80000000 80000000 0 20000000
			  01000000 0 00000000 e2000000 0 00100000>;
		clock-frequency = <3f940aa>;
		#interrupt-cells = <1>;
		#size-cells = <2>;
		#address-cells = <3>;
		reg = <e0008000 1000>;
		compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
		device_type = "pci";
	};
};

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[David Gibson]

On Tue, Mar 04, 2008 at 10:10:59AM +0100, Philippe De Muyter wrote:
> Hi Ben,
> 
> On Tue, Mar 04, 2008 at 07:22:19PM +1100, Benjamin Herrenschmidt wrote:

These comments aren't relevant to the problems you're seeing, but
they're a good idea for writing device trees in general.

First, you may want to consider moving to the version 1 dts format
which uses C-style integer values throughout, instead of hex by
default.

[snip]
> 		i2c@3000 {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			device_type = "i2c";

device_type shouldn't be included here.

> 			compatible = "fsl-i2c";
> 			reg = <3000 100>;
> 			interrupts = <2b 2>;
> 			interrupt-parent = <&mpic>;
> 			dfsrr;
> 
> 			rtc@68 {
> 				compatible = "stm,m41t81";
> 				reg = <68>;
> 			};
> 		};
> 
> 		mdio@24520 {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			device_type = "mdio";
> 			compatible = "gianfar";
[snip]
> 		ethernet@24000 {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			device_type = "network";
> 			model = "TSEC";
> 			compatible = "gianfar";

The binding for gianfar mdio and ethernet devices has been updated to
better fit conventions for use of device_type and compatible
properties.  Check booting-without-of.txt for the details.

Can someone from freescale please go though and update the existing
device trees, so that people stop copying the old crap.

[snip]
> 		ethernet@24000 {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			device_type = "network";
> 			model = "TSEC";
> 			compatible = "gianfar";
> 			reg = <24000 1000>;
> 			/*
> 			 * address is deprecated and will be removed
> 			 * in 2.6.25.  Only recent versions of
> 			 * U-Boot support local-mac-address, however.
> 			 */
> 			address = [ 00 00 00 00 00 00 ];

And since this is a new port, you ought to be able to use a recent
u-boot and drop this backwards compatibility property.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

> I also attach my current (not working) dts file attempt.  It is actually
> a modified mpc8540ads.dts file.
> 
> I now thinks that the ide-cs (hda) discovery or not depends on the cold
> or warm reboot.
> 
> Here are the patches for my config (MEIP_8540) relative to a vanilla
> linux-2.6.24.  I hacked the MPC8540ADS config. The PCI4520 is the
> multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port
> phy)

 .../...

> +#ifdef CONFIG_MEIP_8540
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 0 : nINTPFO
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 1 : nINTRTC
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 2 : nINTPLD
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 3 : nINTSTX
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 4 : nINTPHY
> +#if defined(CONFIG_PCI)
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 5 : PCI4520 MFUNC 0 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 6 : PCI4520 MFUNC 1 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 7 : PCI4520 MFUNC 2 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 8 : PCI4520 MFUNC 3 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 9 : PCI4520 MFUNC 4 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 10 : PCI4520 MFUNC 5 */
> +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 11 : PCI4520 MFUNC 6 */
> +#else
> +	0x0,						/* External  6: */
> +	0x0,						/* External  7: */
> +	0x0,						/* External  8: */
> +	0x0,						/* External  9: */
> +	0x0,						/* External 10: */
> +	0x0,						/* External 11: */
> +#endif
> +#else
>  	0x0,						/* External  0: */
>  #if defined(CONFIG_PCI)
>  	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	/* External 1: PCI slot 0 */
> @@ -77,6 +100,7 @@
>  	0x0,				/* External  9: */
>  	0x0,				/* External 10: */
>  	0x0,				/* External 11: */
> +#endif
>  };

Ok, so based on the above, I deduce that you have 12 external interrupt
sources:

0...4 are those nINT* things. They correspond apparently do discrete
devices on your board. You will have to create device nodes in your .dts
for these with the appropriate interrupts property for each of these.

The rest are ... hrm... weird. You -appear- to have 5 to 8 going to PCI,
to PIRQA...D. Do that mean that you have wired your connectors on the board
such that the interrupt does not depend on the actual slot number ?

Or are you doing some swizzling ?

Also, I would need to know how those external IRQs are connected to the MPIC,
I don't have the spec of that chip here. Hrm. Somebody from freescale can
help him here ?

It's also not clear to me what your interrupts 9 10 and 11 are since you
seem to only talk about PIRQA...D which is only 4 lines ..

So at this stage, that's not enough information. We need to know exactly how
you have wired things on your board, and somebody from fsl needs to tell
me how the ExtIrq are routed to the MPIC on that guy.

Once that's done, you seem to have grasped the interrupt map... for any
device or slot, you provide the mapping between idsel/pirq line on one side,
and mpic interrupt & sense on the other. For PCI, sense is always 1 for an
mpic so you mostly have to check your actual MPIC source numbers.

>From your .dts, I see you've been doing some swizzling of slots using
interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?

Ben.

>  
>  /* ************************************************************************ */
> --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk	2008-01-24 22:58:37.000000000 +0000
> +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h	2008-02-20 16:36:07.000000000 +0000
> @@ -29,10 +29,17 @@
>  extern void mpc85xx_ads_map_io(void) __init;
>  
>  /* PCI interrupt controller */
> +#ifdef CONFIG_MEIP_8540
> +#define PIRQA		MPC85xx_IRQ_EXT5
> +#define PIRQB		MPC85xx_IRQ_EXT6
> +#define PIRQC		MPC85xx_IRQ_EXT7
> +#define PIRQD		MPC85xx_IRQ_EXT8
> +#else
>  #define PIRQA		MPC85xx_IRQ_EXT1
>  #define PIRQB		MPC85xx_IRQ_EXT2
>  #define PIRQC		MPC85xx_IRQ_EXT3
>  #define PIRQD		MPC85xx_IRQ_EXT4
> +#endif
>  
>  #define MPC85XX_PCI1_LOWER_IO	0x00000000
>  #define MPC85XX_PCI1_UPPER_IO	0x00ffffff

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

thanks for all the answers,

On Wed, Mar 05, 2008 at 04:01:04PM +1100, Benjamin Herrenschmidt wrote:
> 
> > I also attach my current (not working) dts file attempt.  It is actually
> > a modified mpc8540ads.dts file.
> > 
> > I now thinks that the ide-cs (hda) discovery or not depends on the cold
> > or warm reboot.
> > 
> > Here are the patches for my config (MEIP_8540) relative to a vanilla
> > linux-2.6.24.  I hacked the MPC8540ADS config. The PCI4520 is the
> > multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port
> > phy)
> 
>  .../...
> 
> > +#ifdef CONFIG_MEIP_8540
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 0 : nINTPFO
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 1 : nINTRTC
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 2 : nINTPLD
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 3 : nINTSTX
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	// External 4 : nINTPHY
> > +#if defined(CONFIG_PCI)
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 5 : PCI4520 MFUNC 0 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 6 : PCI4520 MFUNC 1 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 7 : PCI4520 MFUNC 2 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 8 : PCI4520 MFUNC 3 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 9 : PCI4520 MFUNC 4 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 10 : PCI4520 MFUNC 5 */
> > +	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),      /* External 11 : PCI4520 MFUNC 6 */
> > +#else
> > +	0x0,						/* External  6: */
> > +	0x0,						/* External  7: */
> > +	0x0,						/* External  8: */
> > +	0x0,						/* External  9: */
> > +	0x0,						/* External 10: */
> > +	0x0,						/* External 11: */
> > +#endif
> > +#else
> >  	0x0,						/* External  0: */
> >  #if defined(CONFIG_PCI)
> >  	(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE),	/* External 1: PCI slot 0 */
> > @@ -77,6 +100,7 @@
> >  	0x0,				/* External  9: */
> >  	0x0,				/* External 10: */
> >  	0x0,				/* External 11: */
> > +#endif
> >  };
> 
> Ok, so based on the above, I deduce that you have 12 external interrupt
> sources:
> 
> 0...4 are those nINT* things. They correspond apparently do discrete
> devices on your board. You will have to create device nodes in your .dts
> for these with the appropriate interrupts property for each of these.
> 
> The rest are ... hrm... weird. You -appear- to have 5 to 8 going to PCI,
> to PIRQA...D. Do that mean that you have wired your connectors on the board
> such that the interrupt does not depend on the actual slot number ?

I asked the guy who designed the hardware, and if I understand correctly :

- the i/o and memory resources of the pci device are connected to the pci bus
- the interrupts are directly connected to the MPIC

Can I describe that in the dts file ?

Philippe

> 
> Or are you doing some swizzling ?
> 
> Also, I would need to know how those external IRQs are connected to the MPIC,
> I don't have the spec of that chip here. Hrm. Somebody from freescale can
> help him here ?
> 
> It's also not clear to me what your interrupts 9 10 and 11 are since you
> seem to only talk about PIRQA...D which is only 4 lines ..
> 
> So at this stage, that's not enough information. We need to know exactly how
> you have wired things on your board, and somebody from fsl needs to tell
> me how the ExtIrq are routed to the MPIC on that guy.
> 
> Once that's done, you seem to have grasped the interrupt map... for any
> device or slot, you provide the mapping between idsel/pirq line on one side,
> and mpic interrupt & sense on the other. For PCI, sense is always 1 for an
> mpic so you mostly have to check your actual MPIC source numbers.
> 
> >From your .dts, I see you've been doing some swizzling of slots using
> interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> 
> Ben.
> 
> >  
> >  /* ************************************************************************ */
> > --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk	2008-01-24 22:58:37.000000000 +0000
> > +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h	2008-02-20 16:36:07.000000000 +0000
> > @@ -29,10 +29,17 @@
> >  extern void mpc85xx_ads_map_io(void) __init;
> >  
> >  /* PCI interrupt controller */
> > +#ifdef CONFIG_MEIP_8540
> > +#define PIRQA		MPC85xx_IRQ_EXT5
> > +#define PIRQB		MPC85xx_IRQ_EXT6
> > +#define PIRQC		MPC85xx_IRQ_EXT7
> > +#define PIRQD		MPC85xx_IRQ_EXT8
> > +#else
> >  #define PIRQA		MPC85xx_IRQ_EXT1
> >  #define PIRQB		MPC85xx_IRQ_EXT2
> >  #define PIRQC		MPC85xx_IRQ_EXT3
> >  #define PIRQD		MPC85xx_IRQ_EXT4
> > +#endif
> >  
> >  #define MPC85XX_PCI1_LOWER_IO	0x00000000
> >  #define MPC85XX_PCI1_UPPER_IO	0x00ffffff

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote:
> 
> I asked the guy who designed the hardware, and if I understand
> correctly :
> 
> - the i/o and memory resources of the pci device are connected to the
> pci bus
> - the interrupts are directly connected to the MPIC
> 
> Can I describe that in the dts file ?

Sure, you can describe pretty much any interrupt routing, provided that
we know -how- (ie. where) they are connected. We also need to know the
idsel of the devices. (The later we can deduce from lspci done in
arch/ppc).

Ben.

> Philippe
> 
> > 
> > Or are you doing some swizzling ?
> > 
> > Also, I would need to know how those external IRQs are connected to
> the MPIC,
> > I don't have the spec of that chip here. Hrm. Somebody from
> freescale can
> > help him here ?
> > 
> > It's also not clear to me what your interrupts 9 10 and 11 are since
> you
> > seem to only talk about PIRQA...D which is only 4 lines ..
> > 
> > So at this stage, that's not enough information. We need to know
> exactly how
> > you have wired things on your board, and somebody from fsl needs to
> tell
> > me how the ExtIrq are routed to the MPIC on that guy.
> > 
> > Once that's done, you seem to have grasped the interrupt map... for
> any
> > device or slot, you provide the mapping between idsel/pirq line on
> one side,
> > and mpic interrupt & sense on the other. For PCI, sense is always 1
> for an
> > mpic so you mostly have to check your actual MPIC source numbers.
> > 
> > >From your .dts, I see you've been doing some swizzling of slots
> using
> > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> > 
> > Ben.
> > 
> > >  
> > >  /*
> ************************************************************************ */
> > >
> --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk        2008-01-24
> 22:58:37.000000000 +0000
> > > +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h  2008-02-20
> 16:36:07.000000000 +0000
> > > @@ -29,10 +29,17 @@
> > >  extern void mpc85xx_ads_map_io(void) __init;
> > >  
> > >  /* PCI interrupt controller */
> > > +#ifdef CONFIG_MEIP_8540
> > > +#define PIRQA              MPC85xx_IRQ_EXT5
> > > +#define PIRQB              MPC85xx_IRQ_EXT6
> > > +#define PIRQC              MPC85xx_IRQ_EXT7
> > > +#define PIRQD              MPC85xx_IRQ_EXT8
> > > +#else
> > >  #define PIRQA              MPC85xx_IRQ_EXT1
> > >  #define PIRQB              MPC85xx_IRQ_EXT2
> > >  #define PIRQC              MPC85xx_IRQ_EXT3
> > >  #define PIRQD              MPC85xx_IRQ_EXT4
> > > +#endif
> > >  
> > >  #define MPC85XX_PCI1_LOWER_IO      0x00000000
> > >  #define MPC85XX_PCI1_UPPER_IO      0x00ffffff
> 

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

On Thu, Mar 06, 2008 at 07:14:28AM +1100, Benjamin Herrenschmidt wrote:
> 
> On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote:
> > 
> > I asked the guy who designed the hardware, and if I understand
> > correctly :
> > 
> > - the i/o and memory resources of the pci device are connected to the
> > pci bus
> > - the interrupts are directly connected to the MPIC
> > 
> > Can I describe that in the dts file ?
> 
> Sure, you can describe pretty much any interrupt routing, provided that
> we know -how- (ie. where) they are connected. We also need to know the

They are connected directly to the pic-part of the mpc8540 just as 
described in the .c file in the other mail.

> idsel of the devices. (The later we can deduce from lspci done in
> arch/ppc).

Does this (boot error messages in the not-working arch/powerpc kernel) :
	PCI: Cannot allocate resource region 0 of device 0000:00:12.0
	PCI: Cannot allocate resource region 0 of device 0000:00:12.1
	PCI: Cannot allocate resource region 0 of device 0000:00:12.2
	PCI: Cannot allocate resource region 1 of device 0000:00:12.2

or this (/proc/bus/pci in the working arch/pcc kernel)
	Sorry, I am at home now and cannot access my board :)
or this (boot info messages from working arch/pcc kernel) :
	ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[55]  MMIO=[9f7fd800-9f7fdfff]  Max Packet=[2048]  IR/IT contexts=[4/8]
	...
	Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
	...
	Yenta TI: socket 0000:00:12.0, mfunc 0x00001b00, devctl 0x66
	Yenta TI: socket 0000:00:12.0 probing PCI interrupt failed, trying to fix
	Yenta TI: socket 0000:00:12.0 falling back to parallel PCI interrupts
	Yenta TI: socket 0000:00:12.0 parallel PCI interrupts ok
	Yenta: ISA IRQ mask 0x0000, PCI irq 53
	...
	pccard: PCMCIA card inserted into slot 0
	cs: memory probe 0x80000000-0x9fffffff: excluding 0x80000000-0x807fffff 0x9f000000-0x9fffffff
	pcmcia: registering new device pcmcia0.0
	Yenta TI: socket 0000:00:12.1 parallel PCI interrupts ok
	Yenta: ISA IRQ mask 0x0000, PCI irq 54
	Socket status: 30000086

or this (U-boot info message) :
	PCI Scan: Found Bus 0, Device 18, Function 0
		00  12  104c  ac46  0607  ff
	PCI Scan: Found Bus 0, Device 18, Function 1
		00  12  104c  ac46  0607  ff
	PCI Scan: Found Bus 0, Device 18, Function 2
		00  12  104c  802a  0c00  00
and this (/proc/interrupts on a working system)
		   CPU0
	 25:          0   OpenPIC   Level     gfar_interrupt
	 26:        245   OpenPIC   Level     serial
	 27:          0   OpenPIC   Level     i2c-mpc
	 53:      18797   OpenPIC   Level     yenta, ide0
	 54:          1   OpenPIC   Level     yenta
	 55:         79   OpenPIC   Level     ohci1394
	BAD:          0

help ?

Philippe

> > > 
> > > Or are you doing some swizzling ?
> > > 
> > > Also, I would need to know how those external IRQs are connected to
> > the MPIC,
> > > I don't have the spec of that chip here. Hrm. Somebody from
> > freescale can
> > > help him here ?
> > > 
> > > It's also not clear to me what your interrupts 9 10 and 11 are since
> > you
> > > seem to only talk about PIRQA...D which is only 4 lines ..
> > > 
> > > So at this stage, that's not enough information. We need to know
> > exactly how
> > > you have wired things on your board, and somebody from fsl needs to
> > tell
> > > me how the ExtIrq are routed to the MPIC on that guy.
> > > 
> > > Once that's done, you seem to have grasped the interrupt map... for
> > any
> > > device or slot, you provide the mapping between idsel/pirq line on
> > one side,
> > > and mpic interrupt & sense on the other. For PCI, sense is always 1
> > for an
> > > mpic so you mostly have to check your actual MPIC source numbers.
> > > 
> > > >From your .dts, I see you've been doing some swizzling of slots
> > using
> > > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> > > 
> > > Ben.
> > > 
> > > >  
> > > >  /*
> > ************************************************************************ */
> > > >
> > --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk        2008-01-24
> > 22:58:37.000000000 +0000
> > > > +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h  2008-02-20
> > 16:36:07.000000000 +0000
> > > > @@ -29,10 +29,17 @@
> > > >  extern void mpc85xx_ads_map_io(void) __init;
> > > >  
> > > >  /* PCI interrupt controller */
> > > > +#ifdef CONFIG_MEIP_8540
> > > > +#define PIRQA              MPC85xx_IRQ_EXT5
> > > > +#define PIRQB              MPC85xx_IRQ_EXT6
> > > > +#define PIRQC              MPC85xx_IRQ_EXT7
> > > > +#define PIRQD              MPC85xx_IRQ_EXT8
> > > > +#else
> > > >  #define PIRQA              MPC85xx_IRQ_EXT1
> > > >  #define PIRQB              MPC85xx_IRQ_EXT2
> > > >  #define PIRQC              MPC85xx_IRQ_EXT3
> > > >  #define PIRQD              MPC85xx_IRQ_EXT4
> > > > +#endif
> > > >  
> > > >  #define MPC85XX_PCI1_LOWER_IO      0x00000000
> > > >  #define MPC85XX_PCI1_UPPER_IO      0x00ffffff
> > 

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Scott Wood]

Benjamin Herrenschmidt wrote:
> So at this stage, that's not enough information. We need to know exactly how
> you have wired things on your board, and somebody from fsl needs to tell
> me how the ExtIrq are routed to the MPIC on that guy.

This part's easy -- the external IRQ is used as the mpic interrupt 
number as-is (internal IRQs start at 16).

> Once that's done, you seem to have grasped the interrupt map... for any
> device or slot, you provide the mapping between idsel/pirq line on one side,
> and mpic interrupt & sense on the other. For PCI, sense is always 1 for an
> mpic so you mostly have to check your actual MPIC source numbers.
> 
>>From your .dts, I see you've been doing some swizzling of slots using
> interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?

No, those correspond to the EXT1-4 that are the other side of the #ifdef 
for this board in arch/ppc. :-)

-Scott

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

> >>From your .dts, I see you've been doing some swizzling of slots using
> > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> 
> No, those correspond to the EXT1-4 that are the other side of the #ifdef 
> for this board in arch/ppc. :-)

Yes, that's what I was thinking. So that's what he got wrong in
his .dts.

Philippe, you need to fix those numbers so they map your EXTIRQ.

(that is 1 -> 5, 2 -> 6, etc... )

And of course you need to make sure you have the right routing to the
chip. it's funny the way you keep providing all sort of info but -never-
the one we actually asked for :-)

We basically, to help you, need to know for each PCI device connected to
the SoC, or PCI slot if you have such, which address line is used for
IDSEL, and to which MPIC interrupt inputs.

Once you have given us that, we'll be able to help.

It appears that just looking at the arch/ppc code is a bit too messy and
confusing (and not necessarily right).

In addition, you will also need to do proper interrupt routing for you
other devices (RTC, etc...) but we can look at that separately.

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

On Thu, Mar 06, 2008 at 10:46:51AM +1100, Benjamin Herrenschmidt wrote:
> 
> > >>From your .dts, I see you've been doing some swizzling of slots using
> > > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> > 
> > No, those correspond to the EXT1-4 that are the other side of the #ifdef 
> > for this board in arch/ppc. :-)
> 
> Yes, that's what I was thinking. So that's what he got wrong in
> his .dts.
> 
> Philippe, you need to fix those numbers so they map your EXTIRQ.
> 
> (that is 1 -> 5, 2 -> 6, etc... )
> 
> And of course you need to make sure you have the right routing to the
> chip. it's funny the way you keep providing all sort of info but -never-
> the one we actually asked for :-)

I did not have that.  The board has been designed, and the original linux
port has been made, by a third-party, and the documentation is scarce :(

> 
> We basically, to help you, need to know for each PCI device connected to
> the SoC, or PCI slot if you have such, which address line is used for
> IDSEL, and to which MPIC interrupt inputs.

Well, i have finally an answer for IDSEL : it is connected to AD18 (18 is
decimal), but we knew that actually, because the chip appears as 0000:00:12.0,
0000:00:12.1 and 0000:00:12.2 in the kernel messages.

The pci4520 chip does not have pins labelled inta, intb, intc, or intd,
but pins labelled mfunc0, mfunc1 ... mfunc6.
The pci4520 datasheet does not seem very clear to me about the relation
between the mfunc0..6 pins and the inta..d interrupts :(
Luckily, the running linux kernel shows in /proc/interrupts :

         55:      18797   OpenPIC   Level     yenta, ide0
         54:          1   OpenPIC   Level     yenta
         55:         79   OpenPIC   Level     ohci1394

I can thus deduce that each function of the pci4520 chip uses only
one interrupt line.  With the kernel messages at startup, I also
know that the two yenta's are 12.0 and 12.1 and the ohci1394 is 12.2.
I wrote then the following in my dts file :

        pci@e0008000 {
/*
                                      f800 masks idsel address line
                                      07 masks (sub)function number
                                               7 masks INTA, INTB, INTC or INTD
*/
                interrupt-map-mask = <ff00 0 0 7>;
                interrupt-map = <
                        /* IDSEL 0x12 func 0 */
                        9000 0 0 1 &mpic 5 1
                        9000 0 0 2 &mpic 5 1
                        9000 0 0 3 &mpic 5 1
                        9000 0 0 4 &mpic 5 1

                        /* IDSEL 0x12 func 1 */
                        9100 0 0 1 &mpic 6 1
                        9100 0 0 2 &mpic 6 1
                        9100 0 0 3 &mpic 6 1
                        9100 0 0 4 &mpic 6 1

                        /* IDSEL 0x12 func 2 */
                        9200 0 0 1 &mpic 7 1
                        9200 0 0 2 &mpic 7 1
                        9200 0 0 3 &mpic 7 1
                        9200 0 0 4 &mpic 7 1
                        >;

And it works :) : my board boots and finds its compact-flash disk.  When
writing this, I realize I may simplify my interrupt-map and write
only one config line per function, thus :

                interrupt-map-mask = <ff00 0 0 0>;
                interrupt-map = <
                        /* IDSEL 0x12 func 0 */
                        9000 0 0 0 &mpic 5 1

                        /* IDSEL 0x12 func 1 */
                        9100 0 0 0 &mpic 6 1

                        /* IDSEL 0x12 func 2 */
                        9200 0 0 0 &mpic 7 1
                        >;

Maybe you should explain in booting_without_of.txt the relation between
the idsel and the pci device notation used by lspci or the kernel, and
also document the "function" part ?

> 
> Once you have given us that, we'll be able to help.
> 
> It appears that just looking at the arch/ppc code is a bit too messy and
> confusing (and not necessarily right).
> 
> In addition, you will also need to do proper interrupt routing for you
> other devices (RTC, etc...) but we can look at that separately.

That's for tomorrow.

But I already noticed that the interrupt numbers that the arch/powerpc tree
uses for the parts that do already work (compact-flash and serials) are
different from the ones I saw on the running arch/ppc tree.  e.g.,
the serial lines used irq 26 with the arch/ppc tree and now use 42 with
the powerpc tree.  For the pci4520, irqs changed from 53, 54 and 55 in the
arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel.
That's a little bit confusing.

There must be something hidden in the sources of the openpic driver to
explain that difference.  Could it be fixed by a setting in the dts-file ?

Thanks for you help

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

On Fri, 2008-03-07 at 01:10 +0100, Philippe De Muyter wrote:
> 
> But I already noticed that the interrupt numbers that the arch/powerpc tree
> uses for the parts that do already work (compact-flash and serials) are
> different from the ones I saw on the running arch/ppc tree.  e.g.,
> the serial lines used irq 26 with the arch/ppc tree and now use 42 with
> the powerpc tree.  For the pci4520, irqs changed from 53, 54 and 55 in the
> arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel.
> That's a little bit confusing.
> 
> There must be something hidden in the sources of the openpic driver to
> explain that difference.  Could it be fixed by a setting in the dts-file ?

The interrupt numbers that you see in /proc/interrupts and that drivers
see are "virtual". They have no direct relationship to the hardware
interrupt lines (well, the kernel attempts sometimes at keeping them the
same but not always).

Basially, when the kernel establishes interrupt routing when probing
devices, it gets dynamically assigned numbers and that's what drivers
and /proc/interrupts will see, and internally "binds" them to a given HW
source on a given interrupt controller.

This is done for several reasons, the main ones being that we have to
routinely deal with multiple controllers each having it's own hardware
number space, some systems have very large HW interrupt numbers not
suitable for the irq_desc array, and we reserve virtual numbers 0 as
always invalid and 1...15 for an ISA-type 8259 controller to avoid
problems with x86-oirignated legacy junk that tries to hard code those
numbers. 

There's an compile option to see the mapping between virtual numbers and
HW numbers in debugfs, try enabling debugfs, CONFIG_VIRQ_DEBUG, and
mount debugfs somewhere. You'll see a powerpc/virq_mapping file in there
with the mapping.

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

I now have a working linux on my mpc8540 based board, with support for
the compactflash disk and the i2c rtc.

The network tough, does not work yet. altough the the integrated ethernet
controller (FEC) seems to be recognized.  Could it be a problem with the phy ?
I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
Do I need to give the phy type in the dts file, and how ?

I would also like to know if it is possible to still get in linux the mac
address known by uboot when using a dts file, and how ?

Thanks for listening.

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

On Sun, 2008-03-09 at 23:31 +0100, Philippe De Muyter wrote:
> Hi Ben,
> 
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
> 
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems to be recognized.  Could it be a problem with the phy ?
> I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> Do I need to give the phy type in the dts file, and how ?
> 
> I would also like to know if it is possible to still get in linux the mac
> address known by uboot when using a dts file, and how ?

I'll let the freescale people answer here as I don't know the gianfar
driver at all.

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[David Gibson]

On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> Hi Ben,
> 
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
> 
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems to be recognized.  Could it be a problem with the phy ?
> I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> Do I need to give the phy type in the dts file, and how ?
> 
> I would also like to know if it is possible to still get in linux the mac
> address known by uboot when using a dts file, and how ?

This chiefly depends on whether you're using an old u-boot that
doesn't know about the device tree, or a new u-boot which itself
supplies a device tree to the kernel.

If the old u-boot, you'll need to write a bootwrapper for your
platform which reads the bd_t and pokes the right mac addresses into
the device tree.

If the new u-boot, u-boot itself should put the address into the
device tree.  If it's not, why it's not is a u-boot question rather
than a device tree question.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi David,

On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote:
> On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> > Hi Ben,
> > 
> > I now have a working linux on my mpc8540 based board, with support for
> > the compactflash disk and the i2c rtc.
> > 
> > The network tough, does not work yet. altough the the integrated ethernet
> > controller (FEC) seems to be recognized.  Could it be a problem with the phy ?
> > I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> > on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> > Do I need to give the phy type in the dts file, and how ?
> > 
> > I would also like to know if it is possible to still get in linux the mac
> > address known by uboot when using a dts file, and how ?
> 
> This chiefly depends on whether you're using an old u-boot that
> doesn't know about the device tree, or a new u-boot which itself
> supplies a device tree to the kernel.
> 
> If the old u-boot, you'll need to write a bootwrapper for your
> platform which reads the bd_t and pokes the right mac addresses into
> the device tree.
> 
> If the new u-boot, u-boot itself should put the address into the
> device tree.  If it's not, why it's not is a u-boot question rather
> than a device tree question.

OK :(

Now back to the first an bigger problem :
currently, I have an "old" U-boot and I have written myself a dts file.

Problem is : ethernet does not work, but that's not a mac-address problem,
but something else that I do not understand yet.  The symptom is I get

	ip route add default via 192.168.85.33 dev eth0
	RTNETLINK answers: Network is unreachable

I surmise this is because my eth0 does not become up, and I surmise
again this is because there is no driver selected to drive the phy.

In my arch/ppc setup this was automagically handled by fixed@100:1 IIRC  

Is there something I can put in my dts file to activate a driver for my phy ?

Best regards

Philippe

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[David Gibson]

On Tue, Mar 11, 2008 at 12:46:02PM +0100, Philippe De Muyter wrote:
> Hi David,
> 
> On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote:
> > On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> > > Hi Ben,
> > > 
> > > I now have a working linux on my mpc8540 based board, with support for
> > > the compactflash disk and the i2c rtc.
> > > 
> > > The network tough, does not work yet. altough the the integrated ethernet
> > > controller (FEC) seems to be recognized.  Could it be a problem with the phy ?
> > > I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> > > on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> > > Do I need to give the phy type in the dts file, and how ?
> > > 
> > > I would also like to know if it is possible to still get in linux the mac
> > > address known by uboot when using a dts file, and how ?
> > 
> > This chiefly depends on whether you're using an old u-boot that
> > doesn't know about the device tree, or a new u-boot which itself
> > supplies a device tree to the kernel.
> > 
> > If the old u-boot, you'll need to write a bootwrapper for your
> > platform which reads the bd_t and pokes the right mac addresses into
> > the device tree.
> > 
> > If the new u-boot, u-boot itself should put the address into the
> > device tree.  If it's not, why it's not is a u-boot question rather
> > than a device tree question.
> 
> OK :(
> 
> Now back to the first an bigger problem :
> currently, I have an "old" U-boot and I have written myself a dts file.
> 
> Problem is : ethernet does not work, but that's not a mac-address problem,
> but something else that I do not understand yet.  The symptom is I get
> 
> 	ip route add default via 192.168.85.33 dev eth0
> 	RTNETLINK answers: Network is unreachable
> 
> I surmise this is because my eth0 does not become up, and I surmise
> again this is because there is no driver selected to drive the phy.
> 
> In my arch/ppc setup this was automagically handled by fixed@100:1 IIRC  
> 
> Is there something I can put in my dts file to activate a driver for
> my phy ?

Probably, but how phy selection works is dependent on the ethernet
driver, so I can't help you.  You'll need someone familiar with the
driver in question (or read the code and figure it out).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Andy Fleming]

> Now back to the first an bigger problem :
> currently, I have an "old" U-boot and I have written myself a dts  
> file.
>
> Problem is : ethernet does not work, but that's not a mac-address  
> problem,
> but something else that I do not understand yet.  The symptom is I get
>
> 	ip route add default via 192.168.85.33 dev eth0
> 	RTNETLINK answers: Network is unreachable
>
> I surmise this is because my eth0 does not become up, and I surmise
> again this is because there is no driver selected to drive the phy.
>
> In my arch/ppc setup this was automagically handled by fixed@100:1  
> IIRC
>
> Is there something I can put in my dts file to activate a driver for  
> my phy ?
>
> Best regards

This slipped under my radar, and I'm only just now finding it again.   
Have your issues been resolved?  If not, could you send a bit more of  
the boot log?  There should be a little more if the PHY was not  
found.  If you were operating with a fixed PHY setup before, then the  
generic PHY driver (which will automatically bind to your PHY) should  
suffice unless your MDIO bus is broken.

Andy

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

Hi Andy,

On Tue, May 06, 2008 at 05:54:02PM -0500, Andy Fleming wrote:
>> Now back to the first an bigger problem :
>> currently, I have an "old" U-boot and I have written myself a dts file.
>>
>> Problem is : ethernet does not work, but that's not a mac-address problem,
>> but something else that I do not understand yet.  The symptom is I get
>>
>> 	ip route add default via 192.168.85.33 dev eth0
>> 	RTNETLINK answers: Network is unreachable
>>
>> I surmise this is because my eth0 does not become up, and I surmise
>> again this is because there is no driver selected to drive the phy.
>>
>> In my arch/ppc setup this was automagically handled by fixed@100:1 IIRC
>>
>> Is there something I can put in my dts file to activate a driver for my 
>> phy ?
>>
>> Best regards
>
> This slipped under my radar, and I'm only just now finding it again.  Have 
> your issues been resolved?

This has actually not been resolved as such, but we use now the newest
U-boot version which is dtb-aware, and linux-2.6.25-rc6, and that together
fixes the ethernet problem.

> If not, could you send a bit more of the boot 
> log?  There should be a little more if the PHY was not found.  If you were 
> operating with a fixed PHY setup before, then the generic PHY driver (which 
> will automatically bind to your PHY) should suffice unless your MDIO bus is 
> broken.
>
> Andy

Of course, the dts file also has changed, because it is now filled by
U-boot.  I have attached it here for info.

Thanks

Philippe

PS:

What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
in the official kernel sources ?  Should I send it to linuxppc-dev@ozlabs.org,
lkml or somewhere else ?

[-- Attachment #2: macq_image_processor.dts --]
[-- Type: text/plain, Size: 4814 bytes --]

/*
 * MPC8540 ADS Device Tree Source - Modified by DEVELTECH for MACQ_IMAGE_PROCESSOR
 *
 * Copyright 2006 Freescale Semiconductor Inc.
 *
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */


/ {
	model = "MACQ_IMAGE_PROCESSOR";
	compatible = "MPC8540ADS", "MPC85xxADS";
	#address-cells = <1>;
	#size-cells = <1>;

	aliases {
		ethernet0 = &enet0;
		serial0 = &serial0;
		pci0 = &pci0;
	};

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,8540@0 {
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <20>;	// 32 bytes
			i-cache-line-size = <20>;	// 32 bytes
			d-cache-size = <8000>;		// L1, 32K
			i-cache-size = <8000>;		// L1, 32K
			timebase-frequency = <0>;	//  33.3333 MHz, from uboot
			bus-frequency = <0>;	// 166 MHz
			clock-frequency = <0>;	// 666, 833 or 1000 MHz, from uboot
		};
	};

	memory {
		device_type = "memory";
		reg = <00000000 10000000>;	// 256M at 0x0
	};

	soc8540@e0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		device_type = "soc";
		ranges = <0 e0000000 00100000>;
		reg = <e0000000 00100000>;	// CCSRBAR 1M
		bus-frequency = <0>;

		memory-controller@2000 {
			compatible = "fsl,8540-memory-controller";
			reg = <2000 1000>;
			interrupt-parent = <&mpic>;
			interrupts = <12 2>;
		};

		l2-cache-controller@20000 {
			compatible = "fsl,8540-l2-cache-controller";
			reg = <20000 1000>;
			cache-line-size = <20>;	// 32 bytes
			cache-size = <40000>;	// L2, 256K
			interrupt-parent = <&mpic>;
			interrupts = <10 2>;
		};

		i2c@3000 {
			#address-cells = <1>;
			#size-cells = <0>;
			cell-index = <0>;
			compatible = "fsl-i2c";
			reg = <3000 100>;
			interrupts = <2b 2>;
			interrupt-parent = <&mpic>;
			dfsrr;

			rtc@68 {
				device_type = "rtc";
				compatible = "stm,m41t81";
				reg = <68>;
				};

			temp-sensor@4c {
				device_type = "temp-sensor";
				compatible = "ns,lm63";
				reg = <4c>;
			};

			temp-sensor@48 {
				device_type = "temp-sensor";
				compatible = "ns,lm75";
				reg = <48>;
			};
		
		};


		mdio@24520 {
			#address-cells = <1>;
			#size-cells = <0>;
			compatible = "fsl,gianfar-mdio";
			reg = <24520 20>;

			phy0: ethernet-phy@1 {
				interrupt-parent = <&mpic>;
				interrupts = <4 1>;
				reg = <1>;
				device_type = "ethernet-phy";
			};
		};

		enet0: ethernet@26000 {
			cell-index = <0>;
			device_type = "network";
			model = "FEC";
			compatible = "gianfar";
			reg = <26000 1000>;
			local-mac-address = [ 00 00 00 00 00 00 ];
			interrupts = <29 2>;
			interrupt-parent = <&mpic>;
			phy-handle = <&phy0>;
		};


		serial0: serial@4500 {
			cell-index = <0>;
			device_type = "serial";
			compatible = "ns16550";
			reg = <4500 100>; 	// reg base, size
			clock-frequency = <0>; 	// should we fill in in uboot?
			interrupts = <2a 2>;
			interrupt-parent = <&mpic>;
		};

		mpic: pic@40000 {
			clock-frequency = <0>;
			interrupt-controller;
			#address-cells = <0>;
			#interrupt-cells = <2>;
			reg = <40000 40000>;
			compatible = "chrp,open-pic";
			device_type = "open-pic";
			big-endian;
		};

		dma@21300 {
			#address-cells = <1>;
			#size-cells = <1>;
			compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
			reg = <21300 4>;
			ranges = <0 21100 200>;
			cell-index = <0>;
			dma-channel@0 {
				compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
				reg = <0 80>;
				cell-index = <0>;
				interrupt-parent = <&mpic>;
				interrupts = <14 2>;
			};
			dma-channel@80 {
				compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
				reg = <80 80>;
				cell-index = <1>;
				interrupt-parent = <&mpic>;
				interrupts = <15 2>;
			};
			dma-channel@100 {
				compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
				reg = <100 80>;
				cell-index = <2>;
				interrupt-parent = <&mpic>;
				interrupts = <16 2>;
			};
			dma-channel@180 {
				compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
				reg = <180 80>;
				cell-index = <3>;
				interrupt-parent = <&mpic>;
				interrupts = <17 2>;
			};
		};

	};

	pci0: pci@e0008000 {
		cell-index = <0>;
		interrupt-map-mask = <f800 0 0 7>;
		interrupt-map = <

			/* IDSEL 0x12 */
			9000 0 0 1 &mpic 5 1
			9000 0 0 2 &mpic 6 1
			9000 0 0 3 &mpic 7 1
			9000 0 0 4 &mpic 8 1>;

		interrupt-parent = <&mpic>;
		interrupts = <18 2>;
		bus-range = <0 0>;
		ranges = <02000000 0 80000000 80000000 0 20000000
			  01000000 0 00000000 e2000000 0 00100000>;
		clock-frequency = <3f940aa>;
		#interrupt-cells = <1>;
		#size-cells = <2>;
		#address-cells = <3>;
		reg = <e0008000 1000>;
		compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
		device_type = "pci";
	};
};

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Hi Philippe,

On Wed, 7 May 2008 09:50:48 +0200 Philippe De Muyter <phdm@macqel.be> wrote:
>
> What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
> in the official kernel sources ?  Should I send it to linuxppc-dev@ozlabs.org,
> lkml or somewhere else ?

linuxppc-dev would be the best place.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Benjamin Herrenschmidt]

> > Maybe your PCI interrupt-map is wrong...
> 
> Is the PCI-interrupt map that part of the dts file :
> 
>                 interrupt-map = <
> 
>                         /* IDSEL 0x02 */
>                         1000 0 0 1 &mpic 1 1
>                         1000 0 0 2 &mpic 2 1
>                         1000 0 0 3 &mpic 3 1
>                         1000 0 0 4 &mpic 4 1
> 
>                         /* IDSEL 0x03 */
>                         1800 0 0 1 &mpic 4 1
>                         1800 0 0 2 &mpic 1 1
>                         1800 0 0 3 &mpic 2 1
>                         1800 0 0 4 &mpic 3 1
> 
> 			...
> 
> I do not understand anything there :(

It's documented in booting-without-of.txt afaik... The interrupt-map
goes along with the interrupt-map-mask. The later defines which bits of
the map are relevant.

The first part of the map is 3 cells containing a PCI address, followed
by a cell containing a PCI IRQ line (1=A....4=D). The next is the parent
interrupt controller, followed by the IRQ specification, which for MPIC
is the interrupt number on that controller, followed by an encoding of
the interrupt polarity & trigger type (1 for level-low).

The first part, the PCI address, has a special format, which should be
documented as well in the document I pointed out. For readability, we
ommited the top 16 bits of the first cell, which are the address type
and bus number, mostly irrelevant for interrupt mapping. The next bits
are the device/function. Usually only the device part is unmasked.

Ben.

Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file

[Philippe De Muyter]

Hi Ben,

On Tue, Mar 04, 2008 at 08:26:14AM +1100, Benjamin Herrenschmidt wrote:
> 
> > > Maybe your PCI interrupt-map is wrong...
> > 
> > Is the PCI-interrupt map that part of the dts file :
> > 
> >                 interrupt-map = <
> > 
> >                         /* IDSEL 0x02 */
> >                         1000 0 0 1 &mpic 1 1
> >                         1000 0 0 2 &mpic 2 1
> >                         1000 0 0 3 &mpic 3 1
> >                         1000 0 0 4 &mpic 4 1
> > 
> >                         /* IDSEL 0x03 */
> >                         1800 0 0 1 &mpic 4 1
> >                         1800 0 0 2 &mpic 1 1
> >                         1800 0 0 3 &mpic 2 1
> >                         1800 0 0 4 &mpic 3 1
> > 
> > 			...
> > 
> > I do not understand anything there :(
> 
> It's documented in booting-without-of.txt afaik... The interrupt-map
> goes along with the interrupt-map-mask. The later defines which bits of
> the map are relevant.

Maybe I should read my mail in time-of-arrival order :)

> 
> The first part of the map is 3 cells containing a PCI address, followed
> by a cell containing a PCI IRQ line (1=A....4=D). The next is the parent
> interrupt controller, followed by the IRQ specification, which for MPIC
> is the interrupt number on that controller, followed by an encoding of
> the interrupt polarity & trigger type (1 for level-low).
> 
> The first part, the PCI address, has a special format, which should be
> documented as well in the document I pointed out. For readability, we
> ommited the top 16 bits of the first cell, which are the address type
> and bus number, mostly irrelevant for interrupt mapping. The next bits
> are the device/function. Usually only the device part is unmasked.

1. Can all that info be found in /proc in a running system or even in the
sources, or do I need an hardware doc for that ?

2. Maybe you could explain the conversion between the kernel/lsusb notation
(0000:00:12.0, 0000:00:12.1, 0000:00:12.2)

or /proc/bus/pci notation :
0090    104cac46        35              9ffff000                       0                      0                0                       0                       0
                       0                    1000                       0                      0                0                       0                       0
                       0        yenta_cardbus
0091    104cac46        36              9fbfe000                       0                      0                0                       0                       0
                       0                    1000                       0                      0                0                       0                       0
                       0        yenta_cardbus
0092    104c802a        37              9f7fd800                9f7f8000                      0                0                       0                       0
                       0                     800                    4000                      0                0                       0                       0
                       0        ohci1394

and dts-notation ?

Thanks for listening

Philippe