Tejun Heo wrote: > 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. Eeek, please ignore this. I somehow completely forgot about Allocation Length fields in CDBs. 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
