Hi Finn,
On Sun, 3 Aug 2014, Michael Schmitz wrote:
NCR5380.c lacks support for tagged queueing, while sun3_NCR5380.c and
atari_NCR5380.c have divergent implementations of this.
Might be equivalent for all I've seen - just array vs. bitmap to store
tags..
It is messier than that. setup_use_tagged_queuing is disabled by default
on atari, and enabled by default on sun3. If we don't disable it by
It's configured but disabled by default on Atari because command_per_lun
is set to 1 by default. Can't remember why that was exactly - my best
guess would be that queueing up more commands in the lowlevel driver did
use to exacerbate timeout problems. But that was over a decade ago. On
Sun3, the code is not even configured from what I've seen (SUPPORT_TAGS
not defined).
default everywhere then we need to resolve a change to the algorithm: the
following code appears at the beginning of NCR5380_reselect() in
atari_NCR5380.c but appears at the end of that routine in sun3_NCR5380.c.
That's what I meant to say before - sun3_NCR5380.c does peek at the
message byte without invoking NCR5380_transfer_pio() (needs to manually
set/clear ACK for that resason, finds the disconnected command at issue,
does some DMA setup stuff for that command, and then goes ahead to fetch
the tag message bytes if the phase is still at message in. No idea where
the variable 'phase' gets set in that routine so it might never get to
read tag messages.
atari_NCR5390.c does things a bit different - instead of peeking at the
message byte, NCR5380_transfer_pio() is used for the first message byte
(ACK set there, cleared manually later). NCR5380_transfer_pio() sets the
current phase, so the subsequent transfer of the tag message may work
there (again ACK raised in NCR5380_transfer_pio(), cleared manually later).
I still have to try to figure out the implications of this change.
From what I've checked both should work, but the sun3 code never sets
'phase' so it should never actually have worked. It should not even
compile.
#ifdef SUPPORT_TAGS
/* If the phase is still MSGIN, the target wants to send some more
* messages. In case it supports tagged queuing, this is probably a
* SIMPLE_QUEUE_TAG for the I_T_L_Q nexus.
*/
tag = TAG_NONE;
if (phase == PHASE_MSGIN && setup_use_tagged_queuing) {
/* Accept previous IDENTIFY message by clearing ACK */
NCR5380_write( INITIATOR_COMMAND_REG, ICR_BASE );
len = 2;
data = msg+1;
if (!NCR5380_transfer_pio(instance, &phase, &len, &data) &&
msg[1] == SIMPLE_QUEUE_TAG)
tag = msg[2];
dprintk(NDEBUG_TAGS, "scsi%d: target mask %02x, lun %d sent tag %d at "
"reselection\n", HOSTNO, target_mask, lun, tag);
}
#endif
Changes to NCR5380. are rather major though. I need to carefully go
through the diff again. ISTR trying to run the coroutine as delayed
workqueue instead of immediate but dropped that again for some reason.
I don't think it makes sense to unify NCR5380.c and atari_NCR5380.c at
this stage. The ISA cards' requirements together are more peculiar than,
say, ST-DMA, and are mostly irrelevant to the M68k, ARM and PCI devices.
OK, not for today then.
As an aside, forking NCR5380.c into atari_NCR5380.c, sun3_NCR5380.c and
mac_NCR5380.c (deleted in v2.6.3) was clearly misguided as it never
actually produced a good alternative to NCR5380.c.
atari_NCR5380.c was forked at a time when the m68k port was developed
entirely independent from the main Linux development (which was i386
only at that stage). Linus did not want to deal with other
architectures, and merging m68k code into Linus' code was not something
the m68k authors envisaged at that stage. The fork was not meant to
produce a good alternative to the main driver, just something that
worked. At least that is as I recall it - I had little to do with Linux
kernel development at that stage.
Merging ongoing development on NCR5380.c into the Atari driver was
always something of an afterthought (Geert probably took care of most of
that). The sun3 and Mac drivers were then forked off the Atari one. I'm
guilty in part of the initial Mac one, but that was done mainly in order
to stop Alan Cox from whinging about the lack of a disk driver. (Don't
think he liked SCSI in PIO mode much.)
What I mean to say - in hindsight, it was misguided, but at the time we
did not have the benefit of a crystal ball (or git, or even fast cross
compilers).
Forking just multiplied the maintenance demands, and diminishing man-power
of course lead to neglect and breakage. So I can sympathise with
Christoph's comment in NCR5380.c:
* (Note from hch: unfortunately it was not enough for the different
* m68k folks and instead of improving this driver they copied it
* and hacked it up for their needs. As a consequence they lost
* most updates to this driver. Maybe someone will fix all these
* drivers to use a common core one day..)
Yep, I can now sympathise with that. When m68k began to merge with
Linus, we had already lost much of the initial man-power and expertise.
I'm sure we'd do things different now, but these lessons had to be
learned along the way.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
