Re: libata and DMA quirks

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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