Document recently-added ata_port_operations hooks.

Fill several doc stubs in libata-core.c.

When testing ATAPI PIO data transfer on the ppc64 platform,  __atapi_pio_bytes() got zero when
sg_dma_len() is used. I checked the <asm-ppc64/scatterlish.h>, the struct scatterlist is defined as:

struct scatterlist {
	struct page *page;
	unsigned int offset;
	unsigned int length;

	/* For TCE support */
	u32 dma_address;
	u32 dma_length;
};

#define sg_dma_address(sg)	((sg)->dma_address)
#define sg_dma_len(sg)		((sg)->dma_length)

So, if the scatterlist is not DMA mapped, sg_dma_len() will return zero on ppc64.
The same problem should occur on the x86-64 platform.
On the i386 platform, sg_dma_len() returns sg->length, that's why the problem does not occur on an i386.

Changes:
- Use sg->length if the scatterlist is not DMA mapped (yet).
Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>

Updated patch to fix erroneous flush of COMRESET set and missing flush
of COMRESET clear.  Created a new routine scr_write_flush() to try to
prevent this in the future.  Also, this patch is based on libata-2.6
instead of the previous libata-dev-2.6 based patch.
Signed-off-by: NBrett Russ <russb@emc.com>

Index: libata-2.6/drivers/scsi/libata-core.c
===================================================================

Problem:
   During the libata CD-ROM stress test, sometimes the "BUG: timeout
without command" error is seen.

Root cause:
  Unexpected interrupt occurs after the ata_qc_complete() is called,
but before the SCSI error handler.  The interrupt handler is invoked
before the SCSI error handler, and it clears the command by calling
ata_qc_complete() again.  Later when the SCSI error handler is run,
the ata_queued_cmd is already gone, causing the "BUG: timeout without
command" error.

Changes:
  - Use the ATA_QCFLAG_ACTIVE flag to prevent the interrupt handler
from completing the command twice, before the scsi_error_handler.
Signed-off-by: NAlbert Lee <albertcc@tw.ibm.com>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!