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
--- 1.1/drivers/scsi/mesh.c Sat Dec 8 02:14:29 2001
+++ edited/drivers/scsi/mesh.c Wed Jan 2 00:02:23 2002
@@ -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);
}
/*
On Wed, Jan 02, 2002 at 12:45:34AM +0200, Momchil Velikov wrote:
> 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.
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/
>>>>> "Tom" == Tom Rini <[email protected]> writes:
Tom> On Wed, Jan 02, 2002 at 12:45:34AM +0200, Momchil Velikov wrote:
>> 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.
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.
>> 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.
>
>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.
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" == Benjamin Herrenschmidt <[email protected]> writes:
>>> 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.
>>
>> 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.
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
On Wednesday 02 January 2002 10:17, Benjamin Herrenschmidt wrote:
> 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.
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
> 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'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.