On Tue, Oct 10 2006, Robert Hancock wrote:Allen Martin wrote:OK, I've updated the code to take this into account, an updated patch is attached. However, this does raise an issue. If we have to fall back to legacy mode to do ATAPI DMA, this means that we can't do 64-bit DMA for such transfers. Since by the time the driver gets a request the SGs have already been created based on the set DMA mask, the only way I can see to handle this is to either allow ATAPI DMA or 64-bit DMA, not both. I've chosen to default to 64-bit DMA in this version, but there is a module parameter which allows overriding this if you care more about using ATAPI devices than efficiency with over 4GB of RAM. I'm open to suggestions on a better way to handle this..But I really don't think that is necessary. I will take a look at docs and see how things match up, when I am much more awake. Most likely you need to be using another set of registers, and be all MMIO, all the time.You shouldn't be touching BM registers when ADMA is enabled, it can
cause bad things to happen.
You should be using BM registers when doing ATAPI protocol though, as it
doesn't work through ADMA. So I wouldn't say you should be using MMIO
all the time.
-Allen
Should be easily fixable - in general, set 64-bit dma mask. Then when
you detect an atapi device, lower the dma mask settings to 32-bit dma
for that device only. So the pci device in question gets a full 64-bit
dma mask, the attached scsi devices can have lower masks if necessary.
I'd suggest doing this off slave config.