mac scsi, ncr5380

mac scsi, ncr5380

[Finn Thain]

Hi All,

Of late I've spent some time wrestling with mac_scsi. I've made some 
progress, but I'm uncertain as to how I should procede -- whatever I do, 
there will be implications for some other NCR5380 drivers.

mac_scsi actually works (once I fixed the enable_irq-before-request_irq 
bug -- already fixed in various other NCR5380 wrapper drivers ... sigh) 
but it only works in PIO mode. The PDMA read routine causes a bus error 
(The Guide to Mac Family Hardware says "if a read or write operation over 
the SCSI bus is not completed within certain time (different for different 
machines), the general logic IC asserts a bus error (/BERR) to the CPU.")
The driver tries to fall back to PIO mode when that happens.

The fall back succeeds only on the powerbook 190 and only if the code was 
compiled with gcc-3. It just hangs on the PB 150 and Mac II, though PIO 
works on those machines too when PDMA is disabled. So I think there's a 
race there somewhere. And PIO doesn't work anywhere once debugging printks 
are enabled.

All of which gives me little confidence in NCR5380.c.

(I tested those 3 machines because they have the 3 different kinds of 
VIA2. Logs can be found here
<http://www.telegraphics.com.au/~fthain/mac_scsi_logs/>
should anyone want to see them.)

There is so much duplication of code for the NCR5380 drivers -- sun3, 
atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't 
know where to start looking for fixes.

Thinking that the bug would be trivial, I started out writing cleanup 
patches for the existing mac_scsi.c/NCR5380.c combination. But the more I 
think about it, the less I want to go in that direction.

Now I'm thinking that mac_scsi should adopt the atari core, since that 
appears to be the better maintained contender. Michael, does that sound 
sensible? Does it have working PDMA?

Another thing, should we look at merging sun3_NCR5380.c and 
atari_NCR5380.c? The diff is huge, but that is because of the code style 
and formatting cleanups in atari_NCR5380.c. The functional differencess 
are few and far between.

If we can get to a working, common sun3/atari/mac core, I could then look 
at minimising C preprocessor abuse in favour of a cleaner link-time/ops 
struct abstraction layer -- with some assistance from Micheal and Sam: I'm 
assuming that there is a cut somewhere that would make for a broadly 
useful interface. Does this make sense?

Merging core 5380 drivers could _maybe_ go further if those responsible 
for them were interested, but I would not want to bite off more than 
atari/mac/sun3 at first. As to the rest, here's a list of all the relevant 
#includes (this really needs to be converted to a graphical representation 
somehow..) I don't know who maintains all of these 5380 drivers.

files that include NCR5380.c --
./drivers/scsi/arm/cumana_1.c
./drivers/scsi/arm/oak.c
./drivers/scsi/dmx3191d.c
./drivers/scsi/dtc.c
./drivers/scsi/g_NCR5380.c
./drivers/scsi/mac_scsi.c
./drivers/scsi/pas16.c
./drivers/scsi/t128.c

files that include NCR5380.h --
./drivers/scsi/arm/cumana_1.c
./drivers/scsi/arm/oak.c
./drivers/scsi/atari_scsi.c
./drivers/scsi/dmx3191d.c
./drivers/scsi/dtc.c
./drivers/scsi/g_NCR5380.c
./drivers/scsi/mac_scsi.c
./drivers/scsi/pas16.c
./drivers/scsi/sun3_scsi.c 
./drivers/scsi/sun3_scsi_vme.c
./drivers/scsi/t128.c

files that include atari_NCR5380.c --
./drivers/scsi/atari_scsi.c

files that include atari_scsi.h --
./drivers/scsi/atari_scsi.c

files that include dtc.h --
./drivers/scsi/dtc.c

files that include g_NCR5380.c --
./drivers/scsi/g_NCR5380_mmio.c

files that include g_NCR5380.h --
./drivers/scsi/g_NCR5380.c

files that include mac_scsi.h --
./drivers/scsi/mac_scsi.c

files that include pas16.h --
./drivers/scsi/pas16.c

files that include sun3_NCR5380.c --
./drivers/scsi/sun3_scsi.c
./drivers/scsi/sun3_scsi_vme.c

files that include sun3_scsi.h --
./drivers/scsi/sun3_scsi.c
./drivers/scsi/sun3_scsi_vme.c

files that include t128.h --
./drivers/scsi/t128.c

Note that this include graph is post-patching: I moved the #include 
"NCR5380.h" out of sun3_scsi.h and into sun3_scsi.c and sun3_scsi_vme.c so 
that the graph was more shallow and more symmetrical (that patch is at 
<http://www.telegraphics.com.au/~fthain/patches_wip/>
I'll send some of these patches for the 2.6.28 merge window.)

Regards,

Finn

Re: [linux-m68k] mac scsi, ncr5380

[Sam Creasey]

On Fri, Sep 26, 2008 at 06:27:05PM +1000, Finn Thain wrote:

> There is so much duplication of code for the NCR5380 drivers -- sun3, 
> atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't 
> know where to start looking for fixes.
> 
> Thinking that the bug would be trivial, I started out writing cleanup 
> patches for the existing mac_scsi.c/NCR5380.c combination. But the more I 
> think about it, the less I want to go in that direction.
> 
> Now I'm thinking that mac_scsi should adopt the atari core, since that 
> appears to be the better maintained contender. Michael, does that sound 
> sensible? Does it have working PDMA?
> 
> Another thing, should we look at merging sun3_NCR5380.c and 
> atari_NCR5380.c? The diff is huge, but that is because of the code style 
> and formatting cleanups in atari_NCR5380.c. The functional differencess 
> are few and far between.
> 
> If we can get to a working, common sun3/atari/mac core, I could then look 
> at minimising C preprocessor abuse in favour of a cleaner link-time/ops 
> struct abstraction layer -- with some assistance from Micheal and Sam: I'm 
> assuming that there is a cut somewhere that would make for a broadly 
> useful interface. Does this make sense?

It makes sense, I think.  I'm trying to remember what hackery I had
to do which led me to fork the driver in the first place -- I'm fairly
sure that the main differences were related to the dma controller on
the OBIO sun3's (50/60) being very picky about what bus phases you
programmed the DMA controller during, and this not working well with
the model in place in the version of atari_NCR5380 which I started
with (it's only been 9 years, you'd think I'd know this... :)

I can't actually recall what the requirments are at the moment.  most
of the sun3* function calls seem to be centered around making sure DMA
is configured in the CMDOUT phase and started in the DATAIN/DATAOUT
phases (is this why I commented out merge_contiguous_buffers() in
NCR5380_transfer_dma?)

Let me know if you start making progress, I'll be happy to let ya know
anything else I can rememeber, or to try to bring a kernel up on real
hardware (I think a couple of them still boot...  :)

-- Sam

Re: mac scsi, ncr5380

[Michael Schmitz]

Hi Finn,

> Of late I've spent some time wrestling with mac_scsi. I've made some
> progress, but I'm uncertain as to how I should procede -- whatever I do,
> there will be implications for some other NCR5380 drivers.
>
> mac_scsi actually works (once I fixed the enable_irq-before-request_irq
> bug -- already fixed in various other NCR5380 wrapper drivers ... sigh)
> but it only works in PIO mode. The PDMA read routine causes a bus error
> (The Guide to Mac Family Hardware says "if a read or write operation over
> the SCSI bus is not completed within certain time (different for different
> machines), the general logic IC asserts a bus error (/BERR) to the CPU.")
> The driver tries to fall back to PIO mode when that happens.

The bus error is caught OK by the PDMA function?

> The fall back succeeds only on the powerbook 190 and only if the code was
> compiled with gcc-3. It just hangs on the PB 150 and Mac II, though PIO
> works on those machines too when PDMA is disabled. So I think there's a
> race there somewhere. And PIO doesn't work anywhere once debugging printks
> are enabled.

I've worked around that in the past by hooking into the Mac level 7 interrupt, 
listing the driver state from the NMI post-mortem. (Actually I did that on the 
old Mac ESP driver, but the same sort of hack should apply. ESP was a lot more 
debug friendly though ...)

> All of which gives me little confidence in NCR5380.c.
>
> (I tested those 3 machines because they have the 3 different kinds of
> VIA2. Logs can be found here
> <http://www.telegraphics.com.au/~fthain/mac_scsi_logs/>
> should anyone want to see them.)

Looks like a race with the ADB interrupt to me. In the second Mac II gcc4 case, 
it even seems to fail to add the target to the disconnect queue.

What are these unknown interrupts? DRQ? PDMA stalling?

> There is so much duplication of code for the NCR5380 drivers -- sun3,
> atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't
> know where to start looking for fixes.

The Mac driver originated from the Atari one, but I haven't done more than the 
absolute minimum in fixes to keep that one alive.

> Thinking that the bug would be trivial, I started out writing cleanup
> patches for the existing mac_scsi.c/NCR5380.c combination. But the more I
> think about it, the less I want to go in that direction.
>
> Now I'm thinking that mac_scsi should adopt the atari core, since that
> appears to be the better maintained contender. Michael, does that sound
> sensible? Does it have working PDMA?

Atari uses real DMA. When I adapted it for Mac, I added PIO and that did work 
fine (slowish, but OK). Must have been in the 2.2 kernel series, more than 10 
years ago, so it may not work in the driver's current state. I can test that if 
you need to.

Better maintained ... I strongly doubt it. It still works in the regular case, 
but I haven't pushed it hard enough to test whether my 2.6 error handling 
changes still work today.

> Another thing, should we look at merging sun3_NCR5380.c and
> atari_NCR5380.c? The diff is huge, but that is because of the code style
> and formatting cleanups in atari_NCR5380.c. The functional differencess
> are few and far between.

In order to avoid duplication maintenance effort, we should merge those if it is 
at all possible. I didn't write the Atari code, and my discussions with the 
author were so long ago I have trouble remembering the details. Much of the 
peculiar things in the Atari driver result from the fact that the SCSI chip 
hangs quite frequently on Atari (hardware issue), and the command in-flight may 
not be in any of the queues if that happens (or so a comment in the code claims;
I think I fixed the most glaring case a while ago). Maybe we can let the error
handler clean up after these hangs now; changes since 2.2 in locking and error 
handling have been simplifying things enormously after all.

> If we can get to a working, common sun3/atari/mac core, I could then look
> at minimising C preprocessor abuse in favour of a cleaner link-time/ops
> struct abstraction layer -- with some assistance from Micheal and Sam: I'm
> assuming that there is a cut somewhere that would make for a broadly
> useful interface. Does this make sense?

It does, for me.

> Merging core 5380 drivers could _maybe_ go further if those responsible
> for them were interested, but I would not want to bite off more than
> atari/mac/sun3 at first. As to the rest, here's a list of all the relevant
> #includes (this really needs to be converted to a graphical representation
> somehow..) I don't know who maintains all of these 5380 drivers.

I don't think we have a chance to get most of these tested for regression these 
days. Let's stick to the m68k ones.

My $.02,

 	Michael

Re: mac scsi, ncr5380

[Finn Thain]

On Sat, 27 Sep 2008, Michael Schmitz wrote:

> > mac_scsi actually works (once I fixed the 
> > enable_irq-before-request_irq bug -- already fixed in various other 
> > NCR5380 wrapper drivers ... sigh) but it only works in PIO mode. The 
> > PDMA read routine causes a bus error (The Guide to Mac Family Hardware 
> > says "if a read or write operation over the SCSI bus is not completed 
> > within certain time (different for different machines), the general 
> > logic IC asserts a bus error (/BERR) to the CPU.") The driver tries to 
> > fall back to PIO mode when that happens.
> 
> The bus error is caught OK by the PDMA function?

Yes. Here's a log where the PB 190 booted to login prompt. This kernel had 
PDMA enabled, and you can see that the fallback to PIO worked in this 
instance,

http://marc.info/?l=linux-m68k&m=121930677128486&w=2

Note that the sector size response was screwed up. That happens sometimes. 
It could be related to the other problem I mentioned --

> > The fall back succeeds only on the powerbook 190 and only if the code 
> > was compiled with gcc-3. It just hangs on the PB 150 and Mac II, 
> > though PIO works on those machines too when PDMA is disabled. So I 
> > think there's a race there somewhere. And PIO doesn't work anywhere 
> > once debugging printks are enabled.
> 
> I've worked around that in the past by hooking into the Mac level 7 
> interrupt, listing the driver state from the NMI post-mortem. (Actually 
> I did that on the old Mac ESP driver, but the same sort of hack should 
> apply. ESP was a lot more debug friendly though ...)

OK. But PIO shouldn't be timing sensitive, right? Anyway, I don't want to 
get sidetracked with PIO.. unless there are macs that can't do PDMA.

> > All of which gives me little confidence in NCR5380.c.
> >
> > (I tested those 3 machines because they have the 3 different kinds of 
> > VIA2. Logs can be found here 
> > <http://www.telegraphics.com.au/~fthain/mac_scsi_logs/> should anyone 
> > want to see them.)
> 
> Looks like a race with the ADB interrupt to me.

Well, I know Mac interrupt handling used to be flaky, but that's all fixed 
now. Anyway, I did some tests using the adb_sync parameter, to prevent the 
background ADB probe task, and I get the same results (you can find some 
new logs at the same URL).

> In the second Mac II gcc4 case, it even seems to fail to add the target 
> to the disconnect queue.

I dunno why. I haven't seen that happen before or since.

> What are these unknown interrupts? DRQ? PDMA stalling?

The schematics say that only the NCR5380 drives that VIA input (VIA2 CB2 
aka IRQ_MAC_SCSI), so IRQ 19 is definitely the IRQ line from the chip (and 
not the DRQ line). The DRQ interrupt was/is never registered (BTW, I found 
that it doesn't fire on one of the PowerBooks).

Anyway, it probably isn't PDMA related since that was disabled (#undef 
PSEUDO_DMA).

BASR 0x18 would indicate "IRQ active" and "phase match"... I haven't read 
enough of the datasheet to know what that combination means.

> > There is so much duplication of code for the NCR5380 drivers -- sun3, 
> > atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't 
> > know where to start looking for fixes.
> 
> The Mac driver originated from the Atari one, but I haven't done more 
> than the absolute minimum in fixes to keep that one alive.

There are some mac_scsi.c/NCR5380.c fixes in the mac68k CVS, but it is 
hard to know whether they are relevant to atari_NCR5380.c...

http://linux-mac68k.cvs.sourceforge.net/linux-mac68k/linux-mac68k/drivers/scsi/NCR53C9x.c?view=log&pathrev=MAIN 
http://linux-mac68k.cvs.sourceforge.net/linux-mac68k/linux-mac68k/drivers/scsi/NCR53C9x.c?view=log&pathrev=linux-2_2

> 
> > Thinking that the bug would be trivial, I started out writing cleanup 
> > patches for the existing mac_scsi.c/NCR5380.c combination. But the 
> > more I think about it, the less I want to go in that direction.
> >
> > Now I'm thinking that mac_scsi should adopt the atari core, since that 
> > appears to be the better maintained contender. Michael, does that 
> > sound sensible? Does it have working PDMA?
> 
> Atari uses real DMA. When I adapted it for Mac, I added PIO and that did 
> work fine (slowish, but OK). Must have been in the 2.2 kernel series, 
> more than 10 years ago, so it may not work in the driver's current 
> state. I can test that if you need to.

Thanks. I don't know if PIO will be needed though?

> Better maintained ... I strongly doubt it. It still works in the regular 
> case, but I haven't pushed it hard enough to test whether my 2.6 error 
> handling changes still work today.
> 
> > Another thing, should we look at merging sun3_NCR5380.c and 
> > atari_NCR5380.c? The diff is huge, but that is because of the code 
> > style and formatting cleanups in atari_NCR5380.c. The functional 
> > differencess are few and far between.
> 
> In order to avoid duplication maintenance effort, we should merge those 
> if it is at all possible. I didn't write the Atari code, and my 
> discussions with the author were so long ago I have trouble remembering 
> the details. Much of the peculiar things in the Atari driver result from 
> the fact that the SCSI chip hangs quite frequently on Atari (hardware 
> issue), and the command in-flight may not be in any of the queues if 
> that happens (or so a comment in the code claims; I think I fixed the 
> most glaring case a while ago). Maybe we can let the error handler clean 
> up after these hangs now; changes since 2.2 in locking and error 
> handling have been simplifying things enormously after all.
> 

One implication for a creating a shared driver core is that it rules out 
#ifdef CONFIG_ATARI if we want "make allyesconfig" to work and give 
complete code coverage. We'd have to have run-time conditionals for 
hardware bugs.

I will see what can be done about merging sun3_NCR5380.c with 
atari_NCR5380.c.

Finn

Re: mac scsi, ncr5380

[Brad Boyer]

On Sat, Sep 27, 2008 at 06:00:10PM +1000, Finn Thain wrote:
> On Sat, 27 Sep 2008, Michael Schmitz wrote:
> > > The fall back succeeds only on the powerbook 190 and only if the code 
> > > was compiled with gcc-3. It just hangs on the PB 150 and Mac II, 
> > > though PIO works on those machines too when PDMA is disabled. So I 
> > > think there's a race there somewhere. And PIO doesn't work anywhere 
> > > once debugging printks are enabled.
> > 
> > I've worked around that in the past by hooking into the Mac level 7 
> > interrupt, listing the driver state from the NMI post-mortem. (Actually 
> > I did that on the old Mac ESP driver, but the same sort of hack should 
> > apply. ESP was a lot more debug friendly though ...)
> 
> OK. But PIO shouldn't be timing sensitive, right? Anyway, I don't want to 
> get sidetracked with PIO.. unless there are macs that can't do PDMA.

As usual, there are exceptions. However, it's not as bad as it could
be. The IIfx can do PDMA, but it doesn't do it in exactly the same
way. Like so much else on the IIfx, the SCSI chip isn't quite like
the others. The ideal situation would be to get the real DMA working
(the IIfx is the only Mac using a 5380 chip that has real DMA) which
would mean treating it as a separate machine anyway. If you want the
details, doing PDMA on the IIfx requires poking the DMA engine to
get it out of the way. I have the docs someplace.

> > What are these unknown interrupts? DRQ? PDMA stalling?
> 
> The schematics say that only the NCR5380 drives that VIA input (VIA2 CB2 
> aka IRQ_MAC_SCSI), so IRQ 19 is definitely the IRQ line from the chip (and 
> not the DRQ line). The DRQ interrupt was/is never registered (BTW, I found 
> that it doesn't fire on one of the PowerBooks).

I don't think we really know where the DRQ line is connected, if at all.
That's actually the problem I had with getting the DMA on the IIfx
working. I never got the EOT interrupt from the DMA engine.

> Thanks. I don't know if PIO will be needed though?

My understanding of the NCR5380.c driver is that there are some cases
that use PIO even in the presence of DMA or PDMA support.

	Brad Boyer
	flar@allandria.com

Re: mac scsi, ncr5380

[Finn Thain]

On Sat, 27 Sep 2008, Brad Boyer wrote:

> .. the ideal situation would be to get the real DMA working (the IIfx is 
> the only Mac using a 5380 chip that has real DMA) which would mean 
> treating it as a separate machine anyway. If you want the details, doing 
> PDMA on the IIfx requires poking the DMA engine to get it out of the 
> way. I have the docs someplace.

Docs would be nice... although I can't test anything as I don't have that 
hardware. But aside from yourself, there's a user on the debian-68k list 
who has a IIfx.

> > > What are these unknown interrupts? DRQ? PDMA stalling?
> > 
> > The schematics say that only the NCR5380 drives that VIA input (VIA2 
> > CB2 aka IRQ_MAC_SCSI), so IRQ 19 is definitely the IRQ line from the 
> > chip (and not the DRQ line). The DRQ interrupt was/is never registered 
> > (BTW, I found that it doesn't fire on one of the PowerBooks).
> 
> I don't think we really know where the DRQ line is connected, if at all.

The Guide to Mac Family Hardware says that IRQ and DRQ are connected to 
the OSS. AFAICT, DRQ is wired to VIA2 CA2 on all machines that have 
VIA2/RBV.

>From looking at the NetBSD driver and The Guide, I think perhaps we're 
using the wrong address for PDMA I/O on the particular powerbook that 
didn't raise a DRQ interrupt. (The IIci memory map in The Guide shows 
several different SCSI memory regions including "pseudo-DMA with DRQ" and 
"pseudo-DMA, no DRQ".) Worst case, we'd have to poll DRQ in the status 
register as per existing code.

> That's actually the problem I had with getting the DMA on the IIfx 
> working. I never got the EOT interrupt from the DMA engine.

... that doesn't sound very promising.

The Guide says, "Using the SCSI DMA IC, only data transfers are handled by 
the DMA channel; SCSI bus protocol is under the control of software 
running on the main processor, just as it is on other Macintosh models. 
The SCSI DMA IC on the Macintosh IIfx can also function as a conventional 
SCSI interface and transfer data under the control of the main processor 
... Existing drivers that don't use hardware handshaking will run on the 
Macintosh IIfx as is. Drivers that do use hardware handshaking must be 
modified to set up the SCSI DMA for hardware handshaking in order to run 
on the Macintosh IIfx ... To initiate a DMA transfer, the SCSI driver 
writes control information to the DMA address counter and DMA Byte Count 
register on the SCSI DMA IC and then writes to one of the IC's start 
registers."

There is no detailed programming information unfortunately. But to me, it 
sounds like PDMA is not possible on the IIfx (there's also a comment in 
mac_scsi.c to that effect) so it seems we either attempt DMA again or use 
PIO (yuck).

Finn

Re: mac scsi, ncr5380

[Boaz Harrosh]

Finn Thain wrote:
> Hi All,
> 
> Of late I've spent some time wrestling with mac_scsi. I've made some 
> progress, but I'm uncertain as to how I should procede -- whatever I do, 
> there will be implications for some other NCR5380 drivers.
> 
> mac_scsi actually works (once I fixed the enable_irq-before-request_irq 
> bug -- already fixed in various other NCR5380 wrapper drivers ... sigh) 
> but it only works in PIO mode. The PDMA read routine causes a bus error 
> (The Guide to Mac Family Hardware says "if a read or write operation over 
> the SCSI bus is not completed within certain time (different for different 
> machines), the general logic IC asserts a bus error (/BERR) to the CPU.")
> The driver tries to fall back to PIO mode when that happens.
> 
> The fall back succeeds only on the powerbook 190 and only if the code was 
> compiled with gcc-3. It just hangs on the PB 150 and Mac II, though PIO 
> works on those machines too when PDMA is disabled. So I think there's a 
> race there somewhere. And PIO doesn't work anywhere once debugging printks 
> are enabled.
> 
> All of which gives me little confidence in NCR5380.c.
> 
> (I tested those 3 machines because they have the 3 different kinds of 
> VIA2. Logs can be found here
> <http://www.telegraphics.com.au/~fthain/mac_scsi_logs/>
> should anyone want to see them.)
> 
> There is so much duplication of code for the NCR5380 drivers -- sun3, 
> atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't 
> know where to start looking for fixes.
> 
> Thinking that the bug would be trivial, I started out writing cleanup 
> patches for the existing mac_scsi.c/NCR5380.c combination. But the more I 
> think about it, the less I want to go in that direction.
> 
> Now I'm thinking that mac_scsi should adopt the atari core, since that 
> appears to be the better maintained contender. Michael, does that sound 
> sensible? Does it have working PDMA?
> 
> Another thing, should we look at merging sun3_NCR5380.c and 
> atari_NCR5380.c? The diff is huge, but that is because of the code style 
> and formatting cleanups in atari_NCR5380.c. The functional differencess 
> are few and far between.
> 
> If we can get to a working, common sun3/atari/mac core, I could then look 
> at minimising C preprocessor abuse in favour of a cleaner link-time/ops 
> struct abstraction layer -- with some assistance from Micheal and Sam: I'm 
> assuming that there is a cut somewhere that would make for a broadly 
> useful interface. Does this make sense?
> 
> Merging core 5380 drivers could _maybe_ go further if those responsible 
> for them were interested, but I would not want to bite off more than 
> atari/mac/sun3 at first. As to the rest, here's a list of all the relevant 
> #includes (this really needs to be converted to a graphical representation 
> somehow..) I don't know who maintains all of these 5380 drivers.
> 
> files that include NCR5380.c --
> ./drivers/scsi/arm/cumana_1.c
> ./drivers/scsi/arm/oak.c
> ./drivers/scsi/dmx3191d.c
> ./drivers/scsi/dtc.c
> ./drivers/scsi/g_NCR5380.c
> ./drivers/scsi/mac_scsi.c
> ./drivers/scsi/pas16.c
> ./drivers/scsi/t128.c
> 
> files that include NCR5380.h --
> ./drivers/scsi/arm/cumana_1.c
> ./drivers/scsi/arm/oak.c
> ./drivers/scsi/atari_scsi.c
> ./drivers/scsi/dmx3191d.c
> ./drivers/scsi/dtc.c
> ./drivers/scsi/g_NCR5380.c
> ./drivers/scsi/mac_scsi.c
> ./drivers/scsi/pas16.c
> ./drivers/scsi/sun3_scsi.c 
> ./drivers/scsi/sun3_scsi_vme.c
> ./drivers/scsi/t128.c
> 
> files that include atari_NCR5380.c --
> ./drivers/scsi/atari_scsi.c
> 
> files that include atari_scsi.h --
> ./drivers/scsi/atari_scsi.c
> 
> files that include dtc.h --
> ./drivers/scsi/dtc.c
> 
> files that include g_NCR5380.c --
> ./drivers/scsi/g_NCR5380_mmio.c
> 
> files that include g_NCR5380.h --
> ./drivers/scsi/g_NCR5380.c
> 
> files that include mac_scsi.h --
> ./drivers/scsi/mac_scsi.c
> 
> files that include pas16.h --
> ./drivers/scsi/pas16.c
> 
> files that include sun3_NCR5380.c --
> ./drivers/scsi/sun3_scsi.c
> ./drivers/scsi/sun3_scsi_vme.c
> 
> files that include sun3_scsi.h --
> ./drivers/scsi/sun3_scsi.c
> ./drivers/scsi/sun3_scsi_vme.c
> 
> files that include t128.h --
> ./drivers/scsi/t128.c
> 
> Note that this include graph is post-patching: I moved the #include 
> "NCR5380.h" out of sun3_scsi.h and into sun3_scsi.c and sun3_scsi_vme.c so 
> that the graph was more shallow and more symmetrical (that patch is at 
> <http://www.telegraphics.com.au/~fthain/patches_wip/>
> I'll send some of these patches for the 2.6.28 merge window.)
> 
> Regards,
> 
> Finn
> --
Dear Finn

>From a SCSI generic point of view. The current xxx_NCR5380 remind me allot
of the old ESP drivers stack. At-least at the surface level of the patches
I sent for both these drivers. I was lucky, at the end, to only send the
xxx_NCR5380 patches, because, as strongly recommended by Christoph Hellwig
(CCed), the old ESP stack was brilliantly replaced by a new one. That is 1/10
the size of the old one, and currently supports most of the interesting devices
out there. My unsent patches was a catalyst, for the now broken old-driver-stack,
to be removed quickly. And it seems every one is happy.

My point being, If you are looking to do a major cleanup work, on all these
1/2 forks. Maybe give a hard thought on just trashing the all thing and crafting
a completely new stack, 1/10 the size and much simpler, modern, and maintainable.

>From what I understand, (And again I do not), the ESP sounds a lot like the
NCR5380. I would craft a very similar copy of the new ESP stack, with it's
central library and function-vector registration, The scsi-generic part is
all there, in full glory. Then one concentrated effort should go into the
basic/general chip programing, which lots of it could be ripped from current
code, and the different platform implementation becomes one liners, if the new
ESP stack is any indication.

>From my passed experience, there becomes a source code state when a rewrite is
less effort then any cleanup or enhancements. From the small changes I had to do
to the xxx_NCR5380 family of drivers, my guts feeling scream "rewrite", so here I
voice them. In the mid/long-term you will work much less. And be much more
satisfied from the results.

Good lock
Boaz

Re: mac scsi, ncr5380

[Brad Boyer]

On Sun, Sep 28, 2008 at 09:28:38PM +1000, Finn Thain wrote:
> On Sat, 27 Sep 2008, Brad Boyer wrote:
> > .. the ideal situation would be to get the real DMA working (the IIfx is 
> > the only Mac using a 5380 chip that has real DMA) which would mean 
> > treating it as a separate machine anyway. If you want the details, doing 
> > PDMA on the IIfx requires poking the DMA engine to get it out of the 
> > way. I have the docs someplace.
> 
> Docs would be nice... although I can't test anything as I don't have that 
> hardware. But aside from yourself, there's a user on the debian-68k list 
> who has a IIfx.

The document on the SCSI-DMA chip for the IIfx is a pdf file that is
almost 3Meg. I can send you a copy if you want. I have a IIfx to test,
just not the time to spend writing the code.

> > > The schematics say that only the NCR5380 drives that VIA input (VIA2 
> > > CB2 aka IRQ_MAC_SCSI), so IRQ 19 is definitely the IRQ line from the 
> > > chip (and not the DRQ line). The DRQ interrupt was/is never registered 
> > > (BTW, I found that it doesn't fire on one of the PowerBooks).
> > 
> > I don't think we really know where the DRQ line is connected, if at all.
> 
> The Guide to Mac Family Hardware says that IRQ and DRQ are connected to 
> the OSS. AFAICT, DRQ is wired to VIA2 CA2 on all machines that have 
> VIA2/RBV.

The Guide also says that the PCR bits 1-3 on VIA2 are related to DRQ. Do
we know if we're setting the right values there? It doesn't document
what the individual settings of the bits do, but the Rockwell R6522 VIA
chip document has a chart for what the bits mean. It basically sets
if the line is really treated as an interrupt, and what type if so.
The comments in the code (via.c) suggest that different models use
different trigger types for these lines.

The odd thing about the DRQ on the IIfx going to OSS is that the list
in mac_oss.h has defines for all 16 interrupt bits, and there's only
one for SCSI. My understanding is that the list was based on the A/UX
headers from Apple and should be accurate. I never tried to request
one of the IRQs in the set that we don't have claimed by any driver
to see if one of them really is the DRQ.

> From looking at the NetBSD driver and The Guide, I think perhaps we're 
> using the wrong address for PDMA I/O on the particular powerbook that 
> didn't raise a DRQ interrupt. (The IIci memory map in The Guide shows 
> several different SCSI memory regions including "pseudo-DMA with DRQ" and 
> "pseudo-DMA, no DRQ".) Worst case, we'd have to poll DRQ in the status 
> register as per existing code.

Quite possible. We have 3 memory ranges for the 5380 chip on all systems.
Maybe they switched which one asserted DRQ on some models.

> > That's actually the problem I had with getting the DMA on the IIfx 
> > working. I never got the EOT interrupt from the DMA engine.
> 
> ... that doesn't sound very promising.
> 
> The Guide says, "Using the SCSI DMA IC, only data transfers are handled by 
> the DMA channel; SCSI bus protocol is under the control of software 
> running on the main processor, just as it is on other Macintosh models. 
> The SCSI DMA IC on the Macintosh IIfx can also function as a conventional 
> SCSI interface and transfer data under the control of the main processor 
> ... Existing drivers that don't use hardware handshaking will run on the 
> Macintosh IIfx as is. Drivers that do use hardware handshaking must be 
> modified to set up the SCSI DMA for hardware handshaking in order to run 
> on the Macintosh IIfx ... To initiate a DMA transfer, the SCSI driver 
> writes control information to the DMA address counter and DMA Byte Count 
> register on the SCSI DMA IC and then writes to one of the IC's start 
> registers."
> 
> There is no detailed programming information unfortunately. But to me, it 
> sounds like PDMA is not possible on the IIfx (there's also a comment in 
> mac_scsi.c to that effect) so it seems we either attempt DMA again or use 
> PIO (yuck).

Everything I've read says that regular MacOS uses PDMA on the IIfx. Only
A/UX had a proper driver to use the DMA. The document I have is pretty
detailed, although it's hard to be sure how complete it is. There definitely
are parts of the document that mention PDMA, so it should be possible with
some IIfx specific code. It might be easier to get the real DMA working
since finding the DRQ is likely to be the real issue either way.

	Brad Boyer
	flar@allandria.com

Re: mac scsi, ncr5380

[Finn Thain]

On Sun, 28 Sep 2008, Brad Boyer wrote:

> > The Guide to Mac Family Hardware says that IRQ and DRQ are connected 
> > to the OSS. AFAICT, DRQ is wired to VIA2 CA2 on all machines that have 
> > VIA2/RBV.
> 
> The Guide also says that the PCR bits 1-3 on VIA2 are related to DRQ. Do 
> we know if we're setting the right values there?

Well, that is partly why I tested the Mac II, PB 150 and PB 190. On the PB 
150 (RBV) there is no PCR. But on the Mac II we have all of the relevant 
schematics and data, so I'm certain that we've set that correctly. The PB 
190 has a "quadra-style" VIA, so it is most likely set correctly there too 
(or so I like to think! Macsbug says PCR is 0 on both Mac II and PB 190 
which make no sense to me.)

>...
> The odd thing about the DRQ on the IIfx going to OSS is that the list in 
> mac_oss.h has defines for all 16 interrupt bits, and there's only one 
> for SCSI. My understanding is that the list was based on the A/UX 
> headers from Apple and should be accurate. I never tried to request one 
> of the IRQs in the set that we don't have claimed by any driver to see 
> if one of them really is the DRQ.

I just checked the oss.h A/UX header file and it agrees with mac_oss.h. 
But perhaps DRQ was unused by A/UX (although the SCSI DMA chip would have 
needed it)? That might explain why oss.h lists 3 unused IRQs. Or perhaps 
DRQ and IRQ lines from the NCR5380 core share the same OSS IRQ.

Finn

Re: mac scsi, ncr5380

[Riccardo]

On Sunday, September 28, 2008, at 01:28  PM, Finn Thain wrote:

> Docs would be nice... although I can't test anything as I don't have 
> that
> hardware. But aside from yourself, there's a user on the debian-68k 
> list
> who has a IIfx.

That woule be me I guess?

Out of curisoity I started my faitfhul box again. It was off for months.

uname -a
Linux fangorn 2.2.25 #1 Fri Sep 5 17:57:09 EDT 2003 m68k GNU/Linux

I never got a usable newer kernel. Problems are usually scsi, keyboard, 
RTC... or not even booting at all (not getting past the b&w penguin)

but no problems, I can test kernels.

Riccardo

Re: mac scsi, ncr5380

[Brad Boyer]

On Mon, Sep 29, 2008 at 11:22:36PM +1000, Finn Thain wrote:
> On Sun, 28 Sep 2008, Brad Boyer wrote:
> > > The Guide to Mac Family Hardware says that IRQ and DRQ are connected 
> > > to the OSS. AFAICT, DRQ is wired to VIA2 CA2 on all machines that have 
> > > VIA2/RBV.
> > 
> > The Guide also says that the PCR bits 1-3 on VIA2 are related to DRQ. Do 
> > we know if we're setting the right values there?
> 
> Well, that is partly why I tested the Mac II, PB 150 and PB 190. On the PB 
> 150 (RBV) there is no PCR. But on the Mac II we have all of the relevant 
> schematics and data, so I'm certain that we've set that correctly. The PB 
> 190 has a "quadra-style" VIA, so it is most likely set correctly there too 
> (or so I like to think! Macsbug says PCR is 0 on both Mac II and PB 190 
> which make no sense to me.)

It's possible that macsbug isn't generating the right size load request
to make the chip happy. The 6522 is really just an 8 bit chip, and I think
the address decoder gets unhappy if you do a 16 or 32 bit load/store.

The PCR bits definitely look right in the code for the old II series models,
and supposedly the RBV systems just do the right thing. The problem is that
the "quadra-style" VIA emulation isn't all the same in every model. They
used a new ASIC almost every time. It's probably right, but I don't know.

> >...
> > The odd thing about the DRQ on the IIfx going to OSS is that the list in 
> > mac_oss.h has defines for all 16 interrupt bits, and there's only one 
> > for SCSI. My understanding is that the list was based on the A/UX 
> > headers from Apple and should be accurate. I never tried to request one 
> > of the IRQs in the set that we don't have claimed by any driver to see 
> > if one of them really is the DRQ.
> 
> I just checked the oss.h A/UX header file and it agrees with mac_oss.h. 
> But perhaps DRQ was unused by A/UX (although the SCSI DMA chip would have 
> needed it)? That might explain why oss.h lists 3 unused IRQs. Or perhaps 
> DRQ and IRQ lines from the NCR5380 core share the same OSS IRQ.

Well, that was the original source so it better agree. If they really are
wired to the same IRQ line on OSS, it should have worked. The interrupt
routine appeared to be checking the right status bits in the 5380 to check
for all the appropriate condition flags. It appeared that it just wasn't
getting called. Maybe I'll find some time and just try each of the three
unused interrupts and see if they do something. I would have thought that
using DMA without the DRQ would be pointless.

	Brad Boyer
	flar@allandria.com

Re: mac scsi, ncr5380

[Finn Thain]

On Mon, 29 Sep 2008, Riccardo wrote:

> 
> On Sunday, September 28, 2008, at 01:28 PM, Finn Thain wrote:
> 
> > Docs would be nice... although I can't test anything as I don't have 
> > that hardware. But aside from yourself, there's a user on the 
> > debian-68k list who has a IIfx.
> 
> That woule be me I guess?

How did you guess ;-)

> 
> Out of curisoity I started my faitfhul box again. It was off for months.
> 
> uname -a Linux fangorn 2.2.25 #1 Fri Sep 5 17:57:09 EDT 2003 m68k GNU/Linux
> 
> I never got a usable newer kernel. Problems are usually scsi, keyboard, RTC...
> or not even booting at all (not getting past the b&w penguin)

OK.

> but no problems, I can test kernels.

Thanks.

Finn

> 
> Riccardo
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: mac scsi, ncr5380

[Finn Thain]

On Mon, 29 Sep 2008, Brad Boyer wrote:

> It's possible that macsbug isn't generating the right size load request 
> to make the chip happy. The 6522 is really just an 8 bit chip, and I 
> think the address decoder gets unhappy if you do a 16 or 32 bit 
> load/store.

I see.

> If [IRQ and DRQ] are really are wired to the same IRQ line on OSS, it 
> should have worked.

Right. From looking at the SCSI DMA ASIC datasheet, it's clear that DRQ 
never leaves the chip. So for PDMA we'd have to poll the status register 
in the NCR5380 logic cell. Same for models where IRQ_MAC_SCSIDRQ can't be 
made to work.

> ...I would have thought that using DMA without the DRQ would be 
> pointless.

The DRQ signal is wired internally to the DMA state machine. But yeah, if 
you couldn't get it to raise an EOP interrupt, it is pointless.

Finn

Re: mac scsi, ncr5380

[Christoph Hellwig]

On Sun, Sep 28, 2008 at 04:16:08PM +0300, Boaz Harrosh wrote:
> >From a SCSI generic point of view. The current xxx_NCR5380 remind me allot
> of the old ESP drivers stack. At-least at the surface level of the patches
> I sent for both these drivers. I was lucky, at the end, to only send the
> xxx_NCR5380 patches, because, as strongly recommended by Christoph Hellwig
> (CCed), the old ESP stack was brilliantly replaced by a new one. That is 1/10
> the size of the old one, and currently supports most of the interesting devices
> out there. My unsent patches was a catalyst, for the now broken old-driver-stack,
> to be removed quickly. And it seems every one is happy.
> 
> My point being, If you are looking to do a major cleanup work, on all these
> 1/2 forks. Maybe give a hard thought on just trashing the all thing and crafting
> a completely new stack, 1/10 the size and much simpler, modern, and maintainable.

That would we very nice.  All 5380 drivers are in a really sorry state,
and a new one even if only working for sun3 and atari for now would be a
great change.  I'm not even sure if we have any users left for the PC
and arm 5380 drivers.

Re: mac scsi, ncr5380

[Finn Thain]

On Sun, 28 Sep 2008, Boaz Harrosh wrote:

> From what I understand, (And again I do not), the ESP sounds a lot like 
> the NCR5380. I would craft a very similar copy of the new ESP stack, 
> with it's central library and function-vector registration, The 
> scsi-generic part is all there, in full glory. Then one concentrated 
> effort should go into the basic/general chip programing, which lots of 
> it could be ripped from current code, and the different platform 
> implementation becomes one liners, if the new ESP stack is any 
> indication.

I still do not understand the whole ESP driver but when I wrote mac_esp.c 
I learned the value of the layered structure it provided.

I still have a lot to learn about the SCSI layers and the APIs too. I'm 
reading Documentation/scsi at the moment. If you know of any other 
introductory reading material, that would be a help.

> From my passed experience, there becomes a source code state when a 
> rewrite is less effort then any cleanup or enhancements. From the small 
> changes I had to do to the xxx_NCR5380 family of drivers, my guts 
> feeling scream "rewrite", so here I voice them. In the mid/long-term you 
> will work much less. And be much more satisfied from the results.

This makes sense. Thanks for your feedback.

Finn

> 
> Good lock
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: mac scsi, ncr5380

[Finn Thain]

On Tue, 30 Sep 2008, Christoph Hellwig wrote:

> On Sun, Sep 28, 2008 at 04:16:08PM +0300, Boaz Harrosh wrote:
> > From a SCSI generic point of view. The current xxx_NCR5380 remind me 
> > allot of the old ESP drivers stack. At-least at the surface level of 
> > the patches I sent for both these drivers. I was lucky, at the end, to 
> > only send the xxx_NCR5380 patches, because, as strongly recommended by 
> > Christoph Hellwig (CCed), the old ESP stack was brilliantly replaced 
> > by a new one. That is 1/10 the size of the old one, and currently 
> > supports most of the interesting devices out there. My unsent patches 
> > was a catalyst, for the now broken old-driver-stack, to be removed 
> > quickly. And it seems every one is happy.
> > 
> > My point being, If you are looking to do a major cleanup work, on all 
> > these 1/2 forks. Maybe give a hard thought on just trashing the all 
> > thing and crafting a completely new stack, 1/10 the size and much 
> > simpler, modern, and maintainable.
> 
> That would we very nice.  All 5380 drivers are in a really sorry state, 
> and a new one even if only working for sun3 and atari for now would be a 
> great change.  I'm not even sure if we have any users left for the PC 
> and arm 5380 drivers.

Me neither. And I'd prefer not to worry about the PC and arm drivers. I've 
bitten off more than enough already.

If I follow the ESP model, we'd get something like this:

-atari_NCR5380.c
-atari_scsi.c
-atari_scsi.h
-mac_scsi.c
-mac_scsi.h
-sun3_NCR5380.c
-sun3_scsi.c
-sun3_scsi.c 
-sun3_scsi.h
-sun3_scsi_vme.c
+ncr5380_scsi.c
+ncr5380_scsi.h
+mac_ncr5380.c
+atari_ncr5380.c
+sun3_ncr5380.c
+sun3_vme_ncr5380.c

Which would eliminate some of the duplication. I'd leave the other files 
untouched and let someone else worry about what to do with them -- in the 
hope that a rewrite that meets the needs of atari/sun/mac will at least 
approximate an alternative for the others.

Finn

Re: mac scsi, ncr5380

[Boaz Harrosh]

Finn Thain wrote:
> 
> On Sun, 28 Sep 2008, Boaz Harrosh wrote:
> 
>> From what I understand, (And again I do not), the ESP sounds a lot like 
>> the NCR5380. I would craft a very similar copy of the new ESP stack, 
>> with it's central library and function-vector registration, The 
>> scsi-generic part is all there, in full glory. Then one concentrated 
>> effort should go into the basic/general chip programing, which lots of 
>> it could be ripped from current code, and the different platform 
>> implementation becomes one liners, if the new ESP stack is any 
>> indication.
> 
> I still do not understand the whole ESP driver but when I wrote mac_esp.c 
> I learned the value of the layered structure it provided.
> 
> I still have a lot to learn about the SCSI layers and the APIs too. I'm 
> reading Documentation/scsi at the moment. If you know of any other 
> introductory reading material, that would be a help.
> 

I don't know anything about the ESP driver, You should contact
David S. Miller, Perhaps he will have some time to help you.

The SCSI-API I know more about. Please don't hesitate to ask 
any question, I will be glad to answer.

>> From my passed experience, there becomes a source code state when a 
>> rewrite is less effort then any cleanup or enhancements. From the small 
>> changes I had to do to the xxx_NCR5380 family of drivers, my guts 
>> feeling scream "rewrite", so here I voice them. In the mid/long-term you 
>> will work much less. And be much more satisfied from the results.
> 
> This makes sense. Thanks for your feedback.
> 
> Finn
> 
>> Good lock
>> Boaz
>> --

Thanks for looking into this. We are here for any assistance
Boaz