Hello, Jeff. Jeff Garzik wrote: > That's easy for the PIO case. But CD writing is normally DMA, which > means you will get a DMA engine exception if the device wants to give > you more data than the scatter/gather entries permit. For sense data and mode pages, the standard-sanctioned way to know the transfer size is to issue command with short buffer size just enough to contain the fixed size header part, determine actual transfer size from it and issue the command again with the correct buffer size. This doesn't happen for READ/WRITE commands. Transfer sizes are pre-determined for those commands and WRITE's to optical devices often can't be retried w/o side effect. I've just went through the ATA spec and this basically means we can't use DMA for these variable-transfer-length commands. Some DMA engines have "throw away what's left over bit" in its command structure or SG entry but not all do and none of drivers we currently has such feature enabled. Hmmm.... reading ide-cd.c::cdrom_pc_intr(). OIC, ide-cd is dealing with this problem by draining PIO after BMDMA engine is done. This is possible for BMDMA engines as they simply step out when the SG entries are exhausted; then, the interrupt handler kicks in and drains the left-over using PIO. This just isn't possible with more modern DMA engines. This really makes me think libata should do these commands via PIO unless we're gonna enable leftover draining for each DMA engine implementation or blacklist the ones which can't drain individually. Then again, nobody really knows how well those features would work as probably none has actually used them. Thanks. -- tejun - 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
