RE: [t13] Automatic ATA device / host mode sync

[David F.]

Title: Message

 

So, on parallel ATA the method for locking the timings is going to be specific to each manufacturer as they are going to use different PLL's, clocking technologies, it will depend on the modes, upstream interfaces, etc. The absolute LAST thing you want is a controller to be sniffing the commands that are going out and making programming decisions based on those commands. It leads to all sorts of nastyness. See PATA->SATA bridge as an example.

 

>> Was actually thinking more like a host controller (with a well defined method to set the mode) could program the device or the device could single the host controller to change its mode.   Say device can indicate a control attention to the host controller who then determine the code (set mode) and parameters(the mode).  Then ATA can be used to control the device and anything requiring changes on the host controller can be controlled between the device and host controller (just a thought off the top of my head anyway).

<<

 

That's what ACPI is for.... (for an integrated controller)

 

>> If "having" to do it manually on both sides, as long as the host side was standard, would be fine (hopefully wouldn't take 1 to 2K of code to do something so simple).

<<

 

More answers:

*When is someone going to design a "TrueRAID" controller that hides the devices when programming at the ATA
*command/ports level?

There are controllers that do this today. There are controllers that don't. Both approaches are valid for different reasons. 

>> If the cost wasn't much, it would seem that would be the way all controllers should work.  With specific commands to talk directly to specific drives for DIAG and unit information reported in any SMART data (device registered expanded to allow more than one bit  (2 devices)).  The controllers would all abide to some standard for keeping the RAID info on the disks so you could even switch out the drives to a different controller without any hassle.  (Vendors could do some cools stuff like having multiple controllers hidden behind the one with 8 12 or 14 drives attached for RAID-5).
<<

*For the chipset/BIOS guys, It would be nice if the RAID controller could have two modes - RAID / Non-RAID in
*which the PCI class codes reflect the mode it's in.  (Also be sure to use UDMA on your int 13h interface - many
*highpoint based implementations use PIO 0 via int 13h)

Most if not all do reflect an 0104 class code when in RAID. (Not all do, but most do) 

>>I've only seen a new mobo have it, that A8N-SLI board.  Most of the stuff I had to deal with in the past was more than a year old.  Glad to see it working that way now
<<

As far as your SMART comment goes, I'll leave that to be answered by one of the drive guys. That being said, I've heard compelling reasons before for why they don't open up that level of detail. 

>>They don't want to give out their secrets to the other guys which is fine.  I'm saying just give out a standard for some of the basic information that is useful to software companies.  Which sectors are relocated, where to, how many spares left, which sectors are starting to act up, disable/enable relocation so software can access both the bad and new sectors, is the drive starting to act up or have an issue that the computer itself could take care of.   Shouldn't be anything secret in that type of information<< 

Remember ATA != SCSI. :)