On Tue, 1 Sep 1998, Mark Brinicombe wrote:

> > version of the chip-specific part of the driver. It don't see the point as
> > other drivers such as the one for the Powertec also do this, but he's the one
> > who decides.
> Currently a private arm32 specific patched version of the NCR has not been
> added. The powertec in the tree uses the older sfas code. The motivation
> for not committing it was that it is better and cleaner to make things
> work with the existing MI driver, that however requires time which is a
> commodity in very short supply ;-(

I completely agree with you that it should be done properly, ie. that the
MI driver should be used.
But until this happens I would commit what we have now. It's better than
nothing. And the time until it gets done properly always tends to become
longer so people will have to wait longer for it to appear. During that
time, if they really need it, they should have a solution, even if it's
not the proper one.

> How far have you got so far ? Do you have ay code you can throw my way to
> look at ?

Well, at one point I was able to undo the two changes that were made to
the NCR driver - the ones that check the NCR_NODMA (iirc) flag. I did so
by adding a check in csc_write_reg. I still use that kernel.
Unfortunatedly, I can't repeat this any more. :-((( Either I broke my
changes inbetween or something else has changed. I have a version slightly
before the breakthrough that I tarred to give to Jochen Scharrlach which I
haven't tried yet. I think the best idea is to restart from this.

>From that I moved on to the current MI version but it didn't work with
that. I don't know why.

> Ok since this is a problem that needs addressing and I have not been able
> to do it the way I wanted due to time I need to find some stop-gap
> solution at least. I have a verison of the cumana driver that uses the
> older sfas code so I will put this in the tree. (I don't have a cumana
> card to test with myself)
> 
> This should then at least allow installs etc. from the cumana card.
> 
> Markus: If I get something in the tree and send you a kernel, any chance
> you could confirm that it appears to work ?

You already gave it to me some time ago. IIRC it correctly probes the
devices but hangs the kernel at the first real access to the harddisk. I'm
afraid you can't use this. I wouldn't waste any more time on this.

If you absolutely don't want the check in the version that uses the
private NCR driver, I propose the following solution:
I make my kernel available (eg. on my webpage) for people to use as a
quick solution. I'm pretty sure I can sort out my problems to build a
working kernel and make custom ones if people should need it.
This should be good enough until either me or you sort out the problems
with the MI NCR driver so it can get committed to the tree.

So long, Markus