This message is from the T13 list server.
******** Editor's fault ********** I have re-checked my original notes and see that I incorrectly implemented the change. My notes show it as Larry stated. My notes show that the nIEN should have been added to the HPD2:HPD4 transition, and not to the HPD3:HPD4 transition. Also, the HPD3:HPD2 transition has nIEN=0 added (which I am not sure is correct, since I do not see it in my notes). Can you verify if this incorrect? I also need to change the associated word descriptions. If the HPD2:HPD4 nIEN=0 addition is incorrect, then my notes are consistent and it is merely an editorial error that I will fix in the next version, and no votes are needed. We definitely will review it at the meeting, however. John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Larry Barras Sent: Wednesday, October 29, 2003 2:24 PM To: Alexander Krebs; [EMAIL PROTECTED] Subject: Re: [t13] Host Packet DMA diagram in ATAPI-5/6/7 errata This message is from the T13 list server. Alex, With nIEN=0, following the packet (HPD1) the host enters the INTRQ_wait condition (HPD3). From this state there are two possible exit conditions: DMARQ asserts - the normal case. HPD3:HPD4 INTRQ asserts - the abnormal case (abort, etc) HPD3:HPD4 Somehow, I'm afraid the diagram was incorrectly updated, showing nIEN=1 as a condition for HPD3:HPD4. THIS IS WRONG!!!! The nIEN=1 condition is **SUPPOSED** to be attached to transition HPD2:HPD4. This is a requirement as there is no other condition that allows DMA following a check-status condition. Good catch Alex. My comments below following the June Meeting are still correct. The diagram was incorrectly updated and does not reflect the conditions below. We need to fix this state diagram at the next plenary. See page 122 of d1532v2r3e.pdf. At 10:14 AM +0100 10/29/03, Alexander Krebs wrote: >This message is from the T13 list server. > > >Larry, > >Sorry for the late response. I don't understand the correction as it >is in d1532r3e. > >If the device shall not assert INTRQ after the transfer of the packet >DMA command and before the execution of the command (the DMA >transfer), why shall the host do the HPD1:HPD3 transition in the >"Host PACKET DMA command state diagram"? I would expect a host shall >do HPD1:HPD2 independent of nIEN, i.e. IMO the HPD1:HPD3 transition >is not needed. > >What happens in the corrected version if nIEN==0: The host does >HPD1:HPD3 and waits for INTRQ to get out of HPD3. But the device does >not assert INTRQ (because it's not required to according to the >"Device PACKET DMA command state diagram") but asserts DMARQ to start >the DMA transfer. Neither the HPD3:HPD2 nor the HPD3:HPD4 condition is >true. How does the host get into HPD4 in this case? > >Costa, are you fine with the correction in the spec? I doubt it. But >I haven't seen a reply from you. > >Thanks, >Alex. > >> Date: Wed, 25 Jun 2003 15:49:31 -0700 >> To: "Constantine Sapuntzakis" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >> From: "Larry Barras" <[EMAIL PROTECTED]> >> Subject: [t13] Host Packet DMA diagram in ATAPI-5/6/7 errata >> >> This message is from the T13 list server. >> >> >> Constantine Sapuntzakis raised this issue a couple of months ago and >> yesterday at the T13 meeting we came up with a correction to the Host >> Side Packet DMA state diagrams that appear in ATA/ATAPI-5, 6 and the >> current draft of 7. >> >> The correction has two parts: >> >> 1. Add a further condition to HPD2:HPD4 that "nIEN=1". >> >> 2. Add a transition HPD3:HPD4 with condition, "DMARQ asserted". >> >> The diagram will be published in its corrected form in ATA-7. The >> committee is considering an errata for ATA-5 and ATA-6. >> >> >> >> At 11:06 AM -0800 4/5/03, Constantine Sapuntzakis wrote: >> >This message is from the T13 list server. >> > >> > >> >Figure 33 on page 350: >> > >> >The HPD1:HPD3 transition is not in SFF 8020i r2.6 and seems inconsistent >> >with the device diagram in Figure 34. >> > >> >The transition seems to imply that the host should wait for an interrupt >> >before starting a DMA transfer. But in the device diagram (Figure 34), >> >no such interrupt is generated prior to a DMA transfer. >> > >> >Also, SFF 8020i r2.6 does not require device to assert an interrupt >> >before starting a packet DMA (according to page 35) >> > >> >-Costa >> >> >> -- >> >> --------------------- >> I make stuff go. >> --------------------- >> >> Larry Barras >> Apple Computer Inc. >> 1 Infinite Loop >> MS: 306-2TC >> Cupertino, CA 95014 >> (408) 974-3220 >> > >-- > _______ AMD Saxony LLC & Co. KG | ALEXANDER KREBS > \ ___ | | Email: [EMAIL PROTECTED] > /| | | Dresden Design Center | Voice: +49 351 277 6835 >| |___| | Postfach 110 110 | Fax: +49 351 277 96835 >|____/ \| 01330 Dresden, Germany | M/S: I21-DC -- --------------------- I make stuff go. --------------------- Larry Barras Apple Computer Inc. 1 Infinite Loop MS: 306-2TC Cupertino, CA 95014 (408) 974-3220
