This message is from the T13 list server.
Hello Andre, >Since the new ADMA is a MMIO core and not IOMIO, you are required an new >subclass ident. And we have it--base class/subclass for ADMA is 01/05, not 01/01. >Whereas BAR4 is an PCI IO_MASK under SFF-8038i rules and the new Intel doc >e02105r0, Haven't seen this last doc on the server yet... > ADMA uses and extended MMIO at BAR4 and crosses BAR5. Of that what I'm pretty aware. >They are not the same transport layer. And of that too. Nevertheless, I don't see the point of standardizing values of the ADMA-compliant chip PCI device ID and revision ID. Those things were always at vendor discretion. ATAPI support (or lack thereof) by ADMA could've been and must be reported in some other way than standardized PCI revision ID (if the ADMA standard allows the optional support of ATAPI devices which is not so obvious as the optionality of that support is only mentioned in the PCI revision ID register description). PS: "Table 4. PCI Adapter bit definitions in Programming Interface Byte" doesn't mention that bit 7 has the standard value too, that value being "master IDE device", i.e. showing IDE bus mstering support. Further, looking a bit below from that table: AFAIR, BAR0-BAR3 don't have any default values like 1F1h/3F7h as per SFF-8038i. When in legacy mode, the corresponding channel's BARs should be set to 0 and "don't care" (which isn't always the case, I know). And in case of the native mode values like 1F1h/3F7h are jbviously bad. No other default values other than 0 were previously defined for these BARs. Subscribe/Unsubscribe instructions can be found at www.t13.org.
