|
Greeting t13,
I
suggested Knut post his comments directly to the reflector, and he gave
permission for me to do it on his behalf.
John
-----Original Message-----
From: Grimsrud, Knut S [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 5:33 PM To: John Masiewicz Cc: [EMAIL PROTECTED] Subject: RE: [t13] New guidelines clarify Serial ATA "Intent" and T13 Working Group recommendations Hi John (and Dan) – thanks for forwarding this to me directly.
The steering committee will convene on Thursday and I expect to send you all the completed errata that are still undergoing final ratification immediately thereafter so you can get them considered for inclusion in the spec as we discussed. The most critical one is probably the latching cable errata, although there are one or two other minor nits as well (which might already have been corrected as part of the T13 refinements).
Below please find my views on some of the items you list in your writeup in case my interpretation of view seems contradictory (I think they’re largely aligned).
Knut
1. I don't personally think there is ambiguity over whether hosts are supposed to consider nIEN as immediately taking effect, and there is a state machine in the spec that shows the host state traversals for this. Since the items you list under this category don't seem to really address or relate to such an ambiguity, it probably doesn't matter.
Rule 1: This indeed appears to be a statement of fact based on what we learned from Seagate in the last meeting.
Rule 2: I think this might be a slight exaggeration since it seems that we’re talking about a couple different behaviors and not a complete free-for-all (either the device ignores it or not, etc). Since it is a statement and not directly relating to a particular spec action, it doesn't really matter.
2. It is true that it is unclear what is supposed to happen if a command register is sent with the SRST bit also set. However, I thought we came to the conclusion that within the defined command protocols for the spec it is not possible to send such a FIS, so the observation is largely academic since you would have to violate the spec to create the condition in the first place. Because the condition required a spec violation to create, this issue is not a big deal in my opinion.
Rule 3: I think this is a true statement. It is hopefully not a big deal since it's not possible for this condition to arise without first violating the spec elsewhere.
Rule 4: This is indeed an area where the SATA spec was not very clear and my interpretation of the original spec is different than the conclusion we came to in the meeting. My previous understanding was that the C bit determined whether the device acted on the Command register or the Control register and I did not have the understanding that if the C bit was 1 the device would act on both. We discussed this at the meeting and you indeed captured the consensus of the discussion in your rule. I'm not sure what all the host controllers' behavior is on this point and it could be a big deal if there are substantial differences in assumptions on this. By raising this we can hopefully determine whether there is an issue with this by getting opinion from the host controller guys.
Rule 5: This is true and is already the case as defined in the 1.0 spec.
3. I don’t feel the spec is as unclear on this as you do (of course, I may have some historical insight advantages that you don’t), but the current environment indicates that it’s sufficiently unclear to lead to variation in implemented behavior. I think one conclusion we eluded to was that it didn’t seem to matter which behavior the device adopts provided it does not implement legacy queuing (the only case we could readily identify that tripped up was a queuing case and the mileage we have on the shipping solutions thus far would seem to indicate that non-queuing environments are not getting tripped up). I think we concluded that if legacy queing is implemented, that the correct behavior could be produced if the second of two possible nIEN behaviors was adopted (i.e. drive always ignored nIEN and host-only performs the interrupt masking).
Rule 6: This isn't entirely precise as written but we can gloss over the nit since this item is not suggesting a behavior change. Since the I bit is effectively a edge/event notification that sets the host IPF latch and not a level-based signal, it cannot really be the interrupt pending flag for a device since the device cannot know how long the interrupt is pending for (the interrupt is cleared on the host side without visibility to the device). I know what you mean by the statement, though.
Rule 7: OK -- would be clearer if you pointed out that _devices_ may mask I bit based on nIEN in order to be clear (since the host also uses it’s local nIEN to mask the interrupt line). This is what the Seagate drive apparently does based on my understanding of the meeting discussion.
Rule 8: OK -- again it's not written in a way that is really precise/clear. It is vendor specific whether the device applies nIEN to mask the I bit or not. It's only vendor specific whether or not this masking occurs (the entire behavior is not vendor specific, just which of the two behaviors it implements). A different way of stating this is that it is device specific whether the nIEN bit is ignored or not.
Rule 9: OK – I think the recommendation was that the device ignore the nIEN bit since the host is already doing this masking and that the host likewise avoid sending the nIEN bit to avoid potential for the device responding to it.
Rule 10: This is a little different than my understanding. It was my understanding that the recommendation was for the device to ignore nIEN in all FISes (since the host already performs the nIEN masking). This seems to imply that the recommendation is that the device only ignore nIEN in some FISes but acts on it for Register FISes. Conversely, the host should mask the nIEN in all FISes (symmetrical recommendations). I may have misunderstood or forgotten some nuance of the situation here.
Rule 11: This is true for the current situation.
-----Original
Message-----
Knut, FYI, since you're not on the reflector John
-----Original
Message----- T13 Forum: At the last ATA-7 Working Group in Longmont on July 31-Aug 1, the group responded to the Editor's request for guidelines to clarify certain ambiguous or contradictory descriptions in Volume 3 (the Serial ATA Volume). This resulted in discussions that made it clear there are Serial ATA devices and hosts with several different implementations already. These different implementations may be said to conform to the original SATA spec, but could have interoperability issues due to the various interpretations of the "intent" of the original specification. We want to clarify the ATA-7 standard with the least disruption to prior designs. I have attempted to briefly describe the specification issues here, and listed the group's recommendations as rules so that we may reference them in further discussions. I will apply these rules to clarify the appropriate clauses of Volume 3, and I will mark all of the changes with change-bars for review and post it prior to the next T13 plenary meeting (Aug 19-21 in Boulder). I encourage you to review these issues carefully. I expect these new guidelines may cause some discomfort, and initiate spirited discussion at the next T13 meeting. I look forward to seeing you there!
1) It is unclear whether writing the Control Register with a change to nIEN takes immediate effect on the host adapter, and does not wait for a FIS transmission. There was also a question on what the device should or should not do with nIEN. Working Group
Guidance: (Rule 2) There is no defined behavior for a device when nIEN bit changes. 2) It is unclear whether the Register DH FIS with C=1 and C=0 are mutually exclusive (i.e. if the control reg only written if C=0 and Control Reg is not written if C=1). See Reg HD FIS description and host adapter descriptions. Also note that host and Device transport descriptions do not specify whether control or command FIS types write which registers and just says ‘registers’. Many descriptions imply that C=0 or C=1 write all of the registers. If the host optionally does not send the Control FIS to the device when the condition of nIEN is changed, then the host must manage the disabling or enabling of the interrupt on the host side. This is not specified. If you CAN set the Control register contents with a C=1, then there are some state machines that may be interpreted incorrectly (e.g. says if C=0 or says if C=1). What if C=1, but the SRST bit is also set =1? Another example; In state DI1:DI0, it does not say to transfer the contents to the control register if SRST is cleared to zero. Does this mean nothing to do if Control register is written unless state of SRST changes? (i.e. no changes to nIEN?) Working Group Guidance:
3) In the device, is the I bit completely independent of the nIEN bit? In other words, will the I bit will always be set or cleared regardless of state of nIEN? Is this true for all Device to Host FIS types? Is it true that you cannot look at the I-bit to determine if the host will be interrupted? The definition of the I bit says it reflects the interrupt “bit line” in the device, which could make sense in a bridge, but in a non-bridge solution, does it reflect the interrupt pending condition of the device independent of nIEN? Notice in state DI4, it says to set I=1. This is only true if the service interrupts are enabled. There are other similar references to setting the I bit. In the description of PIO Setup FIS Command Protocol, it says the I bit shall be set=1. Is I=1 always in PIO Setup FIS’es for data-in? In PIO Data-out, it says all I=1 except first DRQ block. (Should these statements say IPF?) (Also in DMA Data-out & in ending state). How should we clarify these statements? Working Group
Guidance: John Masiewicz
Western Digital
|
Title: New guidelines clarify Serial ATA "Intent" and T13 Working Group recommendations
- [t13] New guidelines clarify Serial ATA "Intent" ... John Masiewicz
- Re: FW: [t13] New guidelines clarify Serial ATA "... John Masiewicz
