libata and DMA quirks

libata and DMA quirks

[Benjamin Herrenschmidt]

Hi !

While doing a pmac libata PATA driver, I've been looking at some of the
info we have from Apple (mostly the Darwin code) and some interesting
stuff pops out.

The main one is that one their latest cell, they do the following
"workarounds" which I never implemented in drivers/ide/ppc/pmac.c but
I'd like to implement in the libata driver, unless you believe that is
unnecessary:

a) For any ATAPI DMA, If the transfer size is not a multiple of 16
bytes, switch to PIO for this command.

b) Double buffer all ATAPI DMA reads. They allocate a 128K DMA buffer
and limit all requests to 128K. Then, they route all incoming DMAs to
that buffer and copy back to the original buffer on completion.

The comments in the code seem to indicate this has to do with "alignment
restrictions", unfortunately, I have no more infos so I don't know what
the actual underlying HW issues are.

I could use some tips as to how to implement these in the libata driver.
For a) I'm not sure about either overriding qc_prep or qc_issue and what
would be the consequence of changing tf.protocol there ? Among others,
qc_prep() would be after dma_map_sg has been performed, which is a
concern. I suppose I can ignore the DMA mapping, that would just be a
peformance issue.

Do you see anything else that could shoke on a change of protocol at
that stage ?

For b) I should be able to completely hide that within my qc_prep and
completion, by silently using a different DMA target. I suppose I can
use tf.command == ATA_CMD_ID_ATAPI to differenciate with ATA commands.

How do I set the max request size with the block layer tho from a libata
sub-driver ?

Thanks,

Cheers,
Ben.

Re: libata and DMA quirks

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:
> The main one is that one their latest cell, they do the following
> "workarounds" which I never implemented in drivers/ide/ppc/pmac.c but
> I'd like to implement in the libata driver, unless you believe that is
> unnecessary:
>
> a) For any ATAPI DMA, If the transfer size is not a multiple of 16
> bytes, switch to PIO for this command.
>   

   No need to do this in old driver anyway since the *IDE* core only 
uses DMA for block commands like READ and WRITE.
Not sure about libata.

WBR, Sergei

Re: libata and DMA quirks

[Benjamin Herrenschmidt]

On Fri, 2008-06-27 at 12:37 +0400, Sergei Shtylyov wrote:
> Hello.
> 
> Benjamin Herrenschmidt wrote:
> > The main one is that one their latest cell, they do the following
> > "workarounds" which I never implemented in drivers/ide/ppc/pmac.c but
> > I'd like to implement in the libata driver, unless you believe that is
> > unnecessary:
> >
> > a) For any ATAPI DMA, If the transfer size is not a multiple of 16
> > bytes, switch to PIO for this command.
> >   
> 
>    No need to do this in old driver anyway since the *IDE* core only 
> uses DMA for block commands like READ and WRITE.
> Not sure about libata.

It doesn't use DMA to transfer the bulk of ATAPI ? I know it uses PIO
for the CDB but the rest of the transfer isn't done with DMA ?

Ben.

Re: libata and DMA quirks

[Alan Cox]

> a) For any ATAPI DMA, If the transfer size is not a multiple of 16
> bytes, switch to PIO for this command.

Old IDE does this internally. Tejun has done a lot of this stuff for the
ATAPI layer in libata. See the check_atapi_dma method (example at
it821x_check_atapi_dma with a size rule)

> b) Double buffer all ATAPI DMA reads. They allocate a 128K DMA buffer
> and limit all requests to 128K. Then, they route all incoming DMAs to
> that buffer and copy back to the original buffer on completion.

That seems pretty icky. For overrun space on the standard SFF controllers
we just tack padding on the end of the DMA sg list.

> The comments in the code seem to indicate this has to do with "alignment
> restrictions", unfortunately, I have no more infos so I don't know what
> the actual underlying HW issues are.

Quite a bit of hardware has rules about the internal FIFO being fed in
internal burst sized chunks, especially older devices. For ATA that isn't
usually a problem, for ATAPI it is.

> I could use some tips as to how to implement these in the libata driver.
> For a) I'm not sure about either overriding qc_prep or qc_issue and what
> would be the consequence of changing tf.protocol there ? Among others,

You can't just change the protocol, you must change the command issued.

> For b) I should be able to completely hide that within my qc_prep and
> completion, by silently using a different DMA target. I suppose I can
> use tf.command == ATA_CMD_ID_ATAPI to differenciate with ATA commands.

if (ata_is_atapi(prot))

> How do I set the max request size with the block layer tho from a libata
> sub-driver ?

Set max_sectors for the disk in your dev_config method

See it821x_dev_config for a simple example

Re: libata and DMA quirks

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:
>>> The main one is that one their latest cell, they do the following
>>> "workarounds" which I never implemented in drivers/ide/ppc/pmac.c but
>>> I'd like to implement in the libata driver, unless you believe that is
>>> unnecessary:
>>>
>>> a) For any ATAPI DMA, If the transfer size is not a multiple of 16
>>> bytes, switch to PIO for this command.
>>>   
>>>       
>>    No need to do this in old driver anyway since the *IDE* core only 
>> uses DMA for block commands like READ and WRITE.
>> Not sure about libata.
>>     
>
> It doesn't use DMA to transfer the bulk of ATAPI ? I know it uses PIO
> for the CDB but the rest of the transfer isn't done with DMA ?
>   
   Like I said, DMA is used only for the *block* transfer commands for 
which the transfer size would always be a multiple of 16 bytes.

MBR, Sergei

Re: libata and DMA quirks

[Benjamin Herrenschmidt]

On Fri, 2008-06-27 at 09:54 +0100, Alan Cox wrote:
> > a) For any ATAPI DMA, If the transfer size is not a multiple of 16
> > bytes, switch to PIO for this command.
> 
> Old IDE does this internally. Tejun has done a lot of this stuff for the
> ATAPI layer in libata. See the check_atapi_dma method (example at
> it821x_check_atapi_dma with a size rule)

 .../...

Thanks Alan. I'll look at those various examples and sort things
out.

Cheers,
Ben.

Re: libata and DMA quirks

[Benjamin Herrenschmidt]

On Fri, 2008-06-27 at 13:10 +0400, Sergei Shtylyov wrote:
> > It doesn't use DMA to transfer the bulk of ATAPI ? I know it uses PIO
> > for the CDB but the rest of the transfer isn't done with DMA ?
> >   
>    Like I said, DMA is used only for the *block* transfer commands for 
> which the transfer size would always be a multiple of 16 bytes.

Ok, I see. That might explain why I never saw a problem not doing
anything special with drivers/ide.

Cheers,
Ben.