This message is from the T13 list server.
Just to expand on my questions about SATA-to-PATA bridges (see my previous email about the DMADIR proposal)... It seems that most current SATA-to-PATA bridges are... 1) ...Nearly transparent to a host. The host may not even know that SATA is being used. This all works because these bridges must watch for SET FEATURES commands and set their data transfer hardware DMA mode appropriately so that it matches the PATA device's DMA mode. But that DMA mode was selected by the host based on the PATA device's ID data. We must hope that these bridges support all DMA modes that are possible in shipping devices. 2) ...Are smart. Such a SATA-to-PATA bridge would intercept ID commands and SET FEATURE commands and modify the ID data and or the SET FEATURES mode in order to hide from the host the actual DMA mode being used on the ATA interface. This would be required in the case of a host that thought it could use DMA modes faster than the fastest mode supported by the bridge (for example the host and device can support U-DMA mode 6 but the bridge can only support U-DMA mode 5 - the bridge could allow the host to think U-DMA mode 6 is being used while U-DMA mode 5 is actually being used). I'm not sure there are any bridges that do this sort of thing? But I'm not sure how this DMADIR thing fits into any SATA-to-PATA bridge environment... How does a host know if there is a SATA-to-PATA bridge? Does the bridge modify the PATA ID data on-the-fly? If so, what does it modify? Is there an undocumented command that the bridge intercepts that will tell the host the bridge is present? If the bridge is so stupid that it needs the DMADIR bit then how does it keep up with the SET FEATURES commands that the host may be using to change the PATA interface DMA mode? Something here makes no sense. Doesn't the DMADIR feature need to specify how a SATA-to-PATA bridge actually works - how it is detected, how it operates, etc. This is not a new idea to ATA/ATAPI - T13 added some text and commands to support PATA-to-(memory card devices). It seems this SATA-to-PATA thing is really no different from a documentation requirement standpoint. This DMADIR feature will require all BIOS and OS drivers that want to use PACKET DMA command in the future to check for the DMADIR feature and use it if the ID data indicates it is supported. We know this is a requirement on the host software because devices that support DMADIR *will* find their way into the normal retail sales environment. There is no way that devices that support DMADIR can be restricted to only being sold in environments that include a DMADIR style SATA-to-PATA bridge device. I'm just curious what we are *really* trying to do here. Hale *** Hale Landis *** www.ata-atapi.com ***
