Robert Hancock wrote:
Yeah, according to the datasheet "The SiI3124 will decode the 8-bit ATA
command at PRB offset 0x0a and automatically execute the default
protocol for the command. In certain cases it might be desirable to
specify a non-default protocol to be used, such as with vendor specific
device commands." The DSM command seems to be DMA data-out and the chip
likely doesn't know that command. I have to wonder why they decided to
use that design instead of just making the driver indicate the protocol
explicitly. In any case, it looks like the driver needs code to override
the protocol setting for this command. (Maybe we should just set the
protocol override for what we know the command is supposed to be in all
cases?)
Sil311x will have the same problem. The solution there seems to be to
execute a vendor-specific command to tell the controller what protocol
that command code uses. Some other controllers may have similar issues
if they are parsing the ATA command codes.. it's possible that some of
them might not support DSM/TRIM commands properly.
Yes, this is a common problem for many SATA controllers, for any new
opcode -- and for SATA<->PATA bridges too, which also snoop the opcode
to determine certain behaviors.
Jeff
--
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