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

[Tejun Heo <htejun@gmail.com>]

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