Hi Finn,
However, atari never uses DMA here if cmd->device->borken.
Different semantics of borken, I presume. On Atari, this means a DMA
transfer has failed earlier.
Right. I suppose the question of using PIO in this situation on sun3 would
have to be put to the test.
Yep - let's see whether Sam has a working test configuration with
current kernels.
When cmd->device->borken, I assume sun3_NCR5380 inhibits PIO because
PIO was itself expected to be problematic?
The sun3 driver does set the borken flag but never uses it later - can't
see where it will inhibit PIO.
OTOH, if PIO works up to 128 bytes in all cases, why not larger
transfers?
Performance, perhaps.
Well, sun3_scsi has this:
static inline unsigned long sun3scsi_dma_xfer_len(unsigned long wanted,
struct scsi_cmnd *cmd,
int write_flag)
{
if (cmd->request->cmd_type == REQ_TYPE_FS)
return wanted;
else
return 0;
}
This does suggest that PIO does work beyond 128 bytes, even if it is
avoided for filesystem requests. Which suggests that the atari reselect
code might work on sun3.
(As for performance, I don't know why the REQ_TYPE_FS is significant: why
not just raise the DMA size limit to 512 instead?)
No idea really - the sun3 DMA allows to read the correct residual so it
probably is not necessary to strictly avoid DMA on anything not
guaranteed to transfer the requested size. Not sure what commands will
transfer between 128 and 512 bytes ...
PIO would work, but hog the CPU. In fact, PIO for everything _does_
work, on Falcon as well as Mac (I tried the PIO only mode on the Falcon
before trying on Mac). Did I eve mention how reallly incredibly
painfully slow that is?
Does the sun3_scsi driver still work after removing #define REAL_DMA?
For NCR5380_information_transfer() and PHASE_CMDOUT, the sun3 version
applies the same size limit but only does DMA setup if cmd type is
REQ_TYPE_FS (i.e. filesystem request). This command is then sent by
PIO, so the DMA setup here seems to assume that the next phase will
always be PHASE_DATAIN...
Might be a similar limitation to certain transfer sizes here. Block mode
vs. char mode.
Commands need to be sent by PIO always because of the DMA size limit.
The DMA setup early on may save time if the next phase is indeed DATAIN
or DATAOUT - if a command disconnects the DMA just won't be started. I
would have thought the DMA setup could just as easily be done inside
NCR5380_transfer_dma instead of splitting it in DMA setup and DMA start
- any particular reason for this, Sammy?
That suggests that the test for REQ_TYPE_FS in
NCR5380_information_transfer() in sun3_NCR5380 could be improved upon by
using NCR5380_dma_xfer_len() when checking the size limit. That way it
would work on atari as well, without #ifdefs.
The test for REQ_TYPE_FS could be done in the specific dma_xfer_len()
function which would need to be used whenever DMA setup is going to be
used. As it is, the separation of DMA setup from NCR5380_transfer_dma is
a bit mysterious and makes it hard to merge the drivers without lots of
ifdefs or runtime tests (think multiplatform kernels) anyway.
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
