Re: [RFC][PATCH] libata ATAPI alignment

2005-08-02 Thread Jens Axboe
On Fri, Jul 29 2005, Jeff Garzik wrote: So, one thing that's terribly ugly about SATA ATAPI is that we need to pad DMA transfers to the next 32-bit boundary, if the length is not evenly divisible by 4. Messing with the scatterlist to accomplish this is terribly ugly no matter how you

Re: [RFC][PATCH] libata ATAPI alignment

2005-08-02 Thread Jeff Garzik
Jens Axboe wrote: On Fri, Jul 29 2005, Jeff Garzik wrote: diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c --- a/drivers/scsi/ahci.c +++ b/drivers/scsi/ahci.c @@ -44,7 +44,7 @@ enum { AHCI_PCI_BAR= 5, - AHCI_MAX_SG = 168, /* hardware max is 64K */ +

Re: [RFC][PATCH] libata ATAPI alignment

2005-07-29 Thread Alan Cox
On Gwe, 2005-07-29 at 01:06 -0400, Jeff Garzik wrote: So, one thing that's terribly ugly about SATA ATAPI is that we need to pad DMA transfers to the next 32-bit boundary, if the length is not evenly divisible by 4. Looks good and avoids the special case leaking into the core code.

[RFC][PATCH] libata ATAPI alignment

2005-07-28 Thread Jeff Garzik
So, one thing that's terribly ugly about SATA ATAPI is that we need to pad DMA transfers to the next 32-bit boundary, if the length is not evenly divisible by 4. Messing with the scatterlist to accomplish this is terribly ugly no matter how you slice it. One way would be to create my own