On Tue, Oct 10 2006, Robert Hancock wrote: > Allen Martin wrote: > >>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 > > 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.. 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. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
