mesh: target 0 aborted

This patch makes mesh.c compile, by adapting it to the new pmac_feature API (ported from the ppc tree).

In addition it contains the fix from Thomas Capricelli for the infamous "mesh: target 0 aborted" error, which I've been personally observing since 2.1.13x.

Regards,
-velco

@@ -28,7 +28,8 @@
 #include <asm/irq.h>
 #include <asm/hydra.h>
 #include <asm/processor.h>
-#include <asm/feature.h>
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
 #ifdef CONFIG_PMAC_PBOOK
 #include <linux/adb.h>
 #include <linux/pmu.h>

@@ -155,7 +156,6 @@
 	struct mesh_target tgts[8];
 	void	*dma_cmd_space;
 	struct device_node *ofnode;
-	u8*	mio_base;
 #ifndef MESH_NEW_STYLE_EH
 	Scsi_Cmnd *completed_q;
 	Scsi_Cmnd *completed_qtail;

@@ -258,8 +258,6 @@
 	if (mesh == 0)
 		mesh = find_compatible_devices("scsi", "chrp,mesh0");
 	for (; mesh != 0; mesh = mesh->next) {
-		struct device_node *mio;
-		
 		if (mesh->n_addrs != 2 || mesh->n_intrs != 2) {
 			printk(KERN_ERR "mesh: expected 2 addrs and 2 intrs"
 			       " (got %d,%d)", mesh->n_addrs, mesh->n_intrs);

@@ -325,12 +323,6 @@
 		if (mesh_sync_period < minper)
 			mesh_sync_period = minper;
 
-		ms->mio_base = 0;
-		for (mio = ms->ofnode->parent; mio; mio = mio->parent)
-			if (strcmp(mio->name, "mac-io") == 0 && mio->n_addrs > 0)
-				break;
-		if (mio)
-			ms->mio_base = (u8 *) ioremap(mio->addrs[0].address, 0x40);
 		set_mesh_power(ms, 1);
 
 		mesh_init(ms);

@@ -363,11 +355,9 @@
 		iounmap((void *) ms->mesh);
 	if (ms->dma)
 		iounmap((void *) ms->dma);
-	if (ms->mio_base)
-		iounmap((void *) ms->mio_base);
 	kfree(ms->dma_cmd_space);
 	free_irq(ms->meshintr, ms);
-	feature_clear(ms->ofnode, FEATURE_MESH_enable);
+	pmac_call_feature(PMAC_FTR_MESH_ENABLE, ms->ofnode, 0, 0);
 	return 0;
 }
 

@@ -377,16 +367,10 @@
 	if (_machine != _MACH_Pmac)
 		return;
 	if (state) {
-		feature_set(ms->ofnode, FEATURE_MESH_enable);
-		/* This seems to enable the termination power. strangely
-		   this doesn't fully agree with OF, but with MacOS */
-		if (ms->mio_base)
-			out_8(ms->mio_base + 0x36, 0x70);
+		pmac_call_feature(PMAC_FTR_MESH_ENABLE, ms->ofnode, 0, 1);
 		mdelay(200);
 	} else {
-		feature_clear(ms->ofnode, FEATURE_MESH_enable);
-		if (ms->mio_base)
-			out_8(ms->mio_base + 0x36, 0x34);
+		pmac_call_feature(PMAC_FTR_MESH_ENABLE, ms->ofnode, 0, 1);
 		mdelay(10);
 	}
 }			

@@ -584,25 +568,17 @@
 
 	udelay(100);
 
-	out_le32(&md->control, (RUN|PAUSE|FLUSH|WAKE) << 16);	/* stop dma */
-	out_8(&mr->exception, 0xff);	/* clear all exception bits */
-	out_8(&mr->error, 0xff);	/* clear all error bits */
+	out_8(&mr->exception, 0xff);	
+	out_8(&mr->error, 0xff);	
 	out_8(&mr->sequence, SEQ_RESETMESH);
 	udelay(10);
+
+	out_8(&mr->interrupt, 0xff);	/* clear all interrupt bits */
 	out_8(&mr->intr_mask, INT_ERROR | INT_EXCEPTION | INT_CMDDONE);
 	out_8(&mr->source_id, ms->host->this_id);
 	out_8(&mr->sel_timeout, 25);	/* 250ms */
-	out_8(&mr->sync_params, ASYNC_PARAMS);
-
-	out_8(&mr->bus_status1, BS1_RST);	/* assert RST */
-	udelay(30);			/* leave it on for >= 25us */
-	out_8(&mr->bus_status1, 0);	/* negate RST */
-
-	out_8(&mr->sequence, SEQ_FLUSHFIFO);
-	udelay(1);
-	out_8(&mr->sync_params, ASYNC_PARAMS);
-	out_8(&mr->sequence, SEQ_ENBRESEL);
-	out_8(&mr->interrupt, 0xff);	/* clear all interrupt bits */
+	out_8(&mr->sync_params, ASYNC_PARAMS);	/* asynchronous initially */
+	out_le32(&md->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
 }
 
 /*

Er, what exactly is this against? If this is just what's in the linuxppc_2_4 tree against current 2.4.18pre, this is either (or will be now :)) on BenH's list of things to resend to Marcelo, or there's a problem with it still. If you added in another patch, please re-send this vs the linuxppc_2_4 tree.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

The up to date mesh driver didn't get into 2.4.18pre1, either I forgot to send it to Marcelo along with the other PPC patches, or he missed it.

I'll take care of this.

The other patch for getting rid of "target 0 aborted" need some more review. You seem to just remove the bus reset. That could be made a driver option in case it really cause trouble, but I suppose the bug is elsewhere (while beeing triggered by the bus reset).

I'll look into this around next week.

Ben.

Benjamin> The up to date mesh driver didn't get into 2.4.18pre1, either I forgot Benjamin> to send it to Marcelo along with the other PPC patches, or he missed it.

Benjamin> I'll take care of this.

Benjamin> The other patch for getting rid of "target 0 aborted" need some more Benjamin> review. You seem to just remove the bus reset. That could be made a Benjamin> driver option in case it really cause trouble, but I suppose the bug Benjamin> is elsewhere (while beeing triggered by the bus reset).

Benjamin> I'll look into this around next week.

Thanks a lot.

Regards,
-velco

I'm the one responsible for this patch. I can't boot my powerpc7600 whithout
it. I've been pushing this patch (on the linux-ppc list) for so long (several years, don't remember), that I've given up last year.

Linuxppc people are even worse than Linus. I did not even get an answer
about a problem with my patch or whatever. Pure 'nothing'. Not even a 'no'.

I'm still ready to test/discuss about the pb with anybody, anyway.

Let's get clear about what I've done : I'm using linuxppc for many years,
and at one point, the kernel refused to boot. I've checked the difference between this kernel and the last one I was using, and merely changed back the mesh.c so that it works. As I was not following kernel dvpmt very closely by then, I can't tell when the change that broke things came in.

I would be very happy to change my patch so that this change is optional.

happy new year,
Thomas

whithout

(several

back the

I'm probably responsible for your patch never beeing merged then, sorry about that. MESH is a weird beast, sometimes, fixing it for one case will break others, it's pretty timing sensitive and full of interesting HW bugs. One problem I have currently is the lack of HW. Fortunately, I've managed to get back an old 8500 class machine (with MESH), this will allow me to play a bit with it.

I'm away for now, but I'll look into this once I'm back, next week.

Ben.

Tom> Er, what exactly is this against? If this is just what's in the Tom> linuxppc_2_4 tree against current 2.4.18pre, this is either (or will be Tom> now :)) on BenH's list of things to resend to Marcelo, or there's a Tom> problem with it still. If you added in another patch, please re-send Tom> this vs the linuxppc_2_4 tree.

This is against 2.4.18pre1. You may resync with it.