On 01/04/2010 09:42 AM, Russell King wrote:
On Mon, Jan 04, 2010 at 10:25:37AM -0500, Jeff Garzik wrote:
On 01/04/2010 08:30 AM, Russell King wrote:
This rather makes sense. The PDC20247 handles the UDMA part of the
protocol. It has no way to tell the PDC20246 to wait while it suspends
UDMA, so that a normal register access can take place - the 246 ploughs
on with the register access without any regard to the state of the 247.
If the drive immediately starts the UDMA protocol after a write to the
command register (as it probably will for the DMA WRITE command), then
we'll be accessing the taskfile in the middle of the UDMA setup, which
can't be good. It's certainly a violation of the ATA specs.
Well...
Without AltStatus, you would not be able to check and see if a command
is complete...
I wasn't inferring that reading altstatus was a bad idea. I was saying
that causing altstatus to be read in the middle of an active UDMA
transfer (in other words, while the hosts DMACK is active) is a
violation of the spec.
I wouldn't say that's the case, as I don't see any such prohibition in
the ATA or SFF host adapter specs. The host doesn't necessarily know
whether or not a UDMA transfer is active or not. It's supposed to be the
controller's job to either terminate the UDMA burst or stall the access
until it can handle the request. It seems a bit of a deficiency of this
controller that it can't.
The problem with just taking the altstatus read out is that in certain
cases, the ATA spec requires that we wait for not 400ns, but one PIO
cycle time before reading the status register (which may be up to
600ns). The altstatus read inherently accomplishes this since it causes
a bus cycle. The spec says nothing about not being allowed to access
altstatus during this period, and in fact ATA-6 and up explictly suggest
a dummy altstatus read to do this.
One alternative might be to increase the delay to 600ns and change it to
read the BMDMA status register instead (to ensure PCI posted write
flushing with MMIO). The trick in doing this in generic code is that the
register might not exist (BMDMA controllers are a subset of SFF
controllers, which is what this code deals with).
There's no way for the 20247 (UDMA add-on) to know that the IO access
is coming; the first the 247 knows about it is when the CS/address lines
to the drive have been activated - in violation of the ATA specification
(which calls for the CS lines to be inactive and address lines to be zero
while UDMA is occuring.)
That means there's absolutely no way for the 20247 to stop the UDMA
protocol to allow a read of any registers on the drive until UDMA has
completed.
Yes, technically a buggy host design...
Indeed, which is why I suspect that a global change to handle this
controller may not be a good idea. Overriding sff_exec_command for this
driver to not do the altstatus read (just wait 600ns, maybe) might be
the best solution for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
