Re: "Fix ATAPI transfer lengths" causes CD writing regression

[Tejun Heo <htejun@gmail.com>]

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