[PATCH][PPC32] mv64x60 updates

[PATCH][PPC32] mv64x60 updates

[Mark A. Greer]

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

Hi Andrew.

This patch briges the mv64x60 related code up to the latest that I have.

It:
- adds MPSC support to some ppc bootwrapper files
- adds an erratum workaround for the mv64460
- changes some platform_data related structure names
- cleans up a bunch of whitespace

Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--

[-- Attachment #2: mv64x60.patch --]
[-- Type: text/plain, Size: 21427 bytes --]

diff -Nru a/arch/ppc/boot/common/misc-common.c b/arch/ppc/boot/common/misc-common.c
--- a/arch/ppc/boot/common/misc-common.c	2005-01-25 17:05:15 -07:00
+++ b/arch/ppc/boot/common/misc-common.c	2005-01-25 17:05:15 -07:00
@@ -60,7 +60,8 @@
 unsigned char *ISA_io = NULL;
 
 #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)
 extern unsigned long com_port;
 
 extern int serial_tstc(unsigned long com_port);
@@ -82,7 +83,8 @@
 int tstc(void)
 {
 #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)
 	if(keyb_present)
 		return (CRT_tstc() || serial_tstc(com_port));
 	else
@@ -96,7 +98,8 @@
 {
 	while (1) {
 #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)
 		if (serial_tstc(com_port))
 			return (serial_getc(com_port));
 #endif /* serial console */
@@ -112,7 +115,8 @@
 	int x,y;
 
 #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)
 	serial_putc(com_port, c);
 	if ( c == '\n' )
 		serial_putc(com_port, '\r');
@@ -160,7 +164,8 @@
 
 	while ( ( c = *s++ ) != '\0' ) {
 #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)
 	        serial_putc(com_port, c);
 	        if ( c == '\n' ) serial_putc(com_port, '\r');
 #endif /* serial console */
diff -Nru a/arch/ppc/boot/simple/misc.c b/arch/ppc/boot/simple/misc.c
--- a/arch/ppc/boot/simple/misc.c	2005-01-25 17:05:15 -07:00
+++ b/arch/ppc/boot/simple/misc.c	2005-01-25 17:05:15 -07:00
@@ -50,7 +50,8 @@
  */
 #if (defined(CONFIG_SERIAL_8250_CONSOLE) \
 	|| defined(CONFIG_VGA_CONSOLE) \
-	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE)) \
+	|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
+	|| defined(CONFIG_SERIAL_MPSC_CONSOLE)) \
 	&& !defined(CONFIG_GEMINI)
 #define INTERACTIVE_CONSOLE	1
 #endif
@@ -98,7 +99,7 @@
 	struct bi_record *rec;
 	unsigned long initrd_loc = 0, TotalMemory = 0;
 
-#ifdef CONFIG_SERIAL_8250_CONSOLE
+#if defined(CONFIG_SERIAL_8250_CONSOLE) || defined(CONFIG_SERIAL_MPSC_CONSOLE)
 	com_port = serial_init(0, NULL);
 #endif
 
diff -Nru a/arch/ppc/boot/simple/mv64x60_tty.c b/arch/ppc/boot/simple/mv64x60_tty.c
--- a/arch/ppc/boot/simple/mv64x60_tty.c	2005-01-25 17:05:15 -07:00
+++ b/arch/ppc/boot/simple/mv64x60_tty.c	2005-01-25 17:05:15 -07:00
@@ -6,12 +6,10 @@
  *
  * Author: Mark A. Greer <mgreer@mvista.com>
  *
- * Copyright 2001 MontaVista Software 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.
+ * 2001 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
  */
 
 /* This code assumes that the data cache has been disabled (L1, L2, L3). */
diff -Nru a/arch/ppc/syslib/mv64360_pic.c b/arch/ppc/syslib/mv64360_pic.c
--- a/arch/ppc/syslib/mv64360_pic.c	2005-01-25 17:05:15 -07:00
+++ b/arch/ppc/syslib/mv64360_pic.c	2005-01-25 17:05:15 -07:00
@@ -369,7 +369,8 @@
 	u32	mask;
 	int	rc;
 
-	/* Register CPU interface error interrupt handler */
+	/* Clear old errors and register CPU interface error intr handler */
+	mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
 	if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
 		mv64360_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
 		printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
@@ -377,7 +378,8 @@
 	mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
 	mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000ff);
 
-	/* Register internal SRAM error interrupt handler */
+	/* Clear old errors and register internal SRAM error intr handler */
+	mv64x60_write(&bh, MV64360_SRAM_ERR_CAUSE, 0);
 	if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR,
 		mv64360_sram_error_int_handler,SA_INTERRUPT,SRAM_INTR_STR, 0)))
 		printk(KERN_WARNING "Can't register SRAM error handler: %d",rc);
@@ -393,18 +395,20 @@
 		(mv64x60_get_bridge_rev() > 1))
 		mask |= 0x1;	/* enable DPErr on 64460 */
 
-	/* Register PCI 0 error interrupt handler */
+	/* Clear old errors and register PCI 0 error intr handler */
+	mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, 0);
 	if ((rc = request_irq(MV64360_IRQ_PCI0, mv64360_pci_error_int_handler,
-		    SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
+			SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
 		printk(KERN_WARNING "Can't register pci 0 error handler: %d",
 			rc);
 
 	mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
 	mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, mask);
 
-	/* Register PCI 1 error interrupt handler */
+	/* Clear old errors and register PCI 1 error intr handler */
+	mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, 0);
 	if ((rc = request_irq(MV64360_IRQ_PCI1, mv64360_pci_error_int_handler,
-		    SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
+			SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
 		printk(KERN_WARNING "Can't register pci 1 error handler: %d",
 			rc);
 
diff -Nru a/arch/ppc/syslib/mv64x60.c b/arch/ppc/syslib/mv64x60.c
--- a/arch/ppc/syslib/mv64x60.c	2005-01-25 17:05:15 -07:00
+++ b/arch/ppc/syslib/mv64x60.c	2005-01-25 17:05:15 -07:00
@@ -34,10 +34,10 @@
 u8		mv64x60_pci_exclude_bridge = 1;
 spinlock_t	mv64x60_lock; /* Only really used by PIC code once init done */
 
-static u32	mv64x60_bridge_pbase = 0;
-static u32	mv64x60_bridge_vbase = 0;
-static u32	mv64x60_bridge_type = MV64x60_TYPE_INVALID;
-static u32	mv64x60_bridge_rev = 0;
+static phys_addr_t 	mv64x60_bridge_pbase = 0;
+static void 		*mv64x60_bridge_vbase = 0;
+static u32		mv64x60_bridge_type = MV64x60_TYPE_INVALID;
+static u32		mv64x60_bridge_rev = 0;
 
 static u32 gt64260_translate_size(u32 base, u32 size, u32 num_bits);
 static u32 gt64260_untranslate_size(u32 base, u32 size, u32 num_bits);
@@ -88,7 +88,7 @@
 	.translate_size		= gt64260_translate_size,
 	.untranslate_size	= gt64260_untranslate_size,
 	.set_pci2mem_window	= gt64260_set_pci2mem_window,
-	.set_pci2regs_window    = gt64260_set_pci2regs_window,
+	.set_pci2regs_window	= gt64260_set_pci2regs_window,
 	.is_enabled_32bit	= gt64260_is_enabled_32bit,
 	.enable_window_32bit	= gt64260_enable_window_32bit,
 	.disable_window_32bit	= gt64260_disable_window_32bit,
@@ -104,7 +104,7 @@
 	.translate_size		= gt64260_translate_size,
 	.untranslate_size	= gt64260_untranslate_size,
 	.set_pci2mem_window	= gt64260_set_pci2mem_window,
-	.set_pci2regs_window    = gt64260_set_pci2regs_window,
+	.set_pci2regs_window	= gt64260_set_pci2regs_window,
 	.is_enabled_32bit	= gt64260_is_enabled_32bit,
 	.enable_window_32bit	= gt64260_enable_window_32bit,
 	.disable_window_32bit	= gt64260_disable_window_32bit,
@@ -120,7 +120,7 @@
 	.translate_size		= mv64360_translate_size,
 	.untranslate_size	= mv64360_untranslate_size,
 	.set_pci2mem_window	= mv64360_set_pci2mem_window,
-	.set_pci2regs_window    = mv64360_set_pci2regs_window,
+	.set_pci2regs_window	= mv64360_set_pci2regs_window,
 	.is_enabled_32bit	= mv64360_is_enabled_32bit,
 	.enable_window_32bit	= mv64360_enable_window_32bit,
 	.disable_window_32bit	= mv64360_disable_window_32bit,
@@ -138,7 +138,7 @@
 	.translate_size		= mv64360_translate_size,
 	.untranslate_size	= mv64360_untranslate_size,
 	.set_pci2mem_window	= mv64360_set_pci2mem_window,
-	.set_pci2regs_window    = mv64360_set_pci2regs_window,
+	.set_pci2regs_window	= mv64360_set_pci2regs_window,
 	.is_enabled_32bit	= mv64360_is_enabled_32bit,
 	.enable_window_32bit	= mv64360_enable_window_32bit,
 	.disable_window_32bit	= mv64360_disable_window_32bit,
@@ -160,7 +160,7 @@
  *****************************************************************************
  */
 #ifdef CONFIG_SERIAL_MPSC
-static struct mpsc_shared_pd_dd mv64x60_mpsc_shared_pd_dd = {
+static struct mpsc_shared_pdata mv64x60_mpsc_shared_pdata = {
 	.mrr_val		= 0x3ffffe38,
 	.rcrr_val		= 0,
 	.tcrr_val		= 0,
@@ -192,11 +192,11 @@
 	.num_resources	= ARRAY_SIZE(mv64x60_mpsc_shared_resources),
 	.resource	= mv64x60_mpsc_shared_resources,
 	.dev = {
-		.driver_data = &mv64x60_mpsc_shared_pd_dd,
+		.platform_data = &mv64x60_mpsc_shared_pdata,
 	},
 };
 
-static struct mpsc_pd_dd mv64x60_mpsc0_pd_dd = {
+static struct mpsc_pdata mv64x60_mpsc0_pdata = {
 	.mirror_regs		= 0,
 	.cache_mgmt		= 0,
 	.max_idle		= 0,
@@ -248,11 +248,11 @@
 	.num_resources	= ARRAY_SIZE(mv64x60_mpsc0_resources),
 	.resource	= mv64x60_mpsc0_resources,
 	.dev = {
-		.driver_data = &mv64x60_mpsc0_pd_dd,
+		.platform_data = &mv64x60_mpsc0_pdata,
 	},
 };
 
-static struct mpsc_pd_dd mv64x60_mpsc1_pd_dd = {
+static struct mpsc_pdata mv64x60_mpsc1_pdata = {
 	.mirror_regs		= 0,
 	.cache_mgmt		= 0,
 	.max_idle		= 0,
@@ -305,7 +305,130 @@
 	.num_resources	= ARRAY_SIZE(mv64x60_mpsc1_resources),
 	.resource	= mv64x60_mpsc1_resources,
 	.dev = {
-		.driver_data = &mv64x60_mpsc1_pd_dd,
+		.platform_data = &mv64x60_mpsc1_pdata,
+	},
+};
+#endif
+
+#ifdef CONFIG_MV643XX_ETH
+static struct resource mv64x60_eth_shared_resources[] = {
+	[0] = {
+		.name	= "ethernet shared base",
+		.start	= MV64340_ETH_SHARED_REGS,
+		.end	= MV64340_ETH_SHARED_REGS +
+					MV64340_ETH_SHARED_REGS_SIZE - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mv64x60_eth_shared_device = {
+	.name		= MV64XXX_ETH_SHARED_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv64x60_eth_shared_resources),
+	.resource	= mv64x60_eth_shared_resources,
+};
+
+#ifdef CONFIG_MV643XX_ETH_0
+static struct resource mv64x60_eth0_resources[] = {
+	[0] = {
+		.name	= "eth0 irq",
+		.start	= MV64x60_IRQ_ETH_0,
+		.end	= MV64x60_IRQ_ETH_0,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv64xxx_eth_platform_data eth0_pd;
+
+static struct platform_device eth0_device = {
+	.name		= MV64XXX_ETH_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv64x60_eth0_resources),
+	.resource	= mv64x60_eth0_resources,
+	.dev = {
+		.platform_data = &eth0_pd,
+	},
+};
+#endif
+
+#ifdef CONFIG_MV643XX_ETH_1
+static struct resource mv64x60_eth1_resources[] = {
+	[0] = {
+		.name	= "eth1 irq",
+		.start	= MV64x60_IRQ_ETH_1,
+		.end	= MV64x60_IRQ_ETH_1,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv64xxx_eth_platform_data eth1_pd;
+
+static struct platform_device eth1_device = {
+	.name		= MV64XXX_ETH_NAME,
+	.id		= 1,
+	.num_resources	= ARRAY_SIZE(mv64x60_eth1_resources),
+	.resource	= mv64x60_eth1_resources,
+	.dev = {
+		.platform_data = &eth1_pd,
+	},
+};
+#endif
+
+#ifdef CONFIG_MV643XX_ETH_2
+static struct resource mv64x60_eth2_resources[] = {
+	[0] = {
+		.name	= "eth2 irq",
+		.start	= MV64x60_IRQ_ETH_2,
+		.end	= MV64x60_IRQ_ETH_2,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv64xxx_eth_platform_data eth2_pd;
+
+static struct platform_device eth2_device = {
+	.name		= MV64XXX_ETH_NAME,
+	.id		= 2,
+	.num_resources	= ARRAY_SIZE(mv64x60_eth2_resources),
+	.resource	= mv64x60_eth2_resources,
+	.dev = {
+		.platform_data = &eth2_pd,
+	},
+};
+#endif
+#endif
+
+#ifdef	CONFIG_I2C_MV64XXX
+static struct mv64xxx_i2c_pdata mv64xxx_i2c_pdata = {
+	.freq_m			= 8,
+	.freq_n			= 3,
+	.timeout		= 1000, /* Default timeout of 1 second */
+	.retries		= 1,
+};
+
+static struct resource mv64xxx_i2c_resources[] = {
+	/* Do not change the order of the IORESOURCE_MEM resources */
+	[0] = {
+		.name	= "mv64xxx i2c base",
+		.start	= MV64XXX_I2C_OFFSET,
+		.end	= MV64XXX_I2C_OFFSET + MV64XXX_I2C_REG_BLOCK_SIZE - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.name	= "mv64xxx i2c irq",
+		.start	= MV64x60_IRQ_I2C,
+		.end	= MV64x60_IRQ_I2C,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device i2c_device = {
+	.name		= MV64XXX_I2C_CTLR_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv64xxx_i2c_resources),
+	.resource	= mv64xxx_i2c_resources,
+	.dev = {
+		.platform_data = &mv64xxx_i2c_pdata,
 	},
 };
 #endif
@@ -316,6 +439,21 @@
 	&mpsc0_device,
 	&mpsc1_device,
 #endif
+#ifdef CONFIG_MV643XX_ETH
+	&mv64x60_eth_shared_device,
+#endif
+#ifdef CONFIG_MV643XX_ETH_0
+	&eth0_device,
+#endif
+#ifdef CONFIG_MV643XX_ETH_1
+	&eth1_device,
+#endif
+#ifdef CONFIG_MV643XX_ETH_2
+	&eth2_device,
+#endif
+#ifdef	CONFIG_I2C_MV64XXX
+	&i2c_device,
+#endif
 };
 
 /*
@@ -344,7 +482,7 @@
 	mv64x60_early_init(bh, si);
 
 	if (mv64x60_get_type(bh) || mv64x60_setup_for_chip(bh)) {
-		iounmap((void *)bh->v_base);
+		iounmap(bh->v_base);
 		bh->v_base = 0;
 		if (ppc_md.progress)
 			ppc_md.progress("mv64x60_init: Can't determine chip",0);
@@ -416,7 +554,7 @@
 	memset(bh, 0, sizeof(*bh));
 
 	bh->p_base = si->phys_reg_base;
-	bh->v_base = (u32)ioremap(bh->p_base, MV64x60_INTERNAL_SPACE_SIZE);
+	bh->v_base = ioremap(bh->p_base, MV64x60_INTERNAL_SPACE_SIZE);
 
 	mv64x60_bridge_pbase = bh->p_base;
 	mv64x60_bridge_vbase = bh->v_base;
@@ -598,7 +736,7 @@
  */
 void __init
 mv64x60_set_64bit_window(struct mv64x60_handle *bh, u32 window,
-			u32 base_hi, u32 base_lo, u32 size, u32 other_bits)
+	u32 base_hi, u32 base_lo, u32 size, u32 other_bits)
 {
 	u32	val, base_lo_reg, size_reg, base_lo_bits, size_bits;
 	u32	(*map_to_field)(u32 val, u32 num_bits);
@@ -645,7 +783,7 @@
 }
 
 /*
- * mv64x60_mask_shift_left()
+ * mv64x60_shift_left()
  *
  * Take the low-order 'num_bits' of 'val', shift left to align at bit 31 (MSB).
  */
@@ -702,7 +840,7 @@
 	/* Get the revision of the chip */
 	early_read_config_word(&hose, 0, PCI_DEVFN(0, 0), PCI_CLASS_REVISION,
 		&val);
-	bh->rev = (u32) (val & 0xff);
+	bh->rev = (u32)(val & 0xff);
 
 	/* Figure out the type of Marvell bridge it is */
 	early_read_config_word(&hose, 0, PCI_DEVFN(0, 0), PCI_DEVICE_ID, &val);
@@ -790,7 +928,7 @@
  *
  * Return the virtual address of the bridge's registers.
  */
-u32
+void *
 mv64x60_get_bridge_vbase(void)
 {
 	return mv64x60_bridge_vbase;
@@ -836,13 +974,13 @@
 mv64x60_get_mem_size(u32 bridge_base, u32 chip_type)
 {
 	struct mv64x60_handle	bh;
-	u32			mem_windows[MV64x60_CPU2MEM_WINDOWS][2];
-	u32			rc = 0;
+	u32	mem_windows[MV64x60_CPU2MEM_WINDOWS][2];
+	u32	rc = 0;
 
 	memset(&bh, 0, sizeof(bh));
 
 	bh.type = chip_type;
-	bh.v_base = bridge_base;
+	bh.v_base = (void *)bridge_base;
 
 	if (!mv64x60_setup_for_chip(&bh)) {
 		mv64x60_get_mem_windows(&bh, mem_windows);
@@ -1117,7 +1255,7 @@
 			IORESOURCE_IO, s[hose->index][0]);
 		hose->io_space.start = pi->pci_io.pci_base_lo;
 		hose->io_space.end = pi->pci_io.pci_base_lo + pi->pci_io.size-1;
-		hose->io_base_phys = (ulong)pi->pci_io.cpu_base;
+		hose->io_base_phys = pi->pci_io.cpu_base;
 		hose->io_base_virt = (void *)isa_io_base;
 	}
 
@@ -1592,8 +1730,8 @@
 	struct resource	*r;
 #endif
 #if !defined(CONFIG_NOT_COHERENT_CACHE)
-	u32		val;
-	u8		save_exclude;
+	u32	val;
+	u8	save_exclude;
 #endif
 
 	if (si->pci_0.enable_bus)
@@ -1638,10 +1776,10 @@
 	mv64x60_clr_bits(bh, 0xf2c0, (1<< 6) | (1<<14) | (1<<22) | (1<<30));
 
 #ifdef CONFIG_SERIAL_MPSC
-	mv64x60_mpsc0_pd_dd.mirror_regs = 1;
-	mv64x60_mpsc0_pd_dd.cache_mgmt = 1;
-	mv64x60_mpsc1_pd_dd.mirror_regs = 1;
-	mv64x60_mpsc1_pd_dd.cache_mgmt = 1;
+	mv64x60_mpsc0_pdata.mirror_regs = 1;
+	mv64x60_mpsc0_pdata.cache_mgmt = 1;
+	mv64x60_mpsc1_pdata.mirror_regs = 1;
+	mv64x60_mpsc1_pdata.cache_mgmt = 1;
 
 	if ((r = platform_get_resource(&mpsc1_device, IORESOURCE_IRQ, 0))
 		!= NULL) {
@@ -1667,8 +1805,8 @@
 	struct resource	*r;
 #endif
 #if !defined(CONFIG_NOT_COHERENT_CACHE)
-	u32		val;
-	u8		save_exclude;
+	u32	val;
+	u8	save_exclude;
 #endif
 
 	if (si->pci_0.enable_bus)
@@ -1720,8 +1858,8 @@
 	 * can't access cache coherent regions.  However, testing has shown
 	 * that the MPSC, at least, still has this bug.
 	 */
-	mv64x60_mpsc0_pd_dd.cache_mgmt = 1;
-	mv64x60_mpsc1_pd_dd.cache_mgmt = 1;
+	mv64x60_mpsc0_pdata.cache_mgmt = 1;
+	mv64x60_mpsc1_pdata.cache_mgmt = 1;
 
 	if ((r = platform_get_resource(&mpsc1_device, IORESOURCE_IRQ, 0))
 		!= NULL) {
@@ -2228,10 +2366,10 @@
 	struct mv64x60_setup_info *si)
 {
 #ifdef CONFIG_SERIAL_MPSC
-	mv64x60_mpsc0_pd_dd.brg_can_tune = 1;
-	mv64x60_mpsc0_pd_dd.cache_mgmt = 1;
-	mv64x60_mpsc1_pd_dd.brg_can_tune = 1;
-	mv64x60_mpsc1_pd_dd.cache_mgmt = 1;
+	mv64x60_mpsc0_pdata.brg_can_tune = 1;
+	mv64x60_mpsc0_pdata.cache_mgmt = 1;
+	mv64x60_mpsc1_pdata.brg_can_tune = 1;
+	mv64x60_mpsc1_pdata.cache_mgmt = 1;
 #endif
 
 	return;
@@ -2247,8 +2385,8 @@
 	struct mv64x60_setup_info *si)
 {
 #ifdef CONFIG_SERIAL_MPSC
-	mv64x60_mpsc0_pd_dd.brg_can_tune = 1;
-	mv64x60_mpsc1_pd_dd.brg_can_tune = 1;
+	mv64x60_mpsc0_pdata.brg_can_tune = 1;
+	mv64x60_mpsc1_pdata.brg_can_tune = 1;
 #endif
 	return;
 }
diff -Nru a/include/asm-ppc/mv64x60.h b/include/asm-ppc/mv64x60.h
--- a/include/asm-ppc/mv64x60.h	2005-01-25 17:05:15 -07:00
+++ b/include/asm-ppc/mv64x60.h	2005-01-25 17:05:15 -07:00
@@ -27,7 +27,7 @@
 #include <asm/pci-bridge.h>
 #include <asm/mv64x60_defs.h>
 
-extern u8      mv64x60_pci_exclude_bridge;
+extern u8	mv64x60_pci_exclude_bridge;
 
 extern spinlock_t mv64x60_lock;
 
@@ -210,7 +210,7 @@
 	void	(*enable_window_64bit)(mv64x60_handle_t *bh, u32 window);
 	void	(*disable_window_64bit)(mv64x60_handle_t *bh, u32 window);
 	void	(*disable_all_windows)(mv64x60_handle_t *bh,
-		       struct mv64x60_setup_info *si);
+			struct mv64x60_setup_info *si);
 	void	(*config_io2mem_windows)(mv64x60_handle_t *bh,
 			struct mv64x60_setup_info *si,
 			u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2]);
@@ -223,16 +223,16 @@
 };
 
 struct mv64x60_handle {
-	u32	type;		/* type of bridge */
-	u32	rev;		/* revision of bridge */
-	u32	v_base;		/* virtual base addr of bridge regs */
-	u32	p_base;		/* physical base addr of bridge regs */
+	u32		type;		/* type of bridge */
+	u32		rev;		/* revision of bridge */
+	void		*v_base;	/* virtual base addr of bridge regs */
+	phys_addr_t	p_base;		/* physical base addr of bridge regs */
 
-	u32	pci_mode_a;	/* pci bus 0 mode: conventional pci, pci-x */
-	u32	pci_mode_b;	/* pci bus 1 mode: conventional pci, pci-x */
+	u32		pci_mode_a;	/* pci 0 mode: conventional pci, pci-x*/
+	u32		pci_mode_b;	/* pci 1 mode: conventional pci, pci-x*/
 
-	u32	io_base_a;	/* vaddr of pci 0's I/O space */
-	u32	io_base_b;	/* vaddr of pci 1's I/O space */
+	u32		io_base_a;	/* vaddr of pci 0's I/O space */
+	u32		io_base_b;	/* vaddr of pci 1's I/O space */
 
 	struct pci_controller	*hose_a;
 	struct pci_controller	*hose_b;
@@ -247,7 +247,7 @@
 	ulong	flags;
 
 	spin_lock_irqsave(&mv64x60_lock, flags);
-	out_le32((volatile u32 *)(bh->v_base + offset), val);
+	out_le32(bh->v_base + offset, val);
 	spin_unlock_irqrestore(&mv64x60_lock, flags);
 }
 
@@ -256,7 +256,7 @@
 	ulong	flags;
 
 	spin_lock_irqsave(&mv64x60_lock, flags);
-	return in_le32((volatile u32 *)(bh->v_base + offset));
+	return in_le32(bh->v_base + offset);
 	spin_unlock_irqrestore(&mv64x60_lock, flags);
 }
 
@@ -282,11 +282,11 @@
 u32 mv64x60_get_mem_size(u32 bridge_base, u32 chip_type);
 void mv64x60_early_init(struct mv64x60_handle *bh,
 	struct mv64x60_setup_info *si);
-void mv64x60_alloc_hose(struct mv64x60_handle *bh, u32 cfg_addr, u32 cfg_data,
-	struct pci_controller **hose);
+void mv64x60_alloc_hose(struct mv64x60_handle *bh, u32 cfg_addr,
+	u32 cfg_data, struct pci_controller **hose);
 int mv64x60_get_type(struct mv64x60_handle *bh);
 int mv64x60_setup_for_chip(struct mv64x60_handle *bh);
-u32 mv64x60_get_bridge_vbase(void);
+void *mv64x60_get_bridge_vbase(void);
 u32 mv64x60_get_bridge_type(void);
 u32 mv64x60_get_bridge_rev(void);
 void mv64x60_get_mem_windows(struct mv64x60_handle *bh,
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h	2005-01-25 17:05:15 -07:00
+++ b/include/asm-ppc/mv64x60_defs.h	2005-01-25 17:05:15 -07:00
@@ -216,9 +216,9 @@
 #define MV64360_CPU1_SYNC_BARRIER_VIRT		0x00d8
 
 /* CPU Deadlock and Ordering registers (Rev B part only) */
-#define GT64260_CPU_DEADLOCK_ORDERING                   0x02d0
-#define GT64260_CPU_WB_PRIORITY_BUFFER_DEPTH            0x02d8
-#define GT64260_CPU_COUNTERS_SYNC_BARRIER_ATTRIBUTE     0x02e0
+#define GT64260_CPU_DEADLOCK_ORDERING			0x02d0
+#define GT64260_CPU_WB_PRIORITY_BUFFER_DEPTH		0x02d8
+#define GT64260_CPU_COUNTERS_SYNC_BARRIER_ATTRIBUTE	0x02e0
 
 /* CPU Access Protection Registers (gt64260 realy has 8 but don't need) */
 #define	MV64x260_CPU_PROT_WINDOWS		4
diff -Nru a/include/linux/mv643xx.h b/include/linux/mv643xx.h
--- a/include/linux/mv643xx.h	2005-01-25 17:05:15 -07:00
+++ b/include/linux/mv643xx.h	2005-01-25 17:05:15 -07:00
@@ -1048,7 +1048,7 @@
 #define MPSC_ROUTING_REG_BLOCK_SIZE	0x000c
 #define MPSC_SDMA_INTR_REG_BLOCK_SIZE	0x0084
 
-struct mpsc_shared_pd_dd {
+struct mpsc_shared_pdata {
 	u32	mrr_val;
 	u32	rcrr_val;
 	u32	tcrr_val;
@@ -1067,7 +1067,7 @@
 #define MPSC_SDMA_REG_BLOCK_SIZE	0x0c18
 #define MPSC_BRG_REG_BLOCK_SIZE		0x0008
 
-struct mpsc_pd_dd {
+struct mpsc_pdata {
 	u8	mirror_regs;
 	u8	cache_mgmt;
 	u8	max_idle;

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:
> Hi Andrew.
> 
> This patch briges the mv64x60 related code up to the latest that I have.

Mark, ...

I am a bit bewildered by what you are doing here. How does this mv64x60 code
relate to the mv643xx_eth driver from the mips folk ? 

Friendly,

Sven Luther

Re: [PATCH][PPC32] mv64x60 updates

[Mark A. Greer]

Sven Luther wrote:

>On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:
>  
>
>>Hi Andrew.
>>
>>This patch briges the mv64x60 related code up to the latest that I have.
>>    
>>
>
>Mark, ...
>
>I am a bit bewildered by what you are doing here. How does this mv64x60 code
>relate to the mv643xx_eth driver from the mips folk ? 
>
>Friendly,
>
>Sven Luther
>

Hi Sven.

The mv64x60 is a Marvell host bridge with some I/O ctlrs including 3 
enet cltrs.  There are virtually identical versions for MIPS (called 
mv64x4x) and PPC (called mv64x6x).  The mv643xx_eth driver was 
originally written by the MIPS folks, as you note, but Dale Farnsworth 
has spent a lot of time making it work on both MIPS and PPC.  The code 
you see in the mv64x60.c file is a part of that.  I believe that Dale's 
patch(es) have been accepted and are queued to go into the mainline tree 
at some point.

Did I answer your question?

Mark

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> Sven Luther wrote:
> 
> >On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:
> > 
> >
> >>Hi Andrew.
> >>
> >>This patch briges the mv64x60 related code up to the latest that I have.
> >>   
> >>
> >
> >Mark, ...
> >
> >I am a bit bewildered by what you are doing here. How does this mv64x60 
> >code
> >relate to the mv643xx_eth driver from the mips folk ? 
> >
> >Friendly,
> >
> >Sven Luther
> >
> 
> Hi Sven.

Hi Mark :)

> The mv64x60 is a Marvell host bridge with some I/O ctlrs including 3 

Yeah, i know, as we use the MV64361 in the Pegasos 2 motherboards here at
Genesi/Bplan.

> enet cltrs.  There are virtually identical versions for MIPS (called 
> mv64x4x) and PPC (called mv64x6x).  The mv643xx_eth driver was 
> originally written by the MIPS folks, as you note, but Dale Farnsworth 

Yes, and is in drivers/net.

> has spent a lot of time making it work on both MIPS and PPC.  The code 
> you see in the mv64x60.c file is a part of that.  I believe that Dale's 

Ok, so the code in question is in addition to the existing driver from the
mips guys and works with it ? I had the impression that it was a separate
driver development or something.

> patch(es) have been accepted and are queued to go into the mainline tree 
> at some point.

Ok. Do you know if Dale's patches are available separatedly while they are not
yet in mainline, so Nicolas Det can work on them and make sure they also work
on the Pegasos board, which is not an embedded board but from the chrp
lineage. Nicolas already did some mv643xx ethernet driver work last summer,
but apparently had trouble integrating this in the mainline kernel, and it
seems his work has now been redone by Dale or something. Do you know who the
right person to communicate with about this would be ? The MIPS folk didn't
reply to any of our mails about this subject.

> Did I answer your question?

I think so. I was just surprised to see this 64x6x work go to arch/ppc instead
to drivers/net. I haven't really looked at the code though. Nicolas could you
comment on this ? 

Friendly,

Sven Luther
> 
> Mark
> 
> 

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Thu, Feb 24, 2005 at 10:08:35AM -0700, Mark A. Greer wrote:
> Sven Luther wrote:
> >Ok. Do you know if Dale's patches are available separatedly while they are 
> >not
> >yet in mainline, so Nicolas Det can work on them and make sure they also 
> >work
> >on the Pegasos board, which is not an embedded board but from the chrp
> >lineage. Nicolas already did some mv643xx ethernet driver work last summer,
> >but apparently had trouble integrating this in the mainline kernel, and it
> >seems his work has now been redone by Dale or something. Do you know who 
> >the
> >right person to communicate with about this would be ? The MIPS folk didn't
> >reply to any of our mails about this subject.
> >
> 
> Nicolas has emailed me off-line and he & Dale are now in contact.  FYI, 
> this is part of the email from Dale to Nicolas:

Ok, cool, i really only mailed so that Nicolas could take over from there on.

Friendly,

Sven Luther

Re: [PATCH][PPC32] mv64x60 updates

[Mark A. Greer]

Sven Luther wrote:

>On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
>  
>
>>Sven Luther wrote:
>>
>>    
>>
>>>On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:
>>>
>>>
>>>      
>>>
>>has spent a lot of time making it work on both MIPS and PPC.  The code 
>>you see in the mv64x60.c file is a part of that.  I believe that Dale's 
>>    
>>
>
>Ok, so the code in question is in addition to the existing driver from the
>mips guys and works with it ?
>

If "the code in question" == the enet related code in mv64x60.c then 
yes.  However, the only enet related code in mv64x60 is platform_data 
setup and setup of the bridge's windows between the enet ctlr and system 
memory.

> I had the impression that it was a separate
>driver development or something.
>

Nope.

>
>  
>
>>patch(es) have been accepted and are queued to go into the mainline tree 
>>at some point.
>>    
>>
>
>Ok. Do you know if Dale's patches are available separatedly while they are not
>yet in mainline, so Nicolas Det can work on them and make sure they also work
>on the Pegasos board, which is not an embedded board but from the chrp
>lineage. Nicolas already did some mv643xx ethernet driver work last summer,
>but apparently had trouble integrating this in the mainline kernel, and it
>seems his work has now been redone by Dale or something. Do you know who the
>right person to communicate with about this would be ? The MIPS folk didn't
>reply to any of our mails about this subject.
>

Nicolas has emailed me off-line and he & Dale are now in contact.  FYI, 
this is part of the email from Dale to Nicolas:

>  Please see bk://dfarnsworth@bkbits.net/linux-2.5-mv643xx-enet.  Most of this is
> in netdev and mm, and on track to go into linux-2.5.


>>Did I answer your question?
>>    
>>
>
>I think so. I was just surprised to see this 64x6x work go to arch/ppc instead
>to drivers/net.
>

There is no "driver" functionality in arch/ppc.  There is only 
platform_data setup which is used by the driver and the ensuring the 
bridge's windows between the enet ctlr and system memory are set up 
correctly.

Mark

Re: [PATCH][PPC32] mv64x60 updates

[Dale Farnsworth]

On Thu, Feb 24, 2005 at 04:04:11PM +0000, Sven Luther wrote:
> > >I am a bit bewildered by what you are doing here. How does this mv64x60 
> > >code relate to the mv643xx_eth driver from the mips folk ? 
> 
> [...]
> 
> On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> > has spent a lot of time making it work on both MIPS and PPC.  The code 
> > you see in the mv64x60.c file is a part of that.  I believe that Dale's 
> 
> Ok, so the code in question is in addition to the existing driver from the
> mips guys and works with it ? I had the impression that it was a separate
> driver development or something.

The code in mv64x60.c is related to but separate from the ethernet driver.
It is platform-specific code that passes register addresses, irqs,
mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.

All of my changes to the mv643xx ethernet driver have been posted to
LKML or the netdev list.  I have removed all arch-specific code from
the ethernet driver itself.

> Ok. Do you know if Dale's patches are available separatedly while they are not
> yet in mainline, so Nicolas Det can work on them and make sure they also work
> on the Pegasos board, which is not an embedded board but from the chrp

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

> lineage. Nicolas already did some mv643xx ethernet driver work last summer,
> but apparently had trouble integrating this in the mainline kernel, and it

I'm sorry I wasn't aware of Nicolas' work on the driver.

> seems his work has now been redone by Dale or something. Do you know who the
> right person to communicate with about this would be ? The MIPS folk didn't
> reply to any of our mails about this subject.

Sounds familiar.  Fortunately, Jeff Garzik picked up my changes.
I would appreciate feedback from you or Nicolas on the current driver.

Thanks,
-Dale

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> On Thu, Feb 24, 2005 at 04:04:11PM +0000, Sven Luther wrote:
> > > >I am a bit bewildered by what you are doing here. How does this mv64x60 
> > > >code relate to the mv643xx_eth driver from the mips folk ? 
> > 
> > [...]
> > 
> > On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> > > has spent a lot of time making it work on both MIPS and PPC.  The code 
> > > you see in the mv64x60.c file is a part of that.  I believe that Dale's 
> > 
> > Ok, so the code in question is in addition to the existing driver from the
> > mips guys and works with it ? I had the impression that it was a separate
> > driver development or something.
> 
> The code in mv64x60.c is related to but separate from the ethernet driver.
> It is platform-specific code that passes register addresses, irqs,
> mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.
> 
> All of my changes to the mv643xx ethernet driver have been posted to
> LKML or the netdev list.  I have removed all arch-specific code from
> the ethernet driver itself.

What is the status of this with regard to the 2.6.11 mainline kernel ?

> > Ok. Do you know if Dale's patches are available separatedly while they are not
> > yet in mainline, so Nicolas Det can work on them and make sure they also work
> > on the Pegasos board, which is not an embedded board but from the chrp
> 
> See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
direct related code between the ppc specific mv64x60 stuff, and the mips
related ethernet one.

> > lineage. Nicolas already did some mv643xx ethernet driver work last summer,
> > but apparently had trouble integrating this in the mainline kernel, and it
> 
> I'm sorry I wasn't aware of Nicolas' work on the driver.
> 
> > seems his work has now been redone by Dale or something. Do you know who the
> > right person to communicate with about this would be ? The MIPS folk didn't
> > reply to any of our mails about this subject.
> 
> Sounds familiar.  Fortunately, Jeff Garzik picked up my changes.
> I would appreciate feedback from you or Nicolas on the current driver.

Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to
port your work to the pegasos, but what i have seen from the code in the
mainline kernel doesn't really make sense.

Friendly,

Sven Luther

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > On Thu, Feb 24, 2005 at 04:04:11PM +0000, Sven Luther wrote:
> > > > >I am a bit bewildered by what you are doing here. How does this mv64x60 
> > > > >code relate to the mv643xx_eth driver from the mips folk ? 
> > > 
> > > [...]
> > > 
> > > On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote:
> > > > has spent a lot of time making it work on both MIPS and PPC.  The code 
> > > > you see in the mv64x60.c file is a part of that.  I believe that Dale's 
> > > 
> > > Ok, so the code in question is in addition to the existing driver from the
> > > mips guys and works with it ? I had the impression that it was a separate
> > > driver development or something.
> > 
> > The code in mv64x60.c is related to but separate from the ethernet driver.
> > It is platform-specific code that passes register addresses, irqs,
> > mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.
> > 
> > All of my changes to the mv643xx ethernet driver have been posted to
> > LKML or the netdev list.  I have removed all arch-specific code from
> > the ethernet driver itself.
> 
> What is the status of this with regard to the 2.6.11 mainline kernel ?
> 
> > > Ok. Do you know if Dale's patches are available separatedly while they are not
> > > yet in mainline, so Nicolas Det can work on them and make sure they also work
> > > on the Pegasos board, which is not an embedded board but from the chrp
> > 
> > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> 
> I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> direct related code between the ppc specific mv64x60 stuff, and the mips
> related ethernet one.

Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
those are just 64340-> 643xx replacements though.

What are your plans for mainline inclusion of the rest of those, and is it ok
to work directly with your stuff ? Do you have any experimental or dangerous
parts in the above ? And did you ever get the gigabit ethernet port working on
a powerpc board ? Or are there some Kconfig parts i have missed ?

Friendly,

Sven Luther

Re: [PATCH][PPC32] mv64x60 updates

[Dale Farnsworth]

On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > All of my changes to the mv643xx ethernet driver have been posted to
> > LKML or the netdev list.  I have removed all arch-specific code from
> > the ethernet driver itself.
> 
> What is the status of this with regard to the 2.6.11 mainline kernel ?

I'm hopeful they will go in this week to make 2.6.12

> > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> 
> I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> direct related code between the ppc specific mv64x60 stuff, and the mips
> related ethernet one.

Yes.

> Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to
> port your work to the pegasos, but what i have seen from the code in the
> mainline kernel doesn't really make sense.

Benh also mentioned porting it to pegasos, but I haven't heard that he's
gotten to it.

-Dale

Re: [PATCH][PPC32] mv64x60 updates

[Dale Farnsworth]

On Sat, Mar 05, 2005 at 09:32:54PM +0100, Sven Luther wrote:
> On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> > On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> > 
> > I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> > direct related code between the ppc specific mv64x60 stuff, and the mips
> > related ethernet one.
> 
> Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
> those are just 64340-> 643xx replacements though.

Yes, renames and Lindent make for big diffs.

> What are your plans for mainline inclusion of the rest of those, and is it ok

I've submitted it for mainline inclusion.  Jeff Garzik put it in
netdev-2.6 (and thus in the mm patches) for testing and it's on track
for going into mainline.  I hope it will happen in the next few days,
but that's up to Jeff.

> to work directly with your stuff ? Do you have any experimental or dangerous
> parts in the above ? And did you ever get the gigabit ethernet port working on
> a powerpc board ? Or are there some Kconfig parts i have missed ?

By all means, try it.  Several people are using it without complaints, but
I'd appreciate your feedback.  There isn't anything dangerous in there.
Gigabit works for me.  I'm not sure what Kconfig parts would be needed
specifically for gigabit support.

Updates are coming though.  James Chapman has sent me several patches
that provide: use of the mii library for phy management, additional
ethtool support, message level support, compile fix for non-NAPI, and
much cleanup.  We're working the kinks out now and I expect to submit
these patches in the next few days.

Thanks,
-Dale

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> On Sat, Mar 05, 2005 at 09:32:54PM +0100, Sven Luther wrote:
> > On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote:
> > > On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote:
> > > > See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet
> > > 
> > > I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be
> > > direct related code between the ppc specific mv64x60 stuff, and the mips
> > > related ethernet one.
> > 
> > Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of
> > those are just 64340-> 643xx replacements though.
> 
> Yes, renames and Lindent make for big diffs.

Ah, ...

Well, maybe i will need to do a minimal patch without renaming for the debian
2.6.11 kernel, but we will see.

> > What are your plans for mainline inclusion of the rest of those, and is it ok
> 
> I've submitted it for mainline inclusion.  Jeff Garzik put it in
> netdev-2.6 (and thus in the mm patches) for testing and it's on track
> for going into mainline.  I hope it will happen in the next few days,
> but that's up to Jeff.

Ok.

> > to work directly with your stuff ? Do you have any experimental or dangerous
> > parts in the above ? And did you ever get the gigabit ethernet port working on
> > a powerpc board ? Or are there some Kconfig parts i have missed ?
> 
> By all means, try it.  Several people are using it without complaints, but
> I'd appreciate your feedback.  There isn't anything dangerous in there.
> Gigabit works for me.  I'm not sure what Kconfig parts would be needed
> specifically for gigabit support.

I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
build it, and even insmod it, but the module doesn't do a thing, and not even
a single line shows up in dmesg. I guess i am either missing a part of the
patch or there is something wrong with the probe code.

I have gotten the diff against : 

include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
adding :

 config MV643XX_ETH
        tristate "MV-643XX Ethernet support"
-       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
+       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
        help
          This driver supports the gigabit Ethernet on the Marvell MV643XX
-         chipset which is used in the Momenco Ocelot C and Jaguar ATX.
+         chipset which is used in the Momenco Ocelot C and Jaguar ATX and
+         Pegasos II, amongst other PPC and MIPS boards.

I have no idea where your MV64360 comes from, it seems to be not existent in
any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
combo :/ Will have to look more.

Anyway, how do you probe for the chip ? On the pegasos we used to map on the
marvell pci id :

  0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
  System Controller (rev 03)

too bad Marvell didn't do the logical thing and made the ethernet port appear
as separated devices on a third internal pci bus.

> Updates are coming though.  James Chapman has sent me several patches
> that provide: use of the mii library for phy management, additional
> ethtool support, message level support, compile fix for non-NAPI, and
> much cleanup.  We're working the kinks out now and I expect to submit
> these patches in the next few days.

Ok, let's make sure it works on pegasos before then.

Friendly,

Sven Luther

Re: [PATCH][PPC32] mv64x60 updates

[Dale Farnsworth]

On Sun, Mar 06, 2005 at 08:02:48AM +0100, Sven Luther wrote:
> On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> > By all means, try it.  Several people are using it without complaints, but
> > I'd appreciate your feedback.  There isn't anything dangerous in there.
> > Gigabit works for me.  I'm not sure what Kconfig parts would be needed
> > specifically for gigabit support.
> 
> I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
> build it, and even insmod it, but the module doesn't do a thing, and not even
> a single line shows up in dmesg. I guess i am either missing a part of the
> patch or there is something wrong with the probe code.
> 
> I have gotten the diff against : 
> 
> include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
> adding :
> 
>  config MV643XX_ETH
>         tristate "MV-643XX Ethernet support"
> -       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
> +       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
>         help
>           This driver supports the gigabit Ethernet on the Marvell MV643XX
> -         chipset which is used in the Momenco Ocelot C and Jaguar ATX.
> +         chipset which is used in the Momenco Ocelot C and Jaguar ATX and
> +         Pegasos II, amongst other PPC and MIPS boards.
> 
> I have no idea where your MV64360 comes from, it seems to be not existent in
> any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
> recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
> combo :/ Will have to look more.

MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
CHESTNUT.  If I understand correctly, it should be defined for any
board using the MV64360.  I don't think we want the PPC_CHRP dependency.

> Anyway, how do you probe for the chip ? On the pegasos we used to map on the
> marvell pci id :
> 
>   0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
>   System Controller (rev 03)
> 
> too bad Marvell didn't do the logical thing and made the ethernet port appear
> as separated devices on a third internal pci bus.

The mv643xx_eth probe is dependent on having the appropriate
platform device entry.  See eth0_device and mv64x60_add_pds() in
arch/ppc/syslib/mv643x60.c .

-Dale

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> On Sun, Mar 06, 2005 at 08:02:48AM +0100, Sven Luther wrote:
> > On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote:
> > > By all means, try it.  Several people are using it without complaints, but
> > > I'd appreciate your feedback.  There isn't anything dangerous in there.
> > > Gigabit works for me.  I'm not sure what Kconfig parts would be needed
> > > specifically for gigabit support.
> > 
> > I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to
> > build it, and even insmod it, but the module doesn't do a thing, and not even
> > a single line shows up in dmesg. I guess i am either missing a part of the
> > patch or there is something wrong with the probe code.
> > 
> > I have gotten the diff against : 
> > 
> > include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig,
> > adding :
> > 
> >  config MV643XX_ETH
> >         tristate "MV-643XX Ethernet support"
> > -       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
> > +       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
> >         help
> >           This driver supports the gigabit Ethernet on the Marvell MV643XX
> > -         chipset which is used in the Momenco Ocelot C and Jaguar ATX.
> > +         chipset which is used in the Momenco Ocelot C and Jaguar ATX and
> > +         Pegasos II, amongst other PPC and MIPS boards.
> > 
> > I have no idea where your MV64360 comes from, it seems to be not existent in
> > any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a
> > recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find
> > combo :/ Will have to look more.
> 
> MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> CHESTNUT.  If I understand correctly, it should be defined for any
> board using the MV64360.  I don't think we want the PPC_CHRP dependency.

Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
board, but since it is a generic PPC_CHRP, how is that supposed to work ? 

Could you send me maybe a list of files which need merging yet, compared to
2.6.11 ? I guess it just doesn't work because i am missing pieces.

> > Anyway, how do you probe for the chip ? On the pegasos we used to map on the
> > marvell pci id :
> > 
> >   0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362
> >   System Controller (rev 03)
> > 
> > too bad Marvell didn't do the logical thing and made the ethernet port appear
> > as separated devices on a third internal pci bus.
> 
> The mv643xx_eth probe is dependent on having the appropriate
> platform device entry.  See eth0_device and mv64x60_add_pds() in
> arch/ppc/syslib/mv643x60.c .

The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
(only port1 is wired though) mapped at interrupt 9, shared with other devices.
I guess that would be the only real difference with the other currently
supported hardware, right ? 

Will look at the above mentioned files and function and try to enable it.

Friendly,

Sven Luther

Re: mv64x60 updates

[Nicolas DET]

Hello Sven,

On 06/03/2005, you wrote:

> Ah, i guess that was the missing bit. Basically i need to set MV64360 for
> my board, but since it is a generic PPC_CHRP, how is that supposed to
> work ?  
> Could you send me maybe a list of files which need merging yet, compared
> to 2.6.11 ? I guess it just doesn't work because i am missing pieces.

I fixed that here.
TheKconfig issue is really minor compared to the rest :-)

>> > Anyway, how do you probe for the chip ? On the pegasos we used to map
>> > on the marvell pci id :
>> > 
>> >   0000:00:00.0 Host bridge: Marvell Technology Group Ltd.
>> > MV64360/64361/64362   System Controller (rev 03)
>> > 
>> > too bad Marvell didn't do the logical thing and made the ethernet port
>> > appear as separated devices on a third internal pci bus.
>> 
>> The mv643xx_eth probe is dependent on having the appropriate
>> platform device entry.  See eth0_device and mv64x60_add_pds() in
>> arch/ppc/syslib/mv643x60.c .

> The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> (only port1 is wired though) mapped at interrupt 9, shared with other
> devices. I guess that would be the only real difference with the other
> currently supported hardware, right ? 

Yeah, and also, Pegasos II kernel shouldn't call all the chipset init call
which has been added.
Pegasos II chipset init is done by the OFW. OSs kernel shouldn't have to
touch it much.

> Will look at the above mentioned files and function and try to enable it.

I already patch a bit the kernel. However, enabling new Marvell code means
not booting anymore ATM.
I'm trying to find a way to patch the current source, without breaking
Katana & friends support.

The smartest could be to move all unneeded/board specific code somewhere
else (chipset init...) and to keep ony the minimal (only
platform_get_resource() realted stuff), in arch/ppc/syslib/mv64x60*

Regards
-- 
Nicolas DET
MorphOS & Linux developer

Re: [PATCH][PPC32] mv64x60 updates

[Dale Farnsworth]

On Sun, Mar 06, 2005 at 08:10:34PM +0100, Sven Luther wrote:
> On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> > MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> > CHESTNUT.  If I understand correctly, it should be defined for any
> > board using the MV64360.  I don't think we want the PPC_CHRP dependency.
> 
> Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
> board, but since it is a generic PPC_CHRP, how is that supposed to work ? 
> 
> Could you send me maybe a list of files which need merging yet, compared to
> 2.6.11 ? I guess it just doesn't work because i am missing pieces.

I would be guessing, since I've focused on the ethernet driver.  Mark
Greer <mgreer@mvista.com> has done the core mv64[34]60 core support.
Nicholas is working with regarding Pegasos II support.

> The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> (only port1 is wired though) mapped at interrupt 9, shared with other devices.
> I guess that would be the only real difference with the other currently
> supported hardware, right ? 

Nicholas implied that the PCI IRQs are different as well.

-Dale

Re: [PATCH][PPC32] mv64x60 updates

[Sven Luther]

On Sun, Mar 06, 2005 at 06:00:58PM -0700, Dale Farnsworth wrote:
> On Sun, Mar 06, 2005 at 08:10:34PM +0100, Sven Luther wrote:
> > On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote:
> > > MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and
> > > CHESTNUT.  If I understand correctly, it should be defined for any
> > > board using the MV64360.  I don't think we want the PPC_CHRP dependency.
> > 
> > Ah, i guess that was the missing bit. Basically i need to set MV64360 for my
> > board, but since it is a generic PPC_CHRP, how is that supposed to work ? 
> > 
> > Could you send me maybe a list of files which need merging yet, compared to
> > 2.6.11 ? I guess it just doesn't work because i am missing pieces.
> 
> I would be guessing, since I've focused on the ethernet driver.  Mark
> Greer <mgreer@mvista.com> has done the core mv64[34]60 core support.
> Nicholas is working with regarding Pegasos II support.

Nicolas even, and i work with him on this.

> > The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports
> > (only port1 is wired though) mapped at interrupt 9, shared with other devices.
> > I guess that would be the only real difference with the other currently
> > supported hardware, right ? 
> 
> Nicholas implied that the PCI IRQs are different as well.

The real problem as far as i see it, is that the mv6[34]60 code does too much.
The pegasos OpenFirmware implementation initializes the chip, and we really
only need the ethernet part. It seems that the code from Mark Greer
initializes the whole stuff, since it has no usefull firmware under it anyway,
and thus mis-initializes some of it and thus fully break everything.

Mark, any comment on this ? 

But i hear Nicolas has done some useful work yesterday evening, i will review
it as soon as he is back from dreamland :)

Friendly,

Sven Luther

Re: mv64x60 updates

[Nicolas DET]

Hello Sven,

On 07/03/2005, you wrote:

> But i hear Nicolas has done some useful work yesterday evening, i will
> review it as soon as he is back from dreamland :)

You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2

This patch shouldn't break mv code for others platform (non PegasosII), and
fix Pegasos II init...

Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:

in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
ressources tables for Pegasos II hardware (register base & IRQ).
in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
request_irq if pegasos II detected

The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
because I use this function to use the correct flags in the ethernet
driver.

Of course, this patch may be discuss as there are several architecture
using Marvell chipsets and each requieres some specific code.
I don't know where it's the best to place mv64360_ispeasos2(), maybe this
func could even be renamed mv64x60_ispegasos2()..

Please, people from others MV64x60 architectures review this patch, modify
if it neeeded and check it doesn't break your architecture (I shouldn't but
for MIPS ethernet).

Regards
-- 
Nicolas DET
MorphOS & Linux developer

Re: mv64x60 updates

[Nicolas DET]

Hello Sven,

On 07/03/2005, you wrote:

> But i hear Nicolas has done some useful work yesterday evening, i will
> review it as soon as he is back from dreamland :)

You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2

This patch shouldn't break mv code for others platform (non PegasosII), and
fix Pegasos II init...

Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:

in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
ressources tables for Pegasos II hardware (register base & IRQ).
in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
request_irq if pegasos II detected

The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
because I use this function to use the correct flags in the ethernet
driver.

Of course, this patch may be discuss as there are several architecture
using Marvell chipsets and each requieres some specific code.
I don't know where it's the best to place mv64360_ispeasos2(), maybe this
func could even be renamed mv64x60_ispegasos2()..

Please, people from others MV64x60 architectures review this patch, modify
if it neeeded and check it doesn't break your architecture (I shouldn't but
for MIPS ethernet).

Regards
-- 
Nicolas DET
MorphOS & Linux developer

Re: mv64x60 updates

[James Chapman]

Hi Nicolas,

A few general comments:-

- mv64x60 stuff is best posted to linuxppc-embedded

- you change several generic files to support your platform. It should
   be possible to support new mv64x60 platforms by writing a new
   xxx_setup.c file in arch/ppc/platforms with no other generic changes.
   It is a goal that all mv64x60 boards can be supported by the generic
   code in arch/ppc/syslib. If some changes need to be made outside
   arch/ppc/platforms to support your board, try to make them generic so
   that other similar boards would be able to use them. I suggest you
   clone chrp_setup.c or katana.c rather than adding conditionals in
   chrp_setup.c for your board. Then use code in your board specific
   setup file to call arch/ppc/syslib mv64x60 routines as appropriate.

- you shouldn't need to add board-specific changes in mv643xx_eth.c.
   Setup device platform data for your board in your platform file.
   If something needs to be added to the platform data for a generic
   change to mv643xx_eth, do that rather than add platform conditionals
   in the driver.

- why do you need to use SA_SHIRQ in the ethernet driver?

/james

Nicolas DET wrote:

> Hello Sven,
> 
> On 07/03/2005, you wrote:
> 
> 
>>But i hear Nicolas has done some useful work yesterday evening, i will
>>review it as soon as he is back from dreamland :)
> 
> 
> You can find the patch against 2.6.11 from kernel.org here:
> http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2
> 
> This patch shouldn't break mv code for others platform (non PegasosII), and
> fix Pegasos II init...
> 
> Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:
> 
> in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
> in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
> ressources tables for Pegasos II hardware (register base & IRQ).
> in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
> in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
> mv64x60_init() if CONFIG_MV64x60
> in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
> request_irq if pegasos II detected
> 
> The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
> because I use this function to use the correct flags in the ethernet
> driver.
> 
> Of course, this patch may be discuss as there are several architecture
> using Marvell chipsets and each requieres some specific code.
> I don't know where it's the best to place mv64360_ispeasos2(), maybe this
> func could even be renamed mv64x60_ispegasos2()..
> 
> Please, people from others MV64x60 architectures review this patch, modify
> if it neeeded and check it doesn't break your architecture (I shouldn't but
> for MIPS ethernet).
> 
> Regards

Re: mv64x60 updates

[Sven Luther]

On Mon, Mar 07, 2005 at 12:30:19PM +0000, James Chapman wrote:
> Hi Nicolas,
> 
> A few general comments:-
> 
> - mv64x60 stuff is best posted to linuxppc-embedded

The pegasos is not an embedded machine though, but i guess it is on -embedded
where the people using it are.

> - you change several generic files to support your platform. It should
>   be possible to support new mv64x60 platforms by writing a new
>   xxx_setup.c file in arch/ppc/platforms with no other generic changes.

Well, the pegasos is a chrp, so most of the stuff is in chrp_setup.c already.

>   It is a goal that all mv64x60 boards can be supported by the generic
>   code in arch/ppc/syslib. If some changes need to be made outside

I don't think this is sane. The generic mv64x60 stuff is for embedded boards, 
and does initialize too much stuff for the pegasos. At least in the current
state of it, which is why i asked about Mark's comments about our case.

>   arch/ppc/platforms to support your board, try to make them generic so
>   that other similar boards would be able to use them. I suggest you
>   clone chrp_setup.c or katana.c rather than adding conditionals in

Why ? The pegasos is a chrp, and it works perfectly with the chrp_setup stuff,
we just need to add the necessary code for making use of the gige interface of
the marvell, the rest works perfectly in chrp.

>   chrp_setup.c for your board. Then use code in your board specific
>   setup file to call arch/ppc/syslib mv64x60 routines as appropriate.

Yep.

> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
>   Setup device platform data for your board in your platform file.
>   If something needs to be added to the platform data for a generic
>   change to mv643xx_eth, do that rather than add platform conditionals
>   in the driver.

Ok.

> - why do you need to use SA_SHIRQ in the ethernet driver?

I think because the two ports share the irq with other devices, not sure
though.

Friendly,

Sven Luther

Re: mv64x60 updates

[Nicolas DET]

Hello James,

On 07/03/2005, you wrote:
> Hi Nicolas,

> A few general comments:-

> - mv64x60 stuff is best posted to linuxppc-embedded

ok.
I would just add that our platform (Pegasos II) is using MV64361 from
Marvell and is a complete computer.

> - you change several generic files to support your platform. It should
>    be possible to support new mv64x60 platforms by writing a new
>    xxx_setup.c file in arch/ppc/platforms with no other generic changes.
>    It is a goal that all mv64x60 boards can be supported by the generic
>    code in arch/ppc/syslib. If some changes need to be made outside
>    arch/ppc/platforms to support your board, try to make them generic so
>    that other similar boards would be able to use them. I suggest you
>    clone chrp_setup.c or katana.c rather than adding conditionals in
>    chrp_setup.c for your board. Then use code in your board specific
>    setup file to call arch/ppc/syslib mv64x60 routines as appropriate.

There is almost no changes compare to 2.6.11 (from kernel.org).

Pegasos II is a CHRP machine, as a result all related code is inside
arch/ppc/platform/chrp_*
There is almost nothing to do (but normal CHRP stuff) for the Pegasos
machine. I don't think it's plan clone
chrp_setup.c
I think Sven Luther could answer this better than me anyway.

About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
hardcoded IRQ, hardcoded register base, it changes 
chipset configuration... whereas all of these is already done by the
Pegasos II OpenFirmWare.

I'm open to any solution to have every MV64x60 platform supported.
The Pegasos would _only_ requiere to get correct IRQ and register base for
get_resources stuff and to have the correct flags for the request_irq().
This is only for the ethernet driver.

> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
>    Setup device platform data for your board in your platform file.
>    If something needs to be added to the platform data for a generic
>    change to mv643xx_eth, do that rather than add platform conditionals
>    in the driver.

In this case, the ethernet driver should get the request_irq() flags from
something in arch/ppc/ or arch/mips/

> - why do you need to use SA_SHIRQ in the ethernet driver?

Because the IRQ we use for ethernet is shared with others devices.

Regards
-- 
Nicolas DET
MorphOS & Linux developer

Re: mv64x60 updates

[Sven Luther]

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

On Mon, Mar 07, 2005 at 01:57:39PM +0100, Nicolas DET wrote:
> Hello James,
> 
> On 07/03/2005, you wrote:
> > Hi Nicolas,
> 
> > A few general comments:-
> 
> > - mv64x60 stuff is best posted to linuxppc-embedded
> 
> ok.
> I would just add that our platform (Pegasos II) is using MV64361 from
> Marvell and is a complete computer.

Cross-posting to linuxppc-embedded to reach everyone. In particular comments
from Mark and Dale are welcome.

> > - you change several generic files to support your platform. It should
> >    be possible to support new mv64x60 platforms by writing a new
> >    xxx_setup.c file in arch/ppc/platforms with no other generic changes.
> >    It is a goal that all mv64x60 boards can be supported by the generic
> >    code in arch/ppc/syslib. If some changes need to be made outside
> >    arch/ppc/platforms to support your board, try to make them generic so
> >    that other similar boards would be able to use them. I suggest you
> >    clone chrp_setup.c or katana.c rather than adding conditionals in
> >    chrp_setup.c for your board. Then use code in your board specific
> >    setup file to call arch/ppc/syslib mv64x60 routines as appropriate.
> 
> There is almost no changes compare to 2.6.11 (from kernel.org).

I have appended a (slightly revised) version of the patch, which is against a
saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet, 
which is what Mark and Dale are working on. Viewed like that the patch is
against to really manageable size, altough it may need some fine-tuning. The
rest of your comments probably apply to Dale's and Mark's work in the above
tree though.

Friendly,

Sven Luther

[-- Attachment #2: nico2.diff --]
[-- Type: text/plain, Size: 9389 bytes --]

--- linux-2.5-mv643xx-enet/arch/ppc/boot/simple/Makefile	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/boot/simple/Makefile	2005-03-07 14:13:14.000000000 +0100
@@ -162,7 +162,7 @@
 boot-$(CONFIG_8260)		+= embed_config.o
 boot-$(CONFIG_BSEIP)		+= iic.o
 boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
-boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
+boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o mv64x60_stub.o
 boot-$(CONFIG_RPXCLASSIC)	+= iic.o pci.o qspan_pci.o
 boot-$(CONFIG_RPXLITE)		+= iic.o
 # Different boards need different serial implementations.
--- linux-2.5-mv643xx-enet/arch/ppc/platforms/chrp_setup.c	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/platforms/chrp_setup.c	2005-03-07 14:13:14.000000000 +0100
@@ -217,8 +217,13 @@
 	}
 }
 
+#ifdef CONFIG_MV64X60
+#include <linux/mv643xx.h>
+#include <asm/mv64x60.h>
+#endif
+
 
-static void __init pegasos_set_l2cr(void)
+static void __init pegasos_stuff(void)
 {
 	struct device_node *np;
 
@@ -242,6 +247,19 @@
 			_set_L2CR((*l2cr) | 0x80000000);
 		}
 	}
+
+#ifdef CONFIG_MV64X60
+	// Pegasos II (MV64361)
+	// We have to call mv64x60_init() in arch/ppc/syslib/mv64x60.c 
+	// This call will do NOTHING but set the correct value for IRQ & reg base...
+	// This is needed because new Marvell ethernet driver get theses info from
+	// there
+	{
+		static struct mv64x60_handle bh;
+		static struct mv64x60_setup_info si;
+		mv64x60_init(&bh, &si);
+	}
+#endif
 }
 
 void __init chrp_setup_arch(void)
@@ -262,7 +280,7 @@
 		ROOT_DEV = Root_SDA2; /* sda2 (sda1 is for the kernel) */
 
 	/* On pegasos, enable the L2 cache if not already done by OF */
-	pegasos_set_l2cr();
+	pegasos_stuff();
 
 	/* Lookup PCI host bridges */
 	chrp_find_bridges();
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/Makefile	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/Makefile	2005-03-07 14:13:14.000000000 +0100
@@ -59,8 +59,8 @@
 					open_pic.o i8259.o hawk_common.o
 obj-$(CONFIG_MENF1)		+= todc_time.o i8259.o mpc10x_common.o \
 					pci_auto.o indirect_pci.o
-obj-$(CONFIG_MV64360)		+= mv64360_pic.o
-obj-$(CONFIG_MV64X60)		+= mv64x60.o mv64x60_win.o indirect_pci.o
+obj-$(CONFIG_MV64360)		+=
+obj-$(CONFIG_MV64X60)		+= mv64x60.o mv64x60_win.o indirect_pci.o mv64360_pic.o
 obj-$(CONFIG_MVME5100)		+= open_pic.o todc_time.o indirect_pci.o \
 					pci_auto.o hawk_common.o
 obj-$(CONFIG_MVME5100_IPMC761_PRESENT)	+= i8259.o
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/mv64360_pic.c	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/mv64360_pic.c	2005-03-07 14:13:14.000000000 +0100
@@ -369,6 +369,10 @@
 	u32	mask;
 	int	rc;
 
+	if ( mv64360_ispegasos2() ) return 0;
+
+	printk("not pegasos\n");
+
 	/* Clear old errors and register CPU interface error intr handler */
 	mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
 	if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/mv64x60.c	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/mv64x60.c	2005-03-07 14:21:04.000000000 +0100
@@ -314,15 +314,15 @@
 static struct resource mv64x60_eth_shared_resources[] = {
 	[0] = {
 		.name	= "ethernet shared base",
-		.start	= MV64340_ETH_SHARED_REGS,
-		.end	= MV64340_ETH_SHARED_REGS +
-					MV64340_ETH_SHARED_REGS_SIZE - 1,
+		.start	= MV643XX_ETH_SHARED_REGS,
+		.end	= MV643XX_ETH_SHARED_REGS +
+					MV643XX_ETH_SHARED_REGS_SIZE - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 };
 
 static struct platform_device mv64x60_eth_shared_device = {
-	.name		= MV64XXX_ETH_SHARED_NAME,
+	.name		= MV643XX_ETH_SHARED_NAME,
 	.id		= 0,
 	.num_resources	= ARRAY_SIZE(mv64x60_eth_shared_resources),
 	.resource	= mv64x60_eth_shared_resources,
@@ -341,7 +341,7 @@
 static struct mv64xxx_eth_platform_data eth0_pd;
 
 static struct platform_device eth0_device = {
-	.name		= MV64XXX_ETH_NAME,
+	.name		= MV643XX_ETH_NAME,
 	.id		= 0,
 	.num_resources	= ARRAY_SIZE(mv64x60_eth0_resources),
 	.resource	= mv64x60_eth0_resources,
@@ -361,10 +361,10 @@
 	},
 };
 
-static struct mv64xxx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd;
 
 static struct platform_device eth1_device = {
-	.name		= MV64XXX_ETH_NAME,
+	.name		= MV643XX_ETH_NAME,
 	.id		= 1,
 	.num_resources	= ARRAY_SIZE(mv64x60_eth1_resources),
 	.resource	= mv64x60_eth1_resources,
@@ -475,17 +475,58 @@
 {
 	u32	mem_windows[MV64x60_CPU2MEM_WINDOWS][2];
 
-	if (ppc_md.progress)
-		ppc_md.progress("mv64x60 initialization", 0x0);
+	if (ppc_md.progress) ppc_md.progress("mv64x60 initialization", 0x0);
+
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+	if (mv64360_ispegasos2())
+	{
+		// Pegasos II stuff
+
+		if (ppc_md.progress)
+			ppc_md.progress("mv64x60: Pegasos II Detected, skiping most of the init code & patching the ressources tables", 0x0);
+
+		spin_lock_init(&mv64x60_lock);
+
+		if (mv64x60_get_type(bh) || mv64x60_setup_for_chip(bh))
+		{
+			if (ppc_md.progress) ppc_md.progress("mv64x60_init: Init error", 0x0);
+			return -1;
+		}
+
+		// Pegasos II use IRQ 9 for every port
+		// Also notice that the ethernet driver (& others) have to 
+		// use SA_SHIRQ instead of SA_INTERRUPT
+		// Also the Pegasos II has only port 0 & 1 available (MV64361)
+		
+#ifdef CONFIG_MV643XX_ETH_0
+		mv64x60_eth0_resources[0].start = 9;
+		mv64x60_eth0_resources[0].end = 9;
+#endif
 
+#ifdef CONFIG_MV643XX_ETH_1
+		mv64x60_eth1_resources[0].start = 9;
+		mv64x60_eth1_resources[0].end = 9;
+#endif
+
+		// Marvell register is at 0xf1000000 on Pegasos II
+		mv64x60_eth_shared_resources[0].start = 0xf1000000 + MV643XX_ETH_SHARED_REGS;
+		mv64x60_eth_shared_resources[0].end = 0xf1000000 + MV643XX_ETH_SHARED_REGS + MV643XX_ETH_SHARED_REGS_SIZE - 1;
+	
+		// For Pegasos II, we stop here
+		// Indeed, we only need the resources info for
+		// the ethernet driver ATM
+		if (ppc_md.progress) ppc_md.progress("mv64x60: End", 0x0);
+		return 0;
+	}
+#endif
+	
 	spin_lock_init(&mv64x60_lock);
 	mv64x60_early_init(bh, si);
 
 	if (mv64x60_get_type(bh) || mv64x60_setup_for_chip(bh)) {
 		iounmap(bh->v_base);
 		bh->v_base = 0;
-		if (ppc_md.progress)
-			ppc_md.progress("mv64x60_init: Can't determine chip",0);
+		if (ppc_md.progress) ppc_md.progress("mv64x60_init: Can't determine chip",0);
 		return -1;
 	}
 
@@ -823,6 +864,18 @@
 	u16	val;
 	u8	save_exclude;
 
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+	if (mv64360_ispegasos2())
+	{
+		// we could use the OF pci stuff
+		// but we know Pegasos II use the MV64361 chipset
+		// If people think it's not nice enough I could add some PCI code
+		// to detect that using OF
+		bh->type = MV64x60_TYPE_MV64360;
+		return 0;
+	}
+#endif
+
 	memset(&hose, 0, sizeof(hose));
 	setup_indirect_pci_nomap(&hose, bh->v_base + MV64x60_PCI0_CONFIG_ADDR,
 		bh->v_base + MV64x60_PCI0_CONFIG_DATA);
--- linux-2.5-mv643xx-enet/drivers/net/Kconfig	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/drivers/net/Kconfig	2005-03-07 14:13:14.000000000 +0100
@@ -2094,11 +2094,11 @@
 
 config MV643XX_ETH
 	tristate "MV-643XX Ethernet support"
-	depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360
+	depends on MOMENCO_OCELOT_CA || MOMENCO_JAGUAR_ATX || MV64X60
 	help
 	  This driver supports the gigabit Ethernet on the Marvell MV643XX
-	  chipset which is used in the Momenco Ocelot C and Jaguar ATX and
-	  Pegasos II, amongst other PPC and MIPS boards.
+	  chipset which is used in the Momenco Ocelot C, Jaguar ATX and
+	  bPlan Pegasos II computer.
 
 config MV643XX_ETH_0
 	bool "MV-643XX Port 0"
--- linux-2.5-mv643xx-enet/drivers/net/mv643xx_eth.c	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/drivers/net/mv643xx_eth.c	2005-03-07 14:25:38.000000000 +0100
@@ -44,6 +44,7 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/delay.h>
+#include <asm/mv64x60.h>
 #include "mv643xx_eth.h"
 
 /*
@@ -664,11 +665,16 @@
 	struct mv643xx_private *mp = netdev_priv(dev);
 	unsigned int port_num = mp->port_num;
 	int err;
-
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+	int IRQ_Flags = mv64360_ispegasos2() ? SA_SHIRQ : SA_INTERRUPT;
+#else
+	int IRQ_Flags = SA_INTERRUPT;
+#endif
+	
 	spin_lock_irq(&mp->lock);
 
 	err = request_irq(dev->irq, mv643xx_eth_int_handler,
-			SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev);
+			IRQ_Flags | SA_SAMPLE_RANDOM, dev->name, dev);
 
 	if (err) {
 		printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n",
@@ -1383,6 +1389,8 @@
 	BUG_ON(!res);
 	dev->irq = res->start;
 
+	printk(KERN_INFO "%s: Using IRQ %d\n", __func__, dev->irq);
+
 	mp->port_num = port_num;
 
 	dev->open = mv643xx_eth_open;
@@ -1587,6 +1595,8 @@
 		if (rc)
 			driver_unregister(&mv643xx_eth_shared_driver);
 	}
+
+	printk("%s: return %d\n", __func__, rc);
 	return rc;
 }
 
--- linux-2.5-mv643xx-enet/include/asm-ppc/mv64x60.h	2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/include/asm-ppc/mv64x60.h	2005-03-07 14:18:27.000000000 +0100
@@ -27,6 +27,19 @@
 #include <asm/pci-bridge.h>
 #include <asm/mv64x60_defs.h>
 
+/*
+ * return 1 if you are on a Pegasos II, 0 otherwise
+ * this code is useful to execute the correct code 
+ * on the correct machine
+ * 
+*/
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+extern inline int mv64360_ispegasos2(void)
+{
+	return ((_machine == _MACH_chrp) && (_chrp_type == _CHRP_Pegasos)) ? 1 : 0;
+}
+#endif
+
 extern u8	mv64x60_pci_exclude_bridge;
 
 extern spinlock_t mv64x60_lock;

Re: mv64x60 updates

[Linwoes]

>
> About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
> hardcoded IRQ, hardcoded register base, it changes
> chipset configuration... whereas all of these is already done by the
> Pegasos II OpenFirmWare.
>
All of the hardcoded IRQs are not really hardcoded. They are easily 
overridable in you platform file using a fixup routine as seen in katana.c 
flags can be added also. 

As far as the register base being hardcoded, I don't see it. The config 
options:
CONFIG_MV64X60_BASE=0xf1000000
CONFIG_MV64X60_NEW_BASE=0xf1000000
will allow you register base to be anywhere you would like it.

If you don't need to reinitialize the chip, then don't call mv64x60_init(). 
The only part of mv64x60_init() I see that is not chip related is the 
pci_alloc_hoses(). I guess you could make a new function for that part and 
maybe others you need so the code does not get duplicated in your platform 
files.
Again, mv64x60_early_init() does very little non-chipset stuff and you could 
probably just place the:
        mv64x60_bridge_pbase = bh->p_base;
        mv64x60_bridge_vbase = bh->v_base;
initializers into your platform files.

Thanks
Brian

Re: mv64x60 updates

[Mark A. Greer]

Sven Luther wrote:

>I have appended a (slightly revised) version of the patch, which is against a
>saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet, 
>which is what Mark and Dale are working on. Viewed like that the patch is
>against to really manageable size, altough it may need some fine-tuning. The
>rest of your comments probably apply to Dale's and Mark's work in the above
>tree though.
>  
>

Hi guys.  I got in late today so I'm just reading this thread now.

I basically want to reiterate and expand on what Brian 
<linwoes@gmail.com> stated.

The arch/ppc/syslib/mv64x60* code is really for embedded systems only.  
More accurately, its for systems whose firmwares don't do a good job of 
configuring the bridge or if you want to significantly change that 
configuration.  This ends up including many embedded systems but 
basically no "desktop"-like systems (e.g., ones with openfirmware) so 
that's why this thread should stay on linuxppc-embedded only.

Sven, et. al., your system has openfirmware and apparenly does a very 
good job of configuring the bridge so just ignore the mv64x60 stuff.  
You can use the platform_data code from there as an example of what 
needs to be passed into the enet driver (and mpsc & i2c & wdt, if you 
use them (and find all the patches :)).

If I missed something or you have any more questions, I'l be happy to help.

Mark

mv643xx_eth SA_SHIRQ support patch

[Dale Farnsworth]

On Mon, Mar 07, 2005 at 12:57:39PM +0000, Nicolas DET wrote:
> Hello James,
> > - why do you need to use SA_SHIRQ in the ethernet driver?
> 
> Because the IRQ we use for ethernet is shared with others devices.

I've included an untested patch below that adds support for passing
IRQ flags via platform device.

For the pegasos 2, you'll need the second patch which applies after
the one I previously sent for chrp_setup.c.

Sven + Nicolas, please let me know if this compiles/works for you.

Thanks,
-Dale


------------------------- Begin IRQ_flags Patch --------------------------
mv643xx: support passing ethernet IRQ flags via platform device

This patch adds a field to struct mv643xx_eth_platform_data for
passing the IRQ flags value that is passed to request_irq.

Default value is (SA_INTERRUPT | SA_SAMPLE_RANDOM).

Signed-off-by: Dale Farnsworth <dale@farnsworth.org>

Index: linux-2.5-enet/drivers/net/mv643xx_eth.h
===================================================================
--- linux-2.5-enet.orig/drivers/net/mv643xx_eth.h
+++ linux-2.5-enet/drivers/net/mv643xx_eth.h
@@ -328,6 +328,7 @@
 	u32 port_config_extend;		/* User port config extend value*/
 	u32 port_sdma_config;		/* User port SDMA config value	*/
 	u32 port_serial_control;	/* User port serial control value */
+	u32 irq_flags;			/* Flags for request_irq	*/
 	u32 port_tx_queue_command;	/* Port active Tx queues summary*/
 	u32 port_rx_queue_command;	/* Port active Rx queues summary*/
 
Index: linux-2.5-enet/include/linux/mv643xx.h
===================================================================
--- linux-2.5-enet.orig/include/linux/mv643xx.h
+++ linux-2.5-enet/include/linux/mv643xx.h
@@ -1302,6 +1302,7 @@
 	u32		port_config_extend;
 	u32		port_sdma_config;
 	u32		port_serial_control;
+	u32		irq_flags;
 	u32		tx_queue_size;
 	u32		rx_queue_size;
 	u32		tx_sram_addr;
Index: linux-2.5-enet/drivers/net/mv643xx_eth.c
===================================================================
--- linux-2.5-enet.orig/drivers/net/mv643xx_eth.c
+++ linux-2.5-enet/drivers/net/mv643xx_eth.c
@@ -667,8 +667,8 @@
 
 	spin_lock_irq(&mp->lock);
 
-	err = request_irq(dev->irq, mv643xx_eth_int_handler,
-			SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev);
+	err = request_irq(dev->irq, mv643xx_eth_int_handler, mp->irq_flags,
+			  dev->name, dev);
 
 	if (err) {
 		printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n",
@@ -1427,6 +1427,7 @@
 	mp->port_config_extend = MV643XX_ETH_PORT_CONFIG_EXTEND_DEFAULT_VALUE;
 	mp->port_sdma_config = MV643XX_ETH_PORT_SDMA_CONFIG_DEFAULT_VALUE;
 	mp->port_serial_control = MV643XX_ETH_PORT_SERIAL_CONTROL_DEFAULT_VALUE;
+	mp->irq_flags = SA_INTERRUPT | SA_SAMPLE_RANDOM;
 	mp->rx_ring_size = MV643XX_ETH_PORT_DEFAULT_RECEIVE_QUEUE_SIZE;
 	mp->tx_ring_size = MV643XX_ETH_PORT_DEFAULT_TRANSMIT_QUEUE_SIZE;
 
@@ -1450,6 +1451,9 @@
 		if (pd->port_serial_control || pd->force_port_serial_control)
 			mp->port_serial_control = pd->port_serial_control;
 
+		if (pd->irq_flags)
+			mp->irq_flags = pd->irq_flags;
+
 		if (pd->rx_queue_size)
 			mp->rx_ring_size = pd->rx_queue_size;
 
------------------------- End IRQ_flags Patch --------------------------

------------------------- Begin chrp_setup Patch --------------------------
Index: linux-2.5-enet/arch/ppc/platforms/chrp_setup.c
===================================================================
--- linux-2.5-enet.orig/arch/ppc/platforms/chrp_setup.c
+++ linux-2.5-enet/arch/ppc/platforms/chrp_setup.c
@@ -246,7 +246,9 @@
 	},
 };
 
-static struct mv643xx_eth_platform_data eth0_pd;
+static struct mv643xx_eth_platform_data eth0_pd = {
+	.irq_flags	= SA_SHIRQ | SA_SAMPLE_RANDOM;
+};
 
 static struct platform_device eth0_device = {
 	.name		= MV643XX_ETH_NAME,
@@ -267,7 +269,9 @@
 	},
 };
 
-static struct mv643xx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd = {
+	.irq_flags	= SA_SHIRQ | SA_SAMPLE_RANDOM;
+};
 
 static struct platform_device eth1_device = {
 	.name		= MV643XX_ETH_NAME,
------------------------- End chrp_setup Patch --------------------------

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Mon, Mar 07, 2005 at 03:54:01PM -0700, Dale Farnsworth wrote:
> On Mon, Mar 07, 2005 at 12:57:39PM +0000, Nicolas DET wrote:
> > Hello James,
> > > - why do you need to use SA_SHIRQ in the ethernet driver?
> > 
> > Because the IRQ we use for ethernet is shared with others devices.
> 
> I've included an untested patch below that adds support for passing
> IRQ flags via platform device.

Notice that benh is telling me that you should use SA_SHIRQ always and that
SA_INTERRUPT should go away, and that you should contact him online if you
have trouble with that.

> For the pegasos 2, you'll need the second patch which applies after
> the one I previously sent for chrp_setup.c.

Ok, will test this anyway, and tell you how it works.

> Sven + Nicolas, please let me know if this compiles/works for you.

Yep.

Friendly,

Sven Luther

Re: mv643xx_eth SA_SHIRQ support patch

[Benjamin Herrenschmidt]

> Notice that benh is telling me that you should use SA_SHIRQ always and that
> SA_INTERRUPT should go away, and that you should contact him online if you
> have trouble with that.
> 
> > For the pegasos 2, you'll need the second patch which applies after
> > the one I previously sent for chrp_setup.c.
> 
> Ok, will test this anyway, and tell you how it works.

GHeh, ok, just picked up the discussion. Yes, there is really no reason
to use SA_INTERRUPT here, this is a thing of the past.

Ben.

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Tue, Mar 08, 2005 at 05:20:48AM -0700, Dale Farnsworth wrote:
> On Tue, Mar 08, 2005 at 06:27:12PM +1100, Benjamin Herrenschmidt wrote:
> > > Notice that benh is telling me that you should use SA_SHIRQ always and that
> > > SA_INTERRUPT should go away, and that you should contact him online if you
> > > have trouble with that.
> > > 
> > > > For the pegasos 2, you'll need the second patch which applies after
> > > > the one I previously sent for chrp_setup.c.
> > > 
> > > Ok, will test this anyway, and tell you how it works.
> > 
> > GHeh, ok, just picked up the discussion. Yes, there is really no reason
> > to use SA_INTERRUPT here, this is a thing of the past.
> 
> Excellent.  Thanks.
> 
> Here's a new patch to try.  :-)

Hehe, i did that myself :)

Anyway, i have another problem though, namely that even though i do
arch_initcall(mv643xx_eth_add_pds), mv643xx_eth_add_pds is never called, and
in the mv643xx_eth driver itself, altough the module init is done, _probe
never gets called. I will now do a build without any #ifdefs around the
chrp_setup.c stuff (And Christophe Hellwig proposed moving the stuff into
arch/ppc/platform/pegasos_mv643xx_eth.c), and see if that will solve it.

Also going to add the explicit detection of the marvell bridge in the OF tree,
but need to decide what to check for there.

Friendly,

Sven Luther

Re: mv643xx_eth SA_SHIRQ support patch

[Dale Farnsworth]

On Tue, Mar 08, 2005 at 06:27:12PM +1100, Benjamin Herrenschmidt wrote:
> > Notice that benh is telling me that you should use SA_SHIRQ always and that
> > SA_INTERRUPT should go away, and that you should contact him online if you
> > have trouble with that.
> > 
> > > For the pegasos 2, you'll need the second patch which applies after
> > > the one I previously sent for chrp_setup.c.
> > 
> > Ok, will test this anyway, and tell you how it works.
> 
> GHeh, ok, just picked up the discussion. Yes, there is really no reason
> to use SA_INTERRUPT here, this is a thing of the past.

Excellent.  Thanks.

Here's a new patch to try.  :-)

-Dale

mv643xx: Always pass SA_SHIRQ to request_irq()

Signed-off-by: Dale Farnsworth <dale@farnsworth.org>

Index: linux-2.5-enet/drivers/net/mv643xx_eth.c
===================================================================
--- linux-2.5-enet.orig/drivers/net/mv643xx_eth.c
+++ linux-2.5-enet/drivers/net/mv643xx_eth.c
@@ -668,7 +668,7 @@
 	spin_lock_irq(&mp->lock);
 
 	err = request_irq(dev->irq, mv643xx_eth_int_handler,
-			SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev);
+			SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
 
 	if (err) {
 		printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n",

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Tue, Mar 08, 2005 at 01:15:01PM +0100, Sven Luther wrote:
> On Tue, Mar 08, 2005 at 05:20:48AM -0700, Dale Farnsworth wrote:
> > On Tue, Mar 08, 2005 at 06:27:12PM +1100, Benjamin Herrenschmidt wrote:
> > > > Notice that benh is telling me that you should use SA_SHIRQ always and that
> > > > SA_INTERRUPT should go away, and that you should contact him online if you
> > > > have trouble with that.
> > > > 
> > > > > For the pegasos 2, you'll need the second patch which applies after
> > > > > the one I previously sent for chrp_setup.c.
> > > > 
> > > > Ok, will test this anyway, and tell you how it works.
> > > 
> > > GHeh, ok, just picked up the discussion. Yes, there is really no reason
> > > to use SA_INTERRUPT here, this is a thing of the past.
> > 
> > Excellent.  Thanks.
> > 
> > Here's a new patch to try.  :-)
> 
> Hehe, i did that myself :)
> 
> Anyway, i have another problem though, namely that even though i do
> arch_initcall(mv643xx_eth_add_pds), mv643xx_eth_add_pds is never called, and
> in the mv643xx_eth driver itself, altough the module init is done, _probe
> never gets called. I will now do a build without any #ifdefs around the
> chrp_setup.c stuff (And Christophe Hellwig proposed moving the stuff into
> arch/ppc/platform/pegasos_mv643xx_eth.c), and see if that will solve it.
> 
> Also going to add the explicit detection of the marvell bridge in the OF tree,
> but need to decide what to check for there.

Ah, yes, indifinitely a problem with the #ifdefs, will submit a cleaned up
patch in a bit.

Friendly,

Sven Luther

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Tue, Mar 08, 2005 at 11:19:18AM -0700, Mark A. Greer wrote:
> Sven Luther wrote:
> 
> >Also going to add the explicit detection of the marvell bridge in the OF 
> >tree,
> >
> 
> Do you really need to do that, though?  Just finding "Pegasos" or 
> "Pegasos2" in the 'model' field of the device tree should be sufficient, 
> shouldn't it? (if I'm reading the code correctly)

Well, benh suggested it, so ... Basically i look for a host named node which
is a marvel discovery 2 pci id.

> >but need to decide what to check for there.
> 
> The only way that I know of to tell if you're on a mv64x60 bridge is to 
> do a pci cfg read of the vendor/device id fields of fcn 0 of the 

Yep, this is what i chose. Well in the of device tree not the pci-config
thingy.

> bridge's device on that pci hose.  By default, the bus number of both 
> hoses are 0 (but OF probably sets the second one to be > 0 depending on 
> how many pci buses there are hanging off hose 0), the bridge will be 
> device 0 on both hoses, the vendor id will be PCI_VENDOR_ID_MARVELL 
> (0x11ab) and the device id will be PCI_DEVICE_ID_MARVELL_MV64360 
> (0x6460) for a mv64360.

Nice, didn't think about using the #defines, will modify this.

> Unfortunately, the bus number of each hose, the device # of the bridge's 
> device on that hose (see "PCI P2P Configuration" register offsets 0x1d14 
> & 0x1d94), and the vendor & device ids (by a pci cfg write to those 
> fields) can all be changed by the fw .  I guess the device tree tells 
> you the bus number of each hose so you can generate the proper cfg 
> access and I doubt OF changes the bridge's device # and pci vendor/dev 
> id but I wanted to make you aware of the potential.

The only problem would be if there is more than one 'host' node in the OF
device-tree, but i guess chances are good that even if there are more than
one, the first one would be the marvell one. Well, there are at least two,
one per bus, but i mean beyond that.

The driver seems to work, i was able to launch a dhclient on top of it, but
didn't do more testing. I will do some additional cleanup, and then i think
the patch will be ready.

Thanks for your help, you and Dale and Ben and the others who gave hints on
how to make this happen.

Friendly,

Sven Luther

Re: mv643xx_eth SA_SHIRQ support patch

[Mark A. Greer]

Sven Luther wrote:

>Also going to add the explicit detection of the marvell bridge in the OF tree,
>

Do you really need to do that, though?  Just finding "Pegasos" or 
"Pegasos2" in the 'model' field of the device tree should be sufficient, 
shouldn't it? (if I'm reading the code correctly)

>but need to decide what to check for there.
>

The only way that I know of to tell if you're on a mv64x60 bridge is to 
do a pci cfg read of the vendor/device id fields of fcn 0 of the 
bridge's device on that pci hose.  By default, the bus number of both 
hoses are 0 (but OF probably sets the second one to be > 0 depending on 
how many pci buses there are hanging off hose 0), the bridge will be 
device 0 on both hoses, the vendor id will be PCI_VENDOR_ID_MARVELL 
(0x11ab) and the device id will be PCI_DEVICE_ID_MARVELL_MV64360 
(0x6460) for a mv64360.

Unfortunately, the bus number of each hose, the device # of the bridge's 
device on that hose (see "PCI P2P Configuration" register offsets 0x1d14 
& 0x1d94), and the vendor & device ids (by a pci cfg write to those 
fields) can all be changed by the fw .  I guess the device tree tells 
you the bus number of each hose so you can generate the proper cfg 
access and I doubt OF changes the bridge's device # and pci vendor/dev 
id but I wanted to make you aware of the potential.

Mark

[PATCH] final mv643xx_eth pegasos patch set ...

[Sven Luther]

Hello,

Ok, thanks for your help, here is the final (hopefully) and cleaned up version
of my patches :

  1) mv643xx-eth-pegasos.diff
  This is the arch/ppc/platform diff, benh, could you look it over, and merge
  it in ? It is not really usefull without the mv643xx_eth.c changes, but dale
  is going to move those in together with his patches.

  2) linux-2.5-mv643xx-enet-pegasos.diff
  This is just two small hunks against dale's linux-2.5-mv643xx-enet tree,
  which include the SA_INTERRUPT -> SA_IRQ and the Kconfig change. Dale said
  he would merge them with his stuff, hopefully for 2.6.12.

  3) mv643xx-eth.diff
  This is the linux-2.5-mv643xx-enet diff against 2.6.11, together with the
  linux-2.5-mv643xx-enet-pegasos.diff changes, for those who want to build
  against 2.6.11.

So to build against the linux-2.5-mv643xx-enet tree, you need 1) and 2) and to
build against 2.6.11 you need 1) and 3).

I am currently running the patches included in these changes, and will include
them in the debian 2.6.11 kernels unless i hear otherwise. 

Friendly,

Sven Luther

Re: [PATCH] final mv643xx_eth pegasos patch set ...

[Sven Luther]

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

On Tue, Mar 08, 2005 at 08:28:05PM +0100, luther wrote:
> Hello,
> 
> Ok, thanks for your help, here is the final (hopefully) and cleaned up version
> of my patches :
> 
>   1) mv643xx-eth-pegasos.diff
>   This is the arch/ppc/platform diff, benh, could you look it over, and merge
>   it in ? It is not really usefull without the mv643xx_eth.c changes, but dale
>   is going to move those in together with his patches.
> 
>   2) linux-2.5-mv643xx-enet-pegasos.diff
>   This is just two small hunks against dale's linux-2.5-mv643xx-enet tree,
>   which include the SA_INTERRUPT -> SA_IRQ and the Kconfig change. Dale said
>   he would merge them with his stuff, hopefully for 2.6.12.
> 
>   3) mv643xx-eth.diff
>   This is the linux-2.5-mv643xx-enet diff against 2.6.11, together with the
>   linux-2.5-mv643xx-enet-pegasos.diff changes, for those who want to build
>   against 2.6.11.
> 
> So to build against the linux-2.5-mv643xx-enet tree, you need 1) and 2) and to
> build against 2.6.11 you need 1) and 3).
> 
> I am currently running the patches included in these changes, and will include
> them in the debian 2.6.11 kernels unless i hear otherwise. 

Oh well, with the patches this time :/

Friendly,

Sven Luther

[-- Attachment #2: mv643xx-eth-pegasos.diff --]
[-- Type: text/plain, Size: 3683 bytes --]

--- linux-dale/arch/ppc/platforms/Makefile	2005-03-08 09:52:44.000000000 +0100
+++ kernel-source-2.6.11-marvell/arch/ppc/platforms/Makefile	2005-03-08 17:33:29.000000000 +0100
@@ -12,7 +12,7 @@
 obj-$(CONFIG_PPC_PMAC)		+= pmac_pic.o pmac_setup.o pmac_time.o \
 					pmac_feature.o pmac_pci.o pmac_sleep.o \
 					pmac_low_i2c.o pmac_cache.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o
+obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o mv643xx_eth_pegasos.o
 obj-$(CONFIG_PPC_PREP)		+= prep_pci.o prep_setup.o
 ifeq ($(CONFIG_PPC_PMAC),y)
 obj-$(CONFIG_NVRAM)		+= pmac_nvram.o
--- linux-dale/arch/ppc/platforms/mv643xx_eth_pegasos.c	1970-01-01 01:00:00.000000000 +0100
+++ kernel-source-2.6.11-marvell/arch/ppc/platforms/mv643xx_eth_pegasos.c	2005-03-08 20:21:33.000000000 +0100
@@ -0,0 +1,112 @@
+/*
+ *  arch/ppc/platforms/mv643xx_eth_pegasos.c
+ *
+ *  Copyright (C) 2005 Sven Luther <sl@bplan-gmbh.de> 
+ *  Thanks to :
+ *	Dale Farnsworth <dale@farnsworth.org>
+ *	Mark A. Greer <mgreer@mvista.com>
+ *	Nicolas DET <nd@bplan-gmbh.de>
+ *	Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ *  And anyone else who helped me on this.
+ */
+
+#include <linux/types.h>
+#include <asm/prom.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+#include <linux/mv643xx.h>
+#include <linux/pci_ids.h>
+
+/* Pegasos 2 specific Marvell MV 64361 gigabit ethernet port setup */
+static struct resource mv643xx_eth_shared_resources[] = {
+	[0] = {
+		.name	= "ethernet shared base",
+		.start	= 0xf1000000 + MV643XX_ETH_SHARED_REGS,
+		.end	= 0xf1000000 + MV643XX_ETH_SHARED_REGS +
+					MV643XX_ETH_SHARED_REGS_SIZE - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mv643xx_eth_shared_device = {
+	.name		= MV643XX_ETH_SHARED_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth_shared_resources),
+	.resource	= mv643xx_eth_shared_resources,
+};
+
+#ifdef CONFIG_MV643XX_ETH_0
+static struct resource mv643xx_eth0_resources[] = {
+	[0] = {
+		.name	= "eth0 irq",
+		.start	= 9,
+		.end	= 9,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv643xx_eth_platform_data eth0_pd;
+
+static struct platform_device eth0_device = {
+	.name		= MV643XX_ETH_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth0_resources),
+	.resource	= mv643xx_eth0_resources,
+	.dev = {
+		.platform_data = &eth0_pd,
+	},
+};
+#endif
+
+#ifdef CONFIG_MV643XX_ETH_1
+static struct resource mv643xx_eth1_resources[] = {
+	[0] = {
+		.name	= "eth1 irq",
+		.start	= 9,
+		.end	= 9,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv643xx_eth_platform_data eth1_pd;
+
+static struct platform_device eth1_device = {
+	.name		= MV643XX_ETH_NAME,
+	.id		= 1,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth1_resources),
+	.resource	= mv643xx_eth1_resources,
+	.dev = {
+		.platform_data = &eth1_pd,
+	},
+};
+#endif
+
+static struct platform_device *mv643xx_eth_pd_devs[] __initdata = {
+	&mv643xx_eth_shared_device,
+#ifdef CONFIG_MV643XX_ETH_0
+	&eth0_device,
+#endif
+#ifdef CONFIG_MV643XX_ETH_1
+	&eth1_device,
+#endif
+};
+
+static int __init
+mv643xx_eth_add_pds(void)
+{
+	int ret = 0;
+	struct device_node *np;
+	np = find_devices("host");
+	if (np != NULL) {
+		unsigned short *vendorid = (unsigned short *) get_property (np, "vendor-id", NULL);
+		unsigned short *deviceid = (unsigned short *) get_property (np, "device-id", NULL);
+		
+		if (vendorid && *vendorid == PCI_VENDOR_ID_MARVELL &&
+		    deviceid && *deviceid == PCI_DEVICE_ID_MARVELL_MV64360)
+			ret = platform_add_devices(mv643xx_eth_pd_devs,
+				ARRAY_SIZE(mv643xx_eth_pd_devs));
+	}
+	return ret;
+}
+arch_initcall(mv643xx_eth_add_pds);

[-- Attachment #3: mv643xx-eth-pegasos.diff --]
[-- Type: text/plain, Size: 3683 bytes --]

--- linux-dale/arch/ppc/platforms/Makefile	2005-03-08 09:52:44.000000000 +0100
+++ kernel-source-2.6.11-marvell/arch/ppc/platforms/Makefile	2005-03-08 17:33:29.000000000 +0100
@@ -12,7 +12,7 @@
 obj-$(CONFIG_PPC_PMAC)		+= pmac_pic.o pmac_setup.o pmac_time.o \
 					pmac_feature.o pmac_pci.o pmac_sleep.o \
 					pmac_low_i2c.o pmac_cache.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o
+obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o mv643xx_eth_pegasos.o
 obj-$(CONFIG_PPC_PREP)		+= prep_pci.o prep_setup.o
 ifeq ($(CONFIG_PPC_PMAC),y)
 obj-$(CONFIG_NVRAM)		+= pmac_nvram.o
--- linux-dale/arch/ppc/platforms/mv643xx_eth_pegasos.c	1970-01-01 01:00:00.000000000 +0100
+++ kernel-source-2.6.11-marvell/arch/ppc/platforms/mv643xx_eth_pegasos.c	2005-03-08 20:21:33.000000000 +0100
@@ -0,0 +1,112 @@
+/*
+ *  arch/ppc/platforms/mv643xx_eth_pegasos.c
+ *
+ *  Copyright (C) 2005 Sven Luther <sl@bplan-gmbh.de> 
+ *  Thanks to :
+ *	Dale Farnsworth <dale@farnsworth.org>
+ *	Mark A. Greer <mgreer@mvista.com>
+ *	Nicolas DET <nd@bplan-gmbh.de>
+ *	Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ *  And anyone else who helped me on this.
+ */
+
+#include <linux/types.h>
+#include <asm/prom.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+#include <linux/mv643xx.h>
+#include <linux/pci_ids.h>
+
+/* Pegasos 2 specific Marvell MV 64361 gigabit ethernet port setup */
+static struct resource mv643xx_eth_shared_resources[] = {
+	[0] = {
+		.name	= "ethernet shared base",
+		.start	= 0xf1000000 + MV643XX_ETH_SHARED_REGS,
+		.end	= 0xf1000000 + MV643XX_ETH_SHARED_REGS +
+					MV643XX_ETH_SHARED_REGS_SIZE - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mv643xx_eth_shared_device = {
+	.name		= MV643XX_ETH_SHARED_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth_shared_resources),
+	.resource	= mv643xx_eth_shared_resources,
+};
+
+#ifdef CONFIG_MV643XX_ETH_0
+static struct resource mv643xx_eth0_resources[] = {
+	[0] = {
+		.name	= "eth0 irq",
+		.start	= 9,
+		.end	= 9,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv643xx_eth_platform_data eth0_pd;
+
+static struct platform_device eth0_device = {
+	.name		= MV643XX_ETH_NAME,
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth0_resources),
+	.resource	= mv643xx_eth0_resources,
+	.dev = {
+		.platform_data = &eth0_pd,
+	},
+};
+#endif
+
+#ifdef CONFIG_MV643XX_ETH_1
+static struct resource mv643xx_eth1_resources[] = {
+	[0] = {
+		.name	= "eth1 irq",
+		.start	= 9,
+		.end	= 9,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct mv643xx_eth_platform_data eth1_pd;
+
+static struct platform_device eth1_device = {
+	.name		= MV643XX_ETH_NAME,
+	.id		= 1,
+	.num_resources	= ARRAY_SIZE(mv643xx_eth1_resources),
+	.resource	= mv643xx_eth1_resources,
+	.dev = {
+		.platform_data = &eth1_pd,
+	},
+};
+#endif
+
+static struct platform_device *mv643xx_eth_pd_devs[] __initdata = {
+	&mv643xx_eth_shared_device,
+#ifdef CONFIG_MV643XX_ETH_0
+	&eth0_device,
+#endif
+#ifdef CONFIG_MV643XX_ETH_1
+	&eth1_device,
+#endif
+};
+
+static int __init
+mv643xx_eth_add_pds(void)
+{
+	int ret = 0;
+	struct device_node *np;
+	np = find_devices("host");
+	if (np != NULL) {
+		unsigned short *vendorid = (unsigned short *) get_property (np, "vendor-id", NULL);
+		unsigned short *deviceid = (unsigned short *) get_property (np, "device-id", NULL);
+		
+		if (vendorid && *vendorid == PCI_VENDOR_ID_MARVELL &&
+		    deviceid && *deviceid == PCI_DEVICE_ID_MARVELL_MV64360)
+			ret = platform_add_devices(mv643xx_eth_pd_devs,
+				ARRAY_SIZE(mv643xx_eth_pd_devs));
+	}
+	return ret;
+}
+arch_initcall(mv643xx_eth_add_pds);

[-- Attachment #4: mv643xx-eth.diff.gz --]
[-- Type: application/octet-stream, Size: 39442 bytes --]

Re: mv643xx_eth SA_SHIRQ support patch

[Benjamin Herrenschmidt]

> Ok, i should have something working. adding here both sven2-dale.diff which is
> a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against
> 2.6.11.
> 
> There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c 
> especially with regard the headers, and also the proper copyright/attibution
> of it (since dale wrote it and i just pasted it and did the detection stuff
> benh mentioned above.
> 
> I am unsure also about the : 
> 
> @@ -44,6 +44,9 @@
>  #include <asm/pgtable.h>
>  #include <asm/system.h>
>  #include <asm/delay.h>
> +#ifdef PPC_MULTIPLATEFORM
> +#include <mv64x60.h>
> +#endif
>  #include "mv643xx_eth.h"
> 
>  /*
> 
> hunk. dale can you check it ? 

Looks broken...

> Comments are welcome, in particular benh, i guess my detection code will beak
> horribly if there is another host node prior to the marvell one in the OF
> tree, which is not the case currently on pegasos though.

Why are you looking at vid/did ? Isn't there some name string (model,
compatible, whatever) you can use ? Or is your OF too bad to even give
such info ?

You can also iterate after the find_devices() using np->next

Ben.

Re: final mv643xx_eth pegasos patch set ...

[Nicolas DET]

Hello Sven,

On 08/03/2005, you wrote:
> On Tue, Mar 08, 2005 at 08:28:05PM +0100, luther wrote:
>> Hello,
>> 
>> Ok, thanks for your help, here is the final (hopefully) and cleaned up
>> version of my patches :
>> 
>>   1) mv643xx-eth-pegasos.diff
>>   This is the arch/ppc/platform diff, benh, could you look it over, and
>> merge   it in ? It is not really usefull without the mv643xx_eth.c
>> changes, but dale   is going to move those in together with his patches.
>> 
>>   2) linux-2.5-mv643xx-enet-pegasos.diff
>>   This is just two small hunks against dale's linux-2.5-mv643xx-enet
>> tree,   which include the SA_INTERRUPT -> SA_IRQ and the Kconfig change.
>> Dale said   he would merge them with his stuff, hopefully for 2.6.12.
>> 
>>   3) mv643xx-eth.diff
>>   This is the linux-2.5-mv643xx-enet diff against 2.6.11, together with
>> the   linux-2.5-mv643xx-enet-pegasos.diff changes, for those who want to
>> build   against 2.6.11.
>> 
>> So to build against the linux-2.5-mv643xx-enet tree, you need 1) and 2)
>> and to build against 2.6.11 you need 1) and 3).
>> 

This patch is requiered to get the ethernet driver working.
http://powernico.free.fr/patch_2.6.11_mv64360_peg2

It only check deepers if we have a Marvell chipset.
this patch has been made against 2.6.11 from kernel.org and only touch:
arch/ppc/platform/Makefile
arch/ppc/mv643xx_eth_pegasos.c

Regards
-- 
Nicolas DET
MorphOS & Linux developer

Re: mv64x60 updates

[Benjamin Herrenschmidt]

On Mon, 2005-03-07 at 12:30 +0000, James Chapman wrote:
> Hi Nicolas,
> 
> A few general comments:-
> 
> - mv64x60 stuff is best posted to linuxppc-embedded
> 
> - you change several generic files to support your platform. It should
>    be possible to support new mv64x60 platforms by writing a new
>    xxx_setup.c file in arch/ppc/platforms with no other generic changes.
>    It is a goal that all mv64x60 boards can be supported by the generic
>    code in arch/ppc/syslib. If some changes need to be made outside
>    arch/ppc/platforms to support your board, try to make them generic so
>    that other similar boards would be able to use them. I suggest you
>    clone chrp_setup.c or katana.c rather than adding conditionals in
>    chrp_setup.c for your board. Then use code in your board specific
>    setup file to call arch/ppc/syslib mv64x60 routines as appropriate.

Welcome to the world of embedded people who use #ifdef's for their
platforms :)

Pegasos claims to be chrp compliant, and so uses chrp_setup.c and relies
on other chrp related bits. The point here is to limit the platform
specific code and use the device-tree as much as is possible. Though I
agree that Nicals patch introduce wrong dependencies (I need to do a
deeper review of it).

If chrp_setup.c indeed ends up beeing cluttered by too much Pegasos
specific stuff, then it will be time to do split pegasos to a different
platform type as part of CONFIG_PPC_MULTIPLATFORM.

Now as far as his patch is concernd, the whole is_pegasos2() stuff is
too ugly for words, I agree. If he really needs so, then he should add
an argument to mv64x60_init() in order to customize it's behaviour.
Though I haven't looked at the code to see why he's trying to skip
stuffs here.

> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
>    Setup device platform data for your board in your platform file.
>    If something needs to be added to the platform data for a generic
>    change to mv643xx_eth, do that rather than add platform conditionals
>    in the driver.

Agreed, though I think that's almost there now.

> - why do you need to use SA_SHIRQ in the ethernet driver?

Why don't use use it ? SA_INTERRUPT is crap and should probably be
removed from the driver.

> /james
> 
> Nicolas DET wrote:
> 
> > Hello Sven,
> > 
> > On 07/03/2005, you wrote:
> > 
> > 
> >>But i hear Nicolas has done some useful work yesterday evening, i will
> >>review it as soon as he is back from dreamland :)
> > 
> > 
> > You can find the patch against 2.6.11 from kernel.org here:
> > http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2
> > 
> > This patch shouldn't break mv code for others platform (non PegasosII), and
> > fix Pegasos II init...
> > 
> > Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:
> > 
> > in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
> > in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
> > ressources tables for Pegasos II hardware (register base & IRQ).
> > in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
> > in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
> > mv64x60_init() if CONFIG_MV64x60
> > in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
> > request_irq if pegasos II detected
> > 
> > The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
> > because I use this function to use the correct flags in the ethernet
> > driver.
> > 
> > Of course, this patch may be discuss as there are several architecture
> > using Marvell chipsets and each requieres some specific code.
> > I don't know where it's the best to place mv64360_ispeasos2(), maybe this
> > func could even be renamed mv64x60_ispegasos2()..
> > 
> > Please, people from others MV64x60 architectures review this patch, modify
> > if it neeeded and check it doesn't break your architecture (I shouldn't but
> > for MIPS ethernet).
> > 
> > Regards
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: mv64x60 updates

[Benjamin Herrenschmidt]

> 
> About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
> hardcoded IRQ, hardcoded register base, it changes 
> chipset configuration... whereas all of these is already done by the
> Pegasos II OpenFirmWare.

Embedded people don't understand what a firmware is ;)

(sorry, couldn't resist ...)

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Wed, Mar 09, 2005 at 09:31:26AM +1100, Benjamin Herrenschmidt wrote:
> 
> > Ok, i should have something working. adding here both sven2-dale.diff which is
> > a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against
> > 2.6.11.
> > 
> > There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c 
> > especially with regard the headers, and also the proper copyright/attibution
> > of it (since dale wrote it and i just pasted it and did the detection stuff
> > benh mentioned above.
> > 
> > I am unsure also about the : 
> > 
> > @@ -44,6 +44,9 @@
> >  #include <asm/pgtable.h>
> >  #include <asm/system.h>
> >  #include <asm/delay.h>
> > +#ifdef PPC_MULTIPLATEFORM
> > +#include <mv64x60.h>
> > +#endif
> >  #include "mv643xx_eth.h"
> > 
> >  /*
> > 
> > hunk. dale can you check it ? 
> 
> Looks broken...

Yep, removed it.

> > Comments are welcome, in particular benh, i guess my detection code will beak
> > horribly if there is another host node prior to the marvell one in the OF
> > tree, which is not the case currently on pegasos though.
> 
> Why are you looking at vid/did ? Isn't there some name string (model,
> compatible, whatever) you can use ? Or is your OF too bad to even give
> such info ?
> 
> You can also iterate after the find_devices() using np->next

Well, I have this : 

vendor-id             0x11AB (4523)
device-id             0x6460 (25696)
revision-id           0x3 (3)
class-code            0x60000 (393216)
subsystem-id          0x0 (0)
subsystem-vendor-id   0x0 (0)
.vendor-name          "Marvell"
.part-number          "MV6436x"
.description          "System Controller for PowerPC Processors"
.class                "Bridge Device"
.subclass             "Host/PCI"
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "host"
reg                   0:0
assigned-addresses

In the /pci/host node, i also have :

model                 "Pegasos2"

In the root node, and in the new OF, we even have a /discovery2/port@1 or
something such, but it is unreleased yet.

The thing is not that there is no info, just to chose which info is best.

Christoph suggested to not do that though, but use the normal pci stuff and
match on the host pci id with pci_dev_present. This is what i was thinking of
doing too, and may be more logical, no ? 

Friendly,

Sven Luther

Re: mv643xx_eth SA_SHIRQ support patch

[Benjamin Herrenschmidt]

On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:

> vendor-id             0x11AB (4523)
> device-id             0x6460 (25696)
> revision-id           0x3 (3)
> class-code            0x60000 (393216)
> subsystem-id          0x0 (0)
> subsystem-vendor-id   0x0 (0)
> .vendor-name          "Marvell"
> .part-number          "MV6436x"
> .description          "System Controller for PowerPC Processors"
> .class                "Bridge Device"
> .subclass             "Host/PCI"
> devsel-speed          0x0 (0)
> min-grant             0x0 (0)
> max-latency           0x0 (0)
> name                  "host"
> reg                   0:0
> assigned-addresses

Ok, teach them the interest in having a "model" and "compatible"
property in them for their next version...

> In the /pci/host node, i also have :
> 
> model                 "Pegasos2"
> 
> In the root node, and in the new OF, we even have a /discovery2/port@1 or
> something such, but it is unreleased yet.

Ugh ? What is that supposed to be ?

If it's an ethernet port, it should be called "ethernet".

> The thing is not that there is no info, just to chose which info is best.
> 
> Christoph suggested to not do that though, but use the normal pci stuff and
> match on the host pci id with pci_dev_present. This is what i was thinking of
> doing too, and may be more logical, no ? 

Yah, if there is no meaningful OF name, then probably.

Ben.

Re: mv643xx_eth SA_SHIRQ support patch

[Sven Luther]

On Wed, Mar 09, 2005 at 06:39:27PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:
> 
> > vendor-id             0x11AB (4523)
> > device-id             0x6460 (25696)
> > revision-id           0x3 (3)
> > class-code            0x60000 (393216)
> > subsystem-id          0x0 (0)
> > subsystem-vendor-id   0x0 (0)
> > .vendor-name          "Marvell"
> > .part-number          "MV6436x"
> > .description          "System Controller for PowerPC Processors"
> > .class                "Bridge Device"
> > .subclass             "Host/PCI"
> > devsel-speed          0x0 (0)
> > min-grant             0x0 (0)
> > max-latency           0x0 (0)
> > name                  "host"
> > reg                   0:0
> > assigned-addresses
> 
> Ok, teach them the interest in having a "model" and "compatible"
> property in them for their next version...

You mean a model in /pci/host, ok, i can add that.

> > In the /pci/host node, i also have :
> > 
> > model                 "Pegasos2"
> > 
> > In the root node, and in the new OF, we even have a /discovery2/port@1 or
> > something such, but it is unreleased yet.
> 
> Ugh ? What is that supposed to be ?

As opposed to /ethernet/port1 as it is currently.

> If it's an ethernet port, it should be called "ethernet".

In fact, we already did it, it is /discovery2/ethernet@1, which should make
yaboot happy, i think. Not released though.

> > The thing is not that there is no info, just to chose which info is best.
> > 
> > Christoph suggested to not do that though, but use the normal pci stuff and
> > match on the host pci id with pci_dev_present. This is what i was thinking of
> > doing too, and may be more logical, no ? 
> 
> Yah, if there is no meaningful OF name, then probably.

Well, if there is both, what is the best way to do this ? 

Friendly,

Sven Luther

Re: mv64x60 updates

[Chris Friesen]

Benjamin Herrenschmidt wrote:

> Welcome to the world of embedded people who use #ifdef's for their
> platforms :)

Yeah.  And all the different vendor patches are mutually incompatible, 
and are hardcoded to wrong values, and mangle common code, and....

Chris