Re: [PATCH RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer

[Tejun Heo <htejun@gmail.com>]

James Bottomley wrote:
> I'm reluctant to add another parameter to the request, but this one you
> can calculate:  you just do it wherever you work out the size of the
> request.  If data_len is the true data length and total_data_len is the
> data length plus the drain length, the calculation fragment is
> 
> if (blk_pc_request(req))
> 	data_len = req->data_len;
> else
> 	data_len = req->nr_sectors << 9;
> total_data_len = data_len + req->q->dma_drain_size;
> 
> If the request has already been mapped by scsi, then data_len is
> actually scsi_cmnd->sdb.length

We either need to add a field or a helper and rq->data_len should
probably record the size with drain buffer attached and either add
raw_data_len or blk_rq_raw_data_len().  That size is the length of data
in sg and should be programmed into the controller etc... For ATAPI the
raw size is only used to program the chunk size for odd devices.

>> What's needed is updating libata accordingly and testing it.
> 
> Actually, I sent the patch to do this a few days ago:
> 
> http://marc.info/?l=linux-ide&m=120189565418258
> 
> But I've attached it again.

Thanks a lot.

>> I'm currently away from all my toys.  I'll implement the ATA part,
>> test it and submit the patch on Monday.
> 
> Great, will look forward to the results.  Like I said, I think the turn
> on draining in slave configure should be narrowed from all ATAPI devices
> to all AHCI ATAPI devices if there's no evidence that any other
> implementation that uses DMA to transfer PIO isn't similarly broken (I
> know the aic94xx works fine, for instance ...

What do you mean by aic94xx working fine?  Does the controller
automatically throw away extra data FISes?

Off to bed now.  See you tomorrow.

-- 
tejun