Björn Steinbrink wrote:
It should be correct the way it is - that check is trying to prevent
ATAPI commands from using DMA until the slave_config function has been
called to set up the DMA parameters properly. When the
NV_ADMA_ATAPI_SETUP_COMPLETE flag is not set, this returns 1 which
disallows DMA transfers. Unless you were using an ATAPI (i.e. CD/DVD)
device on the channel this wouldn't affect you anyway.
I wondered about it, because the flag is cleared when adma_enabled is 1,
which seems to be consistent with everything but nv_adma_check_atapi_dma.
When ADMA is enabled we can't use ATAPI at all (or so says NVidia
anyway), so it has to be disabled when an ATAPI device is detected in
slave_config. Since doing that implies using the legacy BMDMA engine
with its greater restrictions, this is why we need to prevent DMA
transfers from being attempted until those restrictions have been set
properly. (Otherwise, the libata core will try to use PACKET commands on
an ATAPI device with DMA enabled before slave_config is even called.)
Thus I thought that nv_adma_check_atapi_dma might be wrong, but maybe
setting/clearing the flag is wrong instead? *feels lost*
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
