This message is from the T13 list server.
My comments interleaved below marked with <MKE>. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pat LaVarre Sent: Tuesday, February 17, 2004 8:37 AM To: [EMAIL PROTECTED] Subject: Re: [t13] o x3F6 DeviceControl default should be what This message is from the T13 list server. > Remember > that some hosts don't even make a physical connection to the INTRQ > signal - they don't care about the setting of nIEN. Other hosts may > want to do some commands in polling mode and may set nIEN=1 when > executing those commands. Aye. At my desk now, I see o 376 02 floats INTRQ hi, just as selecting the absent device vi o 1F6 does. When floating hi, INTRQ appears asserted, so here now I can only disable the toggling of INTRQ that could edge-trigger a PIC, I cannot force INTRQ deasserted. That is, I cannot fully disable INTRQ. <MKE> This is very common since HBA's don't really have to interpret the interrupt. When you disable interrupts on the device you still need to deal with interrupts firing off. This is especially true in native PCI interrupt configurations, where if you don't mask the PIC or get the line to go low you'll see an interrupt "storm" that brings the system to it's knees. > >Anybody already know what is the most popular o x3F6 DeviceControl > >value? > > Well the possible values are: > > 80H - HOB bit (ATA devices) > 04H - SRST bit > 02H - nIEN bit Please could you elaborate "possible"? I was thinking the possible values are from x00 thru xFF inclusive. <MKE> "Possible" should be more like "expected+potential values". Only an unruly BIOS or Driver will send anything else. > NOTE: Bit 0 shall always be written by a host as zero. Mask x01 used to mean something? <MKE> Maybe in another universe, or before ATA4. > Ignore the LBA48 HOB bit .. By its t13.org definition, the o x3F6 DeviceControl port is shared and write-only. That means I can't read it, mess with it, restore it. Instead, when I need to force x02 nIEN lo for my device under test, I have to guess what else may have been written in the other bits or for the sake of the other device on the bus. <MKE> Yes, software must keep a "shadow register" in memeory to keep track of what it's previously written out. If multiple drivers tried to access the register both drivers would break each other. This is why the OS will virtualize the ATA task file registers and prevent the BIOS from doing anything after the OS driver takes over. > Ignore ... the SRST bit, Ok. <MKE> drivers may set/clear this bit to reset a device that is not responding, so Hale why do you suggest this be ignored? > most software will set the > nIEN bit depending on if the host wants to use interrupts. Good to hear. <MKE> most will leave it clear as polling usage is only useful in very limited conditions. > >x00 and x02? The difference there is x02 nIEN. > > I would assume 00H would be most common - I don't see why a > multitasking OS would not use interrupts or would ever want to > disable interrupts from an ATA device (interrupt disable would be > done at a much higher level - either in the processor or the system > interrupt controller). Are we not now starting to see x80 and x82 grow common? <MKE> No. This bit only gets used at the end of a transfer/command where we want to see the last LBA executed. This is generally during error conditions, but someone could do this after every command completion. I've not seen this second condition done...yet. > Note that on x86 systems using PCI bus ATA host controllers and > executing DMA data transfer commands the nIEN bit MUST BE ZERO. The > INTRQ signal from the device is needed by the host controller so that > it can know when a DMA data transfer command as ended, Yes. <MKE> some conditions under Windows, such as Crash and Hibernation writes to the disk are you forced to operate the disk in a polling mode. > especially for > read commands that do not transfer all the data described by the DMA > PRD list. This means the host can see the PRD list ended without needing to see the INTRQ from the device? In particular, devices which lack INTRQ can be read and written via DMA, except that errors then appear as timeouts, recovered by reset? > >Do Win XP/ 2K get along here, or does that design tradition conflict > >with Win ME/ 9X here? > > Why do you ask? Do you see differences in these OS? I'm asking because I find devices designed for Windows work best if I program my host to talk like Windows. Talking differently than Windows is a way of injecting noise that should not matter. I like to inject as little such noise as practical. I think the market shift to designing for XP rather than 98 has made compatibility temporarily more difficult to achieve, as we wait for hosts that were talking like 98 to learn to talk like XP. Personally I haven't practiced much lately, but once upon a time bus traces in effect identified the host by detailed choices that mostly don't matter. Possibly I remember I saw auto sense of x0E bytes in Win ME/ 9X, of x12 bytes in Win XP/ 2K. Possibly they did not both set the byte count limit to xFFFF. Etc. Pat LaVarre
